Se você está usando Versões no seu modelo Core Data você sempre deve iniciar seu Managed Object Model (NSManagedObjectModel) apontando a versão que você quer usar. Dentro do Application Bundle de sua app irá encontrar um arquivo com a extesão .momd,este arquivo é o Model Completo. Dentro desse arquivo você irá encontrar outros arquivos com extensão  .mom, cada arquivo .mom representa uma versão do seu modelo.

Se você rodou sua aplicação apontando ao Modelo Completo com todas as versões dentro, Core Data irá criar o banco de dados com todas as versões, portanto temos o erro de entity duplicado mais adiante, o Core Data não sabe qual versão usar. Nesse ponto, a única forma para solucionar o problema é remover a aplicação, apontar o seu código para a versão correta e rodar novamente, então o Core Data irá criar somente uma versão do banco de dados.

Aqui um pedacinho de código que dá conta do recado:

NSString *fullModelName    = @"myModel.momd";    // The name of the main model.
NSString *modelVersionName = @"myModel1.0.mom";  // Only the name of the version.
NSString *bundlePath = [[NSBundle mainBundle] bundlePath];
NSString *modelPath = [NSString stringWithFormat:@"%@/%@/%@", bundlePath, fullModelName,  modelVersionName];
//
NSURL *modelURL = [NSURL fileURLWithPath:modelPath];
managedObjectModel_ = [[NSManagedObjectModel alloc] initWithContentsOfURL:modelURL];

Um dos erros mais comuns e que a mim me trouxe grandes dores de cabeça são erros de “Merging” do Core Data. No geral esses erros são vistos em aplicações multithread que utilizam o Core Data. E o Core Data é realmente complicado de trabalhar com esse tipo de aplicações.

Introdução

Em todos os casos que queremos utilizar o Core Data com multithread, é necessário manter um contexto (Managed Object Context) por thread. O contexto é a representação do banco de dados na memória, é como um rascunho onde todas as mudanças nos dados são feitas antes de ser guardadas no banco de dados (Persistent Store).

Portanto nós temos dois rascunhos independentes que podem gravar na base de dados em diferentes momentos e inevitavelmente algum conflito vai acontecer. Existem muitas técnicas que devem ser aplicadas para manter os dois rascunhos em sincronia, já que isso não acontece automaticamente. No geral é necessário criar algum tipo de notificação entre os diferentes threads e sincronizar os rascunhos para que estejam sempre iguais. Já vamos ter um artigo sobre o tema aqui no blog.

Soluções

Uma solução que é pouco utilizada porém muito poderosa é informar ao contexto como ele deve proceder no caso de encontrar conflitos. Vejamos em código:

[managedObjectContext setMergePolicy:NSMergeByPropertyStoreTrumpMergePolicy];

O contexto sempre vem configurado para gerar um erro (Exception) no caso de encontrar conflitos, no código acima estamos configurando o contexto para resolver os conflitos automaticamente sempre dando preferência para os dados que estão no rascunho que está gravando no momento.

Claro está que soluciona o problema por um lado, mas se a arquitetura de sua aplicação multithread não está bem pensada você irá perder dados importantes. Portanto habilite essa configuração e faça os testes necessários para estar seguro que os dados estão sendo gravados corretamente entre os diferentes threads.

Veja Core Data Merge Policies para saber as diferentes opções que você pode usar para configurar o seu contexto. Veja também Object Life-Cycle Problems e NSMergePolicy Class Reference.

Nunca é uma boa idéia instalar correndo a última versão do XCode, simplesmente para manter a compatibilidade com os seus projetos. O ideal é baixar a nova versão e instalar em uma pasta diferente. Mantendo assim as duas versões e gradualmente ir testando e verificando se a nova versão funciona corretamente com seus projetos.

Para saber o momento de desinstalar uma velha versão, é quando passou várias semanas sem abri-lá, já é o momento de despedi-la.

Como faço isso?

Por incrível que pareça, é muito, muito simples. O XCode vem com um script de linha de comando que desinstala facilmente todos os componentes ou somente alguns.

Esse script está nessa pasta:

pasta_xcode/Library/

E se chama:

uninstall-devtools

Esse script permite inclusive informar um parâmetro que define quais componentes queremos desinstalar. Para isso abrimos o Terminal e executamos os seguintes comandos:

cd pasta inicia/Library
sudo ./uninstall-devtools --help

