¿Datos básicos con el patrón recomendado de servicios web?

Question

Estoy escribiendo una aplicación para iOS que usa datos proporcionados por un servicio web. Estoy utilizando datos centrales para el almacenamiento local y la persistencia de los datos, de modo que algunos de los principales conjuntos de datos estén disponibles para el usuario si la web no es accesible.

Al construir esta aplicación, he estado leyendo muchas publicaciones sobre datos básicos. Si bien parece haber muchos por ahí sobre la mecánica de hacer esto, he visto menos en los principios/patrones generales para esto.

Me pregunto si hay algunas buenas referencias para un modelo de interacción recomendado.

Por ejemplo, el usuario podrá crear nuevos objetos en la aplicación. Digamos que el usuario crea un nuevo objeto empleado, el usuario típicamente lo creará, lo actualizará y luego lo guardará. He visto recomendaciones que actualiza cada uno de estos pasos al servidor -> cuando el usuario lo crea, cuando el usuario realiza cambios en los campos. Y si el usuario cancela al final, se envía una eliminación al servidor. Otra recomendación diferente para la misma operación es mantener todo localmente y solo enviar la actualización completa al servidor cuando el usuario lo guarde.

Dejando a un lado este ejemplo, hay algunas recomendaciones/patrones generales sobre cómo manejar las operaciones CRUD y asegurar que estén sincronizadas entre el servidor web y los datos principales.

Muchas gracias.

Answer 1

Es posible que desee leer sobre 'transacciones', que es básicamente la agrupación de acciones/cambios múltiples como una única acción/cambio atómico. Esto ayuda a evitar rescates parciales que pueden dar como resultado datos incoherentes en el servidor.

En última instancia, este es un tema muy importante, especialmente si los datos del servidor se comparten entre varios clientes. En el más simple, le conviene decidir sobre políticas básicas. ¿El último ahorro gana? ¿Existe alguna noción de bloqueos retenidos remotamente en objetos en el almacén de datos del servidor? ¿Cómo se resuelve el conflicto, cuando dos clientes están, por ejemplo, editando la misma propiedad del mismo objeto?

Con respecto a cómo se hacen las cosas en el iPhone, estoy de acuerdo con occulus que "Hecho" proporciona un punto natural para los cambios persistentes en el servidor (en un hilo separado).

Answer 2

Creo que el mejor enfoque en el caso que menciona es almacenar datos solo localmente hasta el momento en que el usuario confirma la adición del nuevo registro. El envío de cada edición de campo al servidor es algo excesivo.

Una expresión general de las aplicaciones de iPhone es que no existe tal cosa como "Guardar". El usuario generalmente espera que las cosas se comprometan en algún punto sensible, pero no se presenta al usuario como un ahorro per se.

Por lo tanto, imagine que tiene una IU que le permite al usuario editar algún tipo de registro que se guardará en los datos centrales locales y también se enviará al servidor. En el momento en que el usuario sale de la interfaz de usuario para crear un nuevo registro, tal vez presionen un botón llamado "Listo" (N.B. normalmente no se llama "Guardar"). En el momento en que presionen "Listo", querrá iniciar una escritura de datos básicos y también comenzar un empuje hacia el servidor remoto. El servidor no necesariamente enganchará la interfaz de usuario ni los hará esperar hasta que finalice (es más agradable permitirles que sigan usando la aplicación), pero está sucediendo. Si la actualización push to server falló, es posible que desee señalizarlo al usuario o hacer algo apropiado.

Una buena pregunta que debes hacerte cuando planificas la granularidad de las escrituras en los datos centrales y/o en un servidor remoto es: ¿qué pasaría si la aplicación fallara o el teléfono se quedara sin energía en algún punto del sistema? aplicación? ¿Cuánta pérdida de datos podría ocurrir? Las buenas aplicaciones reducen el riesgo de pérdida de datos y pueden relanzarse en un estado muy similar al que tenían anteriormente después de haber sido retiradas por cualquier motivo.

Answer 3

Prepárate para arrancarte un pelo bastante. He estado trabajando en esto, y el problema es que las muestras de datos básicos son bastante simples. En el momento en que se mueve a un modelo complejo e intenta utilizar NSFetchedResultsController y su delegado, se encuentra con todo tipo de problemas al usar contextos múltiples.

Utilizo uno para completar los datos de su servicio web en un "bloque" de fondo, y un segundo para la vista de tabla; lo más probable es que termine usando una tabla para una lista maestra y una vista de detalle.

Ponga énfasis en el uso de bloques en Cocoa si desea mantener su aplicación receptiva mientras recibe o envía datos a/desde un servidor.