Arquitetura “Middle Ground” para aplicativos iOS cliente-servidor?

5

Eu vejo duas abordagens óbvias para a arquitetura de um aplicativo para iOS que precisa falar com um servidor para fazer seu trabalho.

Finja ser um navegador da web

Sob essa abordagem, o aplicativo busca um bloco de dados (geralmente JSON) do servidor em resposta a uma ação do usuário (navegando para um novo controlador de visualização, tocando em uma "Atualização", o que for), coloca um spinner ou algum outro indicador de progresso e atualiza a visualização quando a solicitação é concluída. As classes "model" são mapeadas diretamente a partir do JSON de entrada e, possivelmente, até mesmo imutáveis, e descartadas quando o usuário sai da tela que foi buscada para preencher.

Na versão "pura" dessa abordagem, você define os cabeçalhos apropriados no servidor e deixa que a NSURLSession e os amigos gerenciem o armazenamento em cache.

Isso funciona bem se você puder assumir que o usuário tem conectividade de rede rápida e de baixa latência e, na maioria das vezes, está lendo dados do servidor e não está escrevendo.

Sincronização

Com a abordagem de "sincronização", o aplicativo mantém um armazenamento de dados do núcleo local de objetos de modelo para exibir ao usuário. Ele atualiza isso em resposta à ação do usuário ou periodicamente e atualiza a interface do usuário (via KVO ou similar) quando o modelo é alterado. Quando o usuário modifica o modelo, essas alterações são enviadas ao servidor de forma assíncrona; deve haver um mecanismo para resolver conflitos.

Essa abordagem é mais adequada quando o aplicativo precisa funcionar off-line ou em contextos de alta latência / rede lenta, ou onde o usuário está gravando muitos dados e precisa ver as alterações no modelo sem esperar pela devolução do servidor.

Existe um terceiro caminho intermediário? E se eu tiver um aplicativo que seja principalmente , mas nem sempre seja lido, mas onde houver gravações, o usuário deverá ver essas atualizações refletidas na IU imediatamente. O aplicativo deve ser utilizável em situações de pouca / nenhuma rede (mostrando todos os dados armazenados anteriormente em cache até que uma solicitação ao servidor tenha tempo de responder).

Posso obter o melhor dos dois mundos sem ter o Core-Data-with-sync completo (que parece pesado e difícil de acertar), mas sem implementar inadvertidamente um clone com bugs e incompletos do Core Data?

    
por Robert Atkins 14.08.2014 / 11:26
fonte

1 resposta

1

Não de uma perspectiva de esforço. Se você está implementando qualquer coisa através de um modelo de sincronização, você precisa construir tudo o que for necessário. Opcionalmente, você pode optar por permitir - para alguns feeds - carregamento lento na atualização, se isso for desejável do ponto de vista do desempenho (essa é uma prática comum para feeds pequenos e obscuros em que menos de 50% da base de usuários navegará). p>

Mas, claro, embora isso seja ainda melhor do que "um ou outro", como acima, ele tem um problema que você essencialmente precisa construir ambos . Na minha opinião, é a maneira mais eficiente de lidar com o carregamento de dados em um aplicativo para dispositivos móveis.

    
por 30.09.2014 / 22:08
fonte