O script irá listar as opções possíveis, escolha a que mais lhe convém. Por exemplo, para desinstalar todos os componentes:

sudo ./uninstall-devtools--mode=all

Quando o script finalizar, verifique que algumas pastas não foram deletadas. Em sua maioria são configurações. Verifique o que necessita desses arquivos, se não precisa deles. Pode deletar tranquilamente.

Realmente simples, com isso damos Adeus a versões antigas do XCode.

Esse artigo ilustra uma instalação básica do Tomcat 7 usando o Mac OS 10.6.4.

Pré-Requisitos

Essa versão do Mac OS já têm o Java Virtual Machine instalado, portanto não temos que preocupar-nos com ela. Você deve simplesmente baixar o Tomcat, para isso encontre a última versão nesse endereço: http://tomcat.apache.org/download-70.cgi.

• Copie o arquivo .zip no diretório que deseje instalar o Tomcat. Não há um lugar predefinido, sugiro a pasta de aplicações em /Applications/tomcat7.
• Descompacte (unzip) ess e arquivo dentro do pasta criada.

Iniciando o Tomcat Server

Os arquivos de inicialização do Tomcat estão na pasta ./tomcat7/bin. É necessário primeiro tornar os scripts executáveis. Para isso abra o Terminal e execute os seguintes comandos (substitua os diretórios se você usando outro que não o sugerido):

cd /Applications/tomcat7/bin
chmod ug+x *.sh

Logo após informamos ao Tomcat qual é o seu diretório inicial, com o seguinte comando:

export CATALINA_HOME=/Applications/tomcat7

Já estamos prontos para iniciar o Tomcat com o seguinte comando:

./startup.sh

Se não houver nenhuma mensagem de erro o Tomcat já está rodando. Para comprovar isso, abra o seu browser e coloque o endereço: http://localhost:8080/.

Uma imagem semelhante a abaixo deve aparecer:

Configurando usuários

Essa versão do Tomcat não vem com nenhum usuário configurado. Portanto devemos editar o arquivo de configurações. Para isso primeiro vamos parar o Tomcat (shutdown), para isso executamos o seguinte comando (lembre-se que os comandos de start e shutdown estão dentro do diretório bin):

./shutdown.sh

Agora vamos editar o arquivo de usuários, esse arquivo está em: /Applications/tomcat7/conf/tomcat-users.xml. Veja abaixo uma base de exemplo de configuração desse arquivo, você deve configurar os seus usuários e seus direitos (roles):

</div>
<div id="_mcePaste">tomcat-users</div>
<div id="_mcePaste">role rolename="tomcat"</div>
<div id="_mcePaste">role rolename="role1"</div>
<div id="_mcePaste">role rolename="manager-gui"</div>
<div id="_mcePaste">role rolename="manager-script"</div>
<div id="_mcePaste">role rolename="manager-jmx "</div>
<div id="_mcePaste">role rolename="manager-status"</div>
<div id="_mcePaste">user username="meuusuario" password="minhasenha" roles="manager-gui"</div>
<div id="_mcePaste">tomcat-users</div>
<div id="_mcePaste">

[/xml]

Muito bem, já temos o Tomcat funcionando e pronto para que possa colocar seus Servlets para rodar.

Uma dical final, é conveniente criar um script de start e outro de shutdown para economizar digitação se você tiver que reiniciar o Tomcat muito seguido, veja o conteúdo dos dois arquivos abaixo. Convém colocar esses arquivos no diretório /bin do Tomcat.

Script para start:

 #!/bin/sh export CATALINA_HOME=/Applications/tomcat7 $CATALINA_HOME/bin/startup.sh 

Script para shutdown:

#!/bin/sh
export CATALINA_HOME=/Applications/tomcat7
$CATALINA_HOME/bin/shutdown.sh

Não esqueça de tornar esses scripts executáveis usando o comando abaixo:

chmod ug+x |arquivo de start| |arquivo de shutdown|

Esse artigo dá continuidade ao conceito de key-value tratado em outros artigos.

NSUserDefaults é uma classe do Objective-C pensada para guardar valores de forma persistente em um lugar padrão para cada aplicação.

Em outras palavras o iOS se ocupa de manter determinado valor guardado, inclusive depois que a aplicação for fechada. Quando abri-la novamente esse valor estará lá para ser recuperado. Muito conveniente para guardar valores de settings, por exemplo.

Esse valores são guardados usando o conceito de key-value, ou seja, o valor é identificado por uma key para ser guardado e recuperado.

Alguns exemplos.

Nossos exemplos estão apontados para o uso em Cocoa Touch (iPhone, iPad, etc.), porém com algumas diferenças pode ser usado para Cocoa (Mac OS). Para cada aplicação uma instância geral do NSUserDefaults é criada automaticamente, portanto não temos que nos preocupar em alocar e iniciar uma nova.

Vamos pensar que temos uma aplicação de música e queremos guardar se o usuário têm o som em mute. Queremos que esse valor seja mantido inclusive se o usuário fechar a aplicação. Para isso temos o seguinte código:

[[NSUserDefaults standardUserDefaults] setObject:[NSNumber numberWithBool:YES] forKey:@"soundMuted"];

O método standardUserDefaults retorna essa instância geral que identifica nossa aplicação. E usamos o método setObject:forKey: para guardar algum valor. A classe NSUserDefaults cuida de todos os detalhes de persistência automaticamente, nesse momento se nossa aplicação for fechada, esse valor estará guardado para ser recuperado como no código abaixo:

BOOL muted = [[NSUserDefaults standardUserDefaults] boolForKey:@"soundMuted"];

No código acima recuperamos o valor, usando a key que o identifica. Note que estamos usando o método boolForKey: que retorna esse valor já convertido para o tipo BOOL. Esse método é por pura conveniência, já que se ocupa da conversão.

E já terminamos. Essa classe é tão simples e poderosa que o básico é assim de simples e fácil.

Esse é mais um artigo feito “a pedido”, bem bacana que o pessoal está colaborando e inclusive pedindo. Aliás, fiquem a vontade para comentar e pedir material. Para isso serve o blog.

Nesse artigo vou tratar a princípio sobre a teoria de armazenar dados baseado em keys (chaves) e depois exemplos de aplicação prática em Objective-C.

Vale lembrar que key-value storage se trata de um conceito, já que é independente de linguagem. Todas as linguagens modernas como Java, PHP, Python, Ruby, Objective-C entre outras tem alguma forma implementada de key-value storage.

O conceito é tão poderoso que bancos de dados baseados em key-value estão surgindo, como o Redis, mas isso é assunto para outro artigo.

Primeiro a teoria

Vamos imaginar uma pilha de dados (uma lista ou coleção) não ordenada. Cada elemento dessa coleção é armazenado e identificado por um elemento único: uma key (chave).

Podemos observar no gráfico acima essa idéia e afirmar os seguintes pontos referentes a uma coleção de key-value:

• Cada valor na coleção é identificado por uma key única, portanto não haverá duas keys iguais dentro de uma coleção.
• Tanto a key como o value podem ser de tipos diferentes (númerico, string, etc.).
• A ordem dos elementos não é importante. Apesar que algumas linguagens implementam coleções de key-value ordenadas.

Agora a prática

Vamos ver alguns exemplos práticos que irão ajudar a fixar o conceito. Em Objective-C uma coleção de key-value é chamada Dictionary e implementada nas classes NSDictionary e NSMutableDictionary.

As duas classes são iguais, a diferença entre elas é que NSDictionary uma vez instanciada não pode ser mutada, quer dizer, não se pode incluir ou remover elementos. E NSMutableDictionary sim. É possível converter um dicionário imutável em mutável criando uma cópia, para isso usamos o método mutableCopy como no código abaixo:

<br />
NSMutableDictionary *copiaMutavel = [instanciaImutavel mutableCopy];<br />

Vejamos como criar um dicionário, para isso usamos o seguinte código:

<br />
	NSString *key   = @&quot;fusca&quot;;<br />
	NSString *valor = @&quot;vermelho&quot;;</p>
<p>	NSMutableDictionary *colecao = [NSMutableDictionary dictionary];<br />
	[colecao setObject:valor forKey:key];<br />

O código acima cria uma instância do dicionário, e insere um valor identificado por uma key. Esse valor está guardado em nossa coleção, para pegar esse valor de volta usamos o seguinte código:

<br />
NSString *recuperado = [colecao objectForKey:@&quot;fusca&quot;];<br />

Vamos incluir em nossa coleção outros valores:

