core data - Transición de RestKit a pura AFNetworking 2.0

core-data restkit-0.20

Question

Había estado usando RestKit durante los últimos dos años, pero recientemente comencé a pensar en la transición de estos monolitos marco, ya que parece ser demasiado exagerado.

Aquí están mis pros para seguir adelante:

1. Existe una gran necesidad de utilizar NSURLSession para las recuperaciones de fondo y RestKit solo tiene una rama experimental para la transición a AFNetworking 2.0. No hay fechas reales cuando la transición habrá finalizado. (Razón principal)
2. No es necesaria la compatibilidad con CoreData en la biblioteca de red, ya que no es necesario contar con un almacenamiento de datos fuera de línea totalmente funcional.
3. Tener dolor de cabeza con el nuevo concepto de descriptores de respuesta / solicitud ya que no admiten diferentes parámetros en los patrones de ruta (por ejemplo, el parámetro token de acceso) y no hay forma de crear una operación de solicitud de objeto en una línea con un descriptor personalizado. Aquí estoy perdiendo características del administrador de objetos como fachada.

I. La mayor pérdida de RestKit para mí en el proceso de mapeo de objetos. ¿Podría recomendar bibliotecas independientes que use que se muestren flexibles y estables?

II. Y como me entristece, no necesito un almacenamiento completamente funcional , pero aún necesito algo de soporte de almacenamiento en caché en algunos lugares. Escuché que NSURLCache se volvió útil en la última versión del sistema operativo. ¿Lo usaste y cuál es la estrategia? ¿Devuelve respuestas de API en caché cuando la conexión de red no funciona ?

III. ¿Alguien tiene los mismos problemas? ¿Qué soluciones has aplicado? ¿Tal vez alguien podría dar algún consejo sobre arquitectura que él o ella usa en múltiples aplicaciones con AFNetworking puro?

Answer 1

I. De acuerdo con otros que han comentado, AFNetworking + Mantle es una forma simple y efectiva de interactuar con una API Restful y reemplazar el proceso de mapeo de objetos de RestKit que usted omite.

II. Para responder a los requisitos de su soporte de almacenamiento en caché, depende en gran medida del contexto. Sin embargo, he encontrado que para mis requisitos funcionales recientes el almacenamiento en caché de un modelo de vista para la pantalla de un controlador en particular y solo los datos de referencia de almacenamiento en caché devueltos por API me permiten mantener la lógica de la aplicación relativamente simple mientras le da al usuario cierta continuidad. Una simple notificación de error para problemas de conectividad se puede tratar de una manera transversal.

III. Un pensamiento sobre la arquitectura relevante para este aspecto es asegurar que las API de las que depende la aplicación proporcionen datos de acuerdo con la experiencia de la aplicación. Esto permite que su aplicación se centre en lo que es bueno (una experiencia de usuario muy hábil) y mueve la lógica a las API más cerca de las dependencias de la API, como los datos. Esto tiene un beneficio adicional de reducir el chattiness de la aplicación.