seguridad - Crear una tienda JSON para iPhone

transferir mensajes de whatsapp de android a iphone

Question

Tenemos muchas aplicaciones en las que buscamos datos de servicios web remotos como JSON y luego usamos un analizador para traducirlo a un modelo de Core-Data.

Para una de nuestras aplicaciones, creo que deberíamos hacer algo diferente.

Esta aplicación tiene datos de solo lectura , que es volátil y, por lo tanto, no se almacena en la memoria caché local durante mucho tiempo . El JSON es profundamente jerárquico con toneladas de "objetos" anidados . Los documentos generalmente no contienen más de 20 elementos de nivel superior, pero pueden ser de hasta 100 K.

No creo que quiera crear un modelo de datos básicos con 100 de entidades, y luego usar un asignador para importar el JSON en él. Parece una canción y un baile así. Creo que solo quiero persistir en el JSON en algún lugar fácil, y tengo la capacidad de consultarlo. MongoDB estaría bien, si funcionó en iPhone.

¿Hay una tienda de documentos JSON en el iPhone que admita consultas?

O bien, ¿puedo usar algún analizador JSON para convertir los datos a algún tipo de NSDictionary persistente y consultarlos usando predicados?

¿O tal vez usar SQLite como una tienda BLOB con índices creados manualmente en las estructuras JSON?

O, ¿debería dejar de lloriquear y usar Core Data? :)

Ayuda apreciada.

Answer 1

Al decidir qué persistencia usar, es importante recordar que Core Data es ante todo un sistema de administración de gráficos de objetos. Su verdadera función es crear la capa de modelo de tiempo de ejecución de las aplicaciones modeladas por diseño de Model-View-Controller. La persistencia es en realidad una función secundaria e incluso opcional de Core Data.

Las principales preocupaciones de modelado / persistencia son el tamaño de los datos y la complejidad de los datos. Entonces, las fortalezas y debilidades relativas de cada tipo de persistencia se desglosarían así:

    _______________________________
    |               |              |
  2 |               |              |
    |  SQL          |  Core Data   | 4
s   |               |              |
i   |_______________ ______________|
z   |               |              |
e   |               |              |
  1 |  Collection   |  Core Data   | 3
    |  plist/xml    |              |
    |               |              |
    -------------------------------  
              Complexity--->       

A lo que podríamos agregar una tercera dimensión de arrendador, la volatilidad, es decir, con qué frecuencia cambian los datos

(1) Si el tamaño, la complejidad y la volatilidad de los datos son bajos, usar una colección, por ejemplo, NSArray, NSDictionary, NSSet de un objeto personalizado serializado sería la mejor opción. Las colecciones deben leerse por completo en la memoria para que limite su tamaño de persistencia efectiva. No tienen administración de complejidad y todos los cambios requieren volver a escribir todo el archivo de persistencia.

(2) Si el tamaño es muy grande pero la complejidad es baja, SQL u otra API de base de datos puede ofrecer un rendimiento superior. Por ejemplo, un sistema de tarjeta de índice de una biblioteca antigua. Cada carta es idéntica, las cartas no tienen ninguna relación entre ellas y las cartas no tienen ningún comportamiento. SQL u otras bases de datos de procedimientos son muy buenas para procesar grandes cantidades de información de baja complejidad. Si los datos son simples, SQL puede manejar incluso datos altamente volátiles de manera eficiente. Si la interfaz de usuario es igualmente simple, la integración de la interfaz de usuario en el diseño orientado a objetos de una aplicación iOS / MacOS tiene poco gasto.

(3) A medida que los datos se vuelven más complejos, Core Data rápidamente se vuelve superior. La parte "administrada" de "objetos administrados" maneja la complejidad en las relaciones y los comportamientos. Con colecciones o SQL, puede administrar la complejidad de forma manual y puede encontrarse rápidamente inundado. De hecho, he visto personas tratando de administrar datos complejos con SQL que terminan escribiendo su propia pila de datos básicos en miniatura. Huelga decir que cuando se combinan la complejidad con la volatilidad, Core Data es aún mejor porque maneja los efectos secundarios de las inserciones y eliminaciones de forma automática.

(La complejidad de la interfaz también es una preocupación. SQL puede manejar una gran tabla estática singular, pero cuando agrega jerarquías de tablas en las que puede cambiar sobre la marcha, SQL se convierte en una pesadilla. Core Data, NSFetchedResultsController y UITableViewController / delegados lo hacen trivial.)

(4) Con alta complejidad y gran tamaño, Core Data es claramente la mejor opción. Core Data está altamente optimizado, por lo que el aumento en el tamaño del gráfico no empantana tanto como lo hacen con SQL. También obtienes caché altamente inteligente.

Además, no confunda, "Entiendo completamente SQL, pero no Core Data", con "Core Data tiene una sobrecarga alta". Realmente no. Incluso cuando Core Data no es la manera más económica de obtener datos dentro y fuera de la persistencia, su integración con el resto de la API generalmente produce resultados superiores cuando se tiene en cuenta la velocidad de desarrollo y la confiabilidad.

En este caso particular, no puedo decir a partir de la descripción si está en caso (2) o caso (4). Depende de la complejidad interna de los datos Y de la complejidad de la IU. Tu dices:

No creo que quiera crear un modelo de datos básicos con 100 de entidades, y luego usar un asignador para importar el JSON en él.

¿Te refieres a entidades abstractas reales aquí o simplemente a objetos administrados? Recuerde, las entidades son para los objetos gestionados qué clases son para las instancias. Si el primero, entonces sí, los datos básicos serán mucho trabajo por adelantado, si es el último, entonces no será así. Puede construir gráficos complejos muy grandes con solo dos o tres entidades relacionadas.

Recuerde también que puede usar la configuración para colocar entidades diferentes en diferentes tiendas, incluso si todas comparten un único contexto en el tiempo de ejecución. Esto puede permitirle poner información temporal en una tienda, usarla como datos más persistentes y luego eliminar la tienda cuando haya terminado con ella.

Los datos principales le brindan más opciones de las que podrían ser aparentes a primera vista.

Answer 2

Yo uso SBJson para analizar JSON a NSDictionaries y luego guardarlos como archivos .plist usando [dict writeToFile:saveFilePath atomically:YES] . La carga también es igual de simple NSMutableDictionary *dict = [NSDictionary dictionaryWithContentsOfFile:saveFilePath] . Es rápido, eficiente y fácil. No hay necesidad de una base de datos.

Answer 3

JSON Framework es uno. Convertirá tu JSON en objetos NSDictionary y NSArray nativos. No sé nada sobre su rendimiento en un documento grande como ese, pero mucha gente lo usa y me gusta. No es la única biblioteca JSON para iOS, pero es muy popular.