<br />
[colecao setObject:@&quot;número&quot; forKey:[NSNumber numberWithInt:23]];<br />
[colecao setObject:@&quot;verde&quot; forKey:&quot;chevette&quot;]<br />

Nossa coleção nesse momento está como na figura que vimos na parte teórica. Vale lembrar que as classes de Dicionário do Objective-C somente aceitam objetos como key ou value, variáveis não são aceitas.

Veja o artigo sobre NSUserDefaults para conhecer outras aplicações de key-value em Objective-C.

A pedido de meu irmão, vou tentar resumir o conceito de web services. Vale lembrar que esse artigo serve como “porta de entrada” para um conceito que é muito mais amplo. Portanto Google, Wikipedia, livros, blogs, são todos seus amigos. Quando pensar que o conceito está completo na cabeça… Procure um pouco mais! Afinal, nunca deixamos de aprender.

Para começar, um pouco de história

Não faz muito tempo, os programas eram mono-usuário e mono-tarefa, rodavam um por vez em sistemas operacionais como DOS. O seguinte passo foi a introdução de sistemas operacionais com interface gráfica como o Windows, os programas passaram a ser multi-tarefa e conectados em redes multi-usuários.

O próximo passo nessa evolução é o conceito de aplicações cliente-servidor, nesse modelo, uma aplicação se divide em uma parte de interação com o usuário (cliente) e outra de processamento e/ou armazenamento de dados (servidor). Esse padrão também permitiu que as duas partes passassem a residir em computadores (máquinas físicas) diferentes.

Com a necessidade de atender a arquitetura de negócios cada vez maiores, projetos de rede cada vez mais complexos foram criados em muitos casos vinculando sucursais de empresas em várias cidades ou mesmo países, entramos em uma era na qual as aplicações estão distribuídas e os processos se realizam em diferentes unidades. Sendo esse um  dos grandes motivos pelo qual nasceu a internet.

O ponto final para essa cronologia, são os web services. É um passo a frente em computação, já que nesse paradigma um computador já não se considera um núcleo de cômputo, senão um repositório de serviços de várias aplicações distribuídas em uma rede (em geral a internet).

Entendendo melhor o conceito

Vamos imaginar uma rede composta pelos servidores A, B e C. Cada servidor dispõe de diferentes serviços. Imaginemos que o servidor W dispõe de um serviço principal que é consumido por clientes em máquinas de sua rede local e também desenhado para servir a clientes que se conectem através da internet. Por sua vez esse serviço principal consome serviços de todos os outros servidores. O gráfico abaixo ilustra essa rede:

Nessa rede imaginária, não sabemos a localização física de cada servidor, não sabemos que tipo de servidor é (físico, virtual), não sabemos qual sistema operacional usam, qual aplicação está rodando ou qual linguagem essas aplicações foram desenvolvidas. Temos portanto muitíssimas possibilidades de combinações e é necessário uma solução padrão para que todos esses servidores, clientes e aplicações possam conversar.

Arquitetura de serviços

A primeira parte a entender de um conceito de web services, é a parte “services”. Devemos entender que as operações de um programa passam a ser pensadas como serviços. Um serviço pode ser uma consulta de cliente, uma entrada de dados (cadastro), entre tantas outras operações que um sistema pode fazer.

As aplicações são desenhadas para funcionar independente de seu entorno, elas não se conhecem. Em um modelo de programação tradicional, em um programa único, o programador sabe todas as funções, os diferentes arquivos de cada módulo, etc. e os chama diretamente. Em um arquitetura de serviços, os programas não se vinculam dessa forma. Eles simplesmente esperam receber uma requisição de um serviço, processam essa requisição e devolvem uma resposta.

A vantagem dessa desvinculação é que as aplicações podem ser divididas em diferentes servidores em lugares físicos ou virtuais. Podem ser aproveitados, substituídos ou modernizados sem afetar outras partes de um sistema geral.

Necessidade de padrões

Agora que começamos a entender a arquitetura. Surge uma grande questão:

Se todas essas partes de um sistema não se conhecem, como elas podem falar uma mesma língua? Como se comunicam?

Se comunicam pela parte “web” de web services, ou seja, os padrões definidos pela World Wide Web ou WWW.

