Pergunta sobre a maneira ideal de organizar dados para um aplicativo para iPhone de estilo de livro

Question

Eu gostaria de começar a trabalhar em um aplicativo para iPhone que faz pouco mais do que exibir um conteúdo de livros para leitura. O conteúdo do livro está disponível online e é totalmente de código aberto, mas eu gostaria de disponibilizar o conteúdo localmente. Com os aplicativos em que trabalhei anteriormente, a saber, com o iPhone OS 2.x, criando (ou encontrando) um banco de dados .SQL e, em seguida, apenas fazendo consultas para dados de dentro do aplicativo funcionou muito bem. Com o advento dos dados principais (com os quais não estou tão familiarizado), o método SQL mais antigo pode não ser o ideal. Então, minha pergunta é: qual é a melhor maneira de eu ir do conteúdo da Web on -line para o conteúdo legível para iPhone armazenado localmente? Independentemente de qual abordagem adoto, vou precisar de um banco de dados (certo?), Então devo tirar o peso dela e começar a importar o conteúdo da Web em um banco de dados com todas as tabelas e colunas corretas? Acho que com esta pergunta, estou apenas procurando um ponto na direção certa. Se houvesse alguma sugestão sobre o melhor método para eu rolar sobre isso, seria muito apreciado. Obrigado!

Answer 1

Os dados principais são bons se você tiver "objetos" que deseja tornar persistente. No caso de ter muitos dados para ler/escrever, o SQLite antigo e simples pode ser mais simples.

Lamento não poder dar mais conselhos específicos, mas se resume a quão complicado o modelo de dados do aplicativo e os modelos de objetos são. Eu recomendo olhar para os dados principais, mas não os use apenas porque todo mundo diz como é legal.

Se você for com dados principais, não definirá seu próprio esquema de banco de dados SQL; portanto, não inicie esse caminho até que você tenha tomado a decisão.

Answer 2

Na verdade, eu iria com a rota de dados principal. Os dados principais são apenas uma API fornecida pela Apple para gerenciar dados persistentes, independentemente do back -end de dados (se é um arquivo plistado, um arquivo XML ou um arquivo de banco de dados SQLite completo).

No caso de um livro, você pode quebrar as entidades da seguinte forma.

Entidade do livro

• Título que é um atributo de string
• Autor, que é um atributo de string
• Capítulos que têm muitos relacionamentos de entidades de capítulo

Entidade do capítulo

• Título que é um atributo de string
• Páginas que têm muitas relações de entidades de página

Entidade da página

• PageText, que é um atributo de string

Em seguida, você pode acessar todos os valores como se fossem objetos usando dados principais sem precisar se preocupar com o código de back -end do SQL e escrever todo o código para traduzir os tipos de dados SQLite em objetos de cacau que seus controladores de exibição podem exibir.