Transição de Restkit para AFNetworking Pure AFNetworking

Question

Eu estava usando o Restkit nos últimos dois anos, mas recentemente comecei a pensar em transição dessas estruturas de monólito como parece ser realmente exagero.

Aqui estão meus profissionais para seguir em frente:

.
1. Há grande necessidade de usar nsurlsession para busca de fundo e restkit tem apenas ramificação experimental para transição para a AFNetworking 2.0. Não há datas reais quando a transição será concluída. (Razão principal)
2. Não há necessidade de suporte ao Coredata na biblioteca de rede, pois não há necessidade de armazenamento de dados offline totalmente funcional.
3. Ter dor de cabeça com o novo conceito de descritores de resposta / solicitação, pois eles não suportam diferentes parâmetros em padrões de caminho (Ex. Parâmetro de token de acesso) e não há como criar a operação de solicitação de objeto em uma linha com descritor personalizado. Aqui estou perdendo recursos do Gerente de Objetos como fachada.

i. a maior perda de restkit para mim em processo de mapeamento de objeto. Você poderia recomendar bibliotecas independentes que você usa que se mostra como flexíveis e estáveis?

ii. e como eu triste eu preciso não totalmente funcional armazenamento, mas eu ainda preciso de um suporte de cache em alguns lugares. Eu ouvi que Nsurlcache tornou-se útil no último sistema de liberação. Você usou e qual é a estratégia? Ele retorna em cache respostas de API quando a conexão de rede está para baixo ?

iii. Alguém enfrenta os mesmos problemas? Quais soluções você se inscreveu? Talvez alguém pudesse dar um pouco de conselho sobre a arquitetura que ele ou ela usa em vários aplicativos com puro AFNetworking?

Answer 1

i. De acordo com outras pessoas que comentaram, AFNetworking + Mantle é uma maneira simples e eficaz de interagir com uma API repousante e para substituir o processo de mapeamento de objetos do Restkit que você sente falta.

II. Para responder aos requisitos do seu suporte de cache, é altamente dependente do contexto. No entanto, eu encontrei para os meus requisitos funcionais recentes que armazenando em cache um modelo de exibição para uma determinada tela do controlador e apenas dados de referência de cache retornados pela APIs me permite manter a lógica do aplicativo relativamente simples, enquanto dando ao usuário alguma continuidade. Uma simples notificação de erro para problemas de conectividade pode ser tratada de maneira transversal.

III. Um pensamento na arquitetura relevante para este aspecto é garantir que a APIs o aplicativo dependente fornece dados de acordo com a experiência do aplicativo. Isso permite que seu aplicativo se concentre no que seja bom em (uma experiência de usuário muito slick) e move a lógica para as dependências da API, como dados. Isso tem um benefício adicional de reduzir a agitação do aplicativo.