O World Wide Web Consortium ao longo dos anos desde a abertura da internet homologou, definiu e amadureceu um conjunto de padrões e protocolos que permitem que milhões de sítios web funcionem em conjunto no que conhecemos como internet. Buscadores, redes sociais, blogs, sites de bancos, de música, de vídeos, de empresas e muitos outros se comunicam e permitem que possamos entrar em determinado sítio somente colocando um endereço em nosso browser. E em definitivo estamos consumindo serviços de diferentes aplicações em diferentes servidores que não temos idéia de onde estão ou como funcionam.

Portanto esses padrões são os adotados quando implementamos uma Arquitetura de Serviços baseada em padrões Web, mais curtinho: Web services !!

Os padrões

A internet é uma rede viva, a cada dia surgem novas tecnologias, muitas delas independentes e open-source, outras criadas por grandes companhias e adotadas por comunidades de desenvolvedores, algumas são aceitas e homologadas pelo WWW, outras não são homologadas, mas ainda assim são amplamente usadas, etc.

Nesse cenário a implementação de uma arquitetura de web services pode variar segundo as necessidades de cada projeto. Entretanto algumas tecnologias são as adotadas como standard na maioria das implementações. As bases são os protocolos de transporte que normalmente são HTTP, ou HTTPS para conexões seguras. O padrão XML é usado para formatar os dados e o protocolo SOAP para definir as especificações dos pacotes de dados que são transacionados pelo serviços.

Outros padrões são utilizados em aspectos específicos do transporte de dados, tais como segurança, parametrização de serviços, processos de publicação/pesquisa/descoberta, entre outros.

Como disse no começo do artigo, até aqui vimos apenas um pequeno pedaço de um todo que é cada vez maior e continua crescendo. Espero que seja um bom “pontapé” para buscar mais informações. Eventualmente voltarei a escrever outro artigo em um ponto mais específico do assunto.

Se você usa o Wikipedia, para uma consulta ou outra. Ou se você jogou sua Barsa no lixo e hoje em dia só faz pesquisa por ali esse post tem a ver com você.

O Wikipedia é mantido por uma fundação sem fins lucrativos. O Wikipedia não tem publicidade e não tem assinatura paga, ele é mantido por quem usa, contribuiu e consulta. Se você tem R$10 que não te farão falta, faça uma doação e ajuda a manter esse site vivo. Veja o apelo de Jimmy Wales, e os dados da Fundação Wikimedia para mais informações.

Dando continuidade a primeira entrega desse artigo, vamos falar um pouco

mais sobre Core Data.

Queries

Para os que conhecem sobre bancos de dados, a palavra query é muito comum.

Uma query é uma requisição de dados baseada em um filtro, ou seja, especificamos qual condição deve ser cumprida para extrair uma porção de dados de um conjunto maior. Por exemplo, temos os números 1, 2, 3, 4 e 5 (conjunto de dados). E queremos requerir somente os números menores que 3 (filtro), tendo como resultado 1, 2 (dados requeridos).

No Core Data essa requisição de dados (query) é chamada Fetch Request. Um Fetch Request pode ser formado de duas formas: Criando uma coleção de queries usando uma ferramenta visual do XCode, ou escrevendo uma query diretamente no código. Nesse artigo vamos fazer um passo-a-passo da primeira forma.

Criando uma Coleção de Fetch Requests

Cada elemento em uma Coleção de Fetch Requests é chamada Template. Esses templates serão chamados por nome diretamente no código posteriormente. Vejamos como criar um Template:

• Selecione a entity (tabela) que deseja criar o Fetch Request.
• Na pequena “flecha para baixo” no painel de atributos selecione Show Fetch Requests.

• O painel abaixo ilustra o editor de Fetch Requests, nele poderá editar o nome pelo qual será chamado no código e o predicate. Predicate é o filtro que especifica a condição de busca de um Fetch Request.

Uma das grandes vantagens de criar uma Coleção de Fetch Requests é o Predicate Builder. Ele permite de uma forma visual montar a lógica que compõe o filtro de um Fetch Request.

Vejamos como funciona:

O editor do Predicate Builder está formado por dois lados. Do lado esquerdo podemos selecionar os atributos (keys ou campos) da Entity que estamos trabalhando e associá-los do lado direito com valores fixos, valores dinâmicos ou com outros atributos (keys).

• Selecione do lado esquerdo do editor um atributo (key) que queremos usar para formar o Predicate. No campo central selecione que tipo de comparação queremos que tenha com o valor do lado direito.
• Do lado direito por default podemos selecionar um valor. Normalmente montamos um predicate com um valor variável que será enviado pelo código. Para mudar que tipo de valor ou atributo queremos do lado direito do painel, faça um clique com o botão direito e selecione no menu de contexto. É possível comparar valores com diferentes atributos (keys) e no caso de variáveis especificamos um nome de variável que será enviado pelo código posteriormente.
• Também podemos criar Fetch Requests com mais de complexidade adicionando novas linhas e compondo com operadores AND e OR. .

Espero que o conceito esteja claro nesse momento, usamos o editor do Core Data para montar Fetch Requests, tendo dessa forma uma Coleção de Templates que serão usados no código posteriormente.

Estamos nesse caso desvinculando o nosso Modelo de Dados (Model) do Código (Controller), a maior vantagem desse conceito é que podemos alterar condições lógicas de filtragem de dados sem tocar o código, também formamos um repositório que será aproveitado em várias partes do código.

Vejamos como usar esses templates no código:

O primeiro passo é carregar de nossa coleção um Template já montado:

[

<br />NSFetchRequest *query = [managedObjectModel<br />fetchRequestFromTemplateWithName:@"PessoasComIdadeMaior" substitutionVariables:[NSNumber numberWithInt:21]];<br />

O código acima carrega um Template chamado "PessoasComIdadeMaior". Estamos pensando que esse Template espera um valor do tipo numérico para compor o filtro. Portanto estamos informando o valor 21. Nesse momento ainda não fizemos a requisição, simplesmente montamos um objeto que compõe um Fetch Request. Comparando com o SQL, seria uma String com uma query formatada.

Agora vamos fazer o Request:

<br />
NSFetchRequest *query = [managedObjectModel fetchRequestFromTemplateWithName:&quot;PessoasComIdadeMaior&quot; substitutionVariables:[NSNumber numberWithInt:21]];<br />

O código acima, executa o Fetch Request, o Core Data nesse momento irá internamente consultar o SQLite (ou outro modo de persistência sendo usado) e retornar o resultado em um NSArray com objetos formatados.

O CoreData já formata os resultados do Fetch (query) como objetos que herdam da classe NSManagedObject.

Vejamos um exemplo de como poderíamos imprimir cada um desses elementos no Console de nossa aplicação.

for (id object in queryResult) {&lt;br /&gt;<br />
	NSLog( result.nomeDaPessoa )&lt;br /&gt;<br />
}&lt;br /&gt;<br />

O código acima, faz um loop sobre todos os elementos dentro do NSArray e imprime no Console a propriedade "nomeDaPessoa", essa propriedade é um campo do Banco de Dados (Entity) que fizemos o Fetch Request (query).

Nos próximos artigos sobre Core Data aprofundaremos um pouco mais nesse poderoso framework.

Esse é o primeiro artigo de uma série que irei escrever sobre Core Data.

Core Data é um Framework do Cocoa dedicado a gerenciar e armazenar dados em uma base persistente (SQL, XML ou Binary). É formado por um conjunto de Classes (veja gráfico abaixo) divididas em funções de Modelagem, Controle de Dados no Runtime e Queries. Formando um ecosistema completo para administração de dados.

Um ponto a aclarar, que geralmente leva a certa confusão. Core Data não é um banco de dados, é um Object-Relational Mapping, isso quer dizer que é uma camada em cima de um banco de dados. Essa camada abstrae os comandos de um banco de dados (queries) a um paradigma de OOP.

Portanto ao invés de fazer queries para deletar uma linha, ou updates para alterar um valor. Deletamos um objeto que representa um registro ou atualizamos uma propriedade desse objeto.

Vantagens.

Desvantagem.

• Não é possível usar modelagem de dados externas, bancos de dados já existentes ou importar dados sem usar rotinas de importação especialmente escritas. O Core Data cria o banco de dados baseado no modelo criado no XCode e o gerencia.

Nomenclaturas.

Para entender melhor as nomenclaturas do Core Data em relação ao SQL, vejamos algumas equivalências na tabela abaixo (Tenhamos em conta que são apenas equivalências para entender melhor cada elemento, não funcionam exatamente da mesma forma.).

Exemplos.

Usando a ferramenta de modelagem do XCode criamos uma tabela (Entity). O resultado é o que mostra o gráfico abaixo.

Com esse modelo o XCode automaticamente pode criar o banco de dados SQLite (ou outro tipo) e a Classe que controla os dados dessa tabela.

Abrir o Banco de Dados.

<br />// Inicia o BD.<br />NSManagedObjectContext *database = [self managedObjectContext];<br />

Query de dados.

<br />// Alocamos uma instância da Classe que fará o Query (NSFetchRequest). (SELECT)<br />NSFetchRequest *query = [[NSFetchRequest alloc] init];<br /><br />// Configura para carregar toda a tabela.<br />[query setReturnsObjectsAsFaults:NO];<br /><br />// Associamos a qual tabela este Fetch fará o Query.<br />[query setEntity:[NSEntityDescription entityForName:@"Agenda" inManagedObjectContext:database]];<br /><br />// Executa o Fetch, recebendo os dados diretamente em um Dataset (NSMutableArray).<br />NSMutableArray *resultadoQuery = [[database executeFetchRequest:query error:&error] mutableCopy];<br /><br />// Podemos perceber o poder e a conveniência do Fetch nesse caso.<br />// Veja que ele devolve o resultado diretamente em um Array<br />// Imprime no Console diretamente.<br />NSLog( resultadoQuery );<br />

Neste caso estamos montando um Fetch programaticamente. Em um projeto maior o mais comum é criar todos os Fetchs necessários usando a ferramenta gráfica de Edição de Predicados. Desta forma portanto, somente é necessário associar esse template já criado para fazer determinada consulta.

Inserção de dados.

<br />// Cria um novo registro. Esse registro não será gravado no BD por enquanto.<br />Agenda *novoRegistro = (Agenda *)[NSEntityDescription insertNewObjectForEntityForName:"Agenda" inManagedObjectContext:database];<br /><br />// Monta os dados que serão gravados.<br />novoRegistro.nome = "Narques Oliveira";<br />novoRegistro.telefone = NSDouble( 08001050 );<br /><br />// Guarda no BD. (COMMIT)<br />[database save:&error];<br />

O Core Data mantém os dados na memória até que o método save: seja chamado. Algumas razões para que funcione desa forma: habilitar a possibiloidade de utilizar a API de undo e redo, manter os dados guardados em uma janela de edição (cadastro) até que o usuário confirme as mudanças sem criar nenhuma linha de código, entre outras. Todas essas conveniências já estão embutidas no Core Data.

Remoção de dados .

Vamos obervar que a remoção de um item no Core Data difere um pouco de uma forma convencional do SQL. No SQL passamos ao Banco de Dados um Query com os dados a deletar diretamente. Pela forma que o Core Data funciona internamente ele não permite a deleção de dados baseadas em Queries. O que devemos fazer é deletar um registro (ou um conjunto de registros) da memória e depois chamar o método save: para que ele faça o trabalho de remover esses registros da tabela (Entity) e todos os que tiverem um Relacionamento com eles.

Para deletar o conteúdo de uma tabela inteira, por exemplo. Seria necessária fazer um Fetch de todos os elementos da tabela; Deletar todas as linhas; Executar o save:.

É uma desvantagem no caso de uma tabela única e uma vantagem no caso de uma tabela master, pois essa ação simples deletará de forma segura todos os elementos que dependem dela seguindo o Relacionamento que respeitem.

No caso de remover apenas um item, é mais comum que deletemos o objeto que estamos trabalhando ou que está visualmente na tela. Afinal uma ação de deletar quase sempre é iniciada pelo usuário diretamente nos dados que estamos trabalhando no momento.

<br />// Obtemos a referência de um registo para deletar, neste caso estamos pedindo o registro guardado na linha 1 do Dataset.<br />NSManagedObject *registroParaDeletar = [resultadoQuery objectAtIndex:1];<br /><br />// Deleta o registro. Não foi deletado da tabela ainda.<br />[database deleteObject: registroParaDeletar];<br /><br />// Guarda no BD. (COMMIT)<br />[database save:&error];<br />

A remoção de objetos nesse caso é de um item simplesmente. Em Modelos de Dados mais complexos a remoção de um item segue os Relacionamentos montados. Portanto é possível fazer uma Deleção em Cascata, ou seja, deletar um item e todos os que dependem dele de forma automática.

Nos próximos artigos sobre Core Data aprofundaremos um pouco mais nesse poderoso framework.

Veja mais em Core Data Parte II.