[quote=juliocbq][quote=ricardobocchi][quote=Ataxexe]ricardobocchi, eu entendo sua vontade de defender o framework. Mas o que estamos questionando não é funcionalidade nem persistência ou lazy loading. Estamos questionando os motivos de se fazer isso no dispositivo em vez de fazer um serviço restfull ser consumido no dispositivo.
Pensando no mundo corporativo, se o cara tem um smartphone mas não pode conectar em uma rede wireless na corporação, tem algo de errado. Claro que algumas informações podem ser gravadas offline (quando o usuário não está na rede da empresa, por exemplo), mas elas seriam enviadas posteriormente para o serviço. Por causa disso não seria tão interessante fazer uma persistência com framework pois um dump da informação pode ser feito pra então ser mandado ao serviço.
São coisas como essa que estamos querendo debater.[/quote]
Sim Ataxexe, eu entendo o que você está querendo dizer, e o que eu estou dizendo é exatamente o que você está entendo. O ganho dele é exatamente isso! Produtividade. Se para suas aplicações isso não é um ganho, então você não deve usar. Só acho que nem toda aplicação vai ter um servidor para fazer o processamento, tem muitas aplicações que geram arquivos e mandam para um outro sistema a informação pronta. Também tem a questão da internet, que em muitos lugares é ruim de mais ou inexistente e os planos são carissimos. Se você obrigar o cliente a ter internet ilimitada ou um servidor dedicado, já está reduzindo suas possibilidades.
O framework te ajuda a fazer uma coisa que você é obrigado a fazer, apenas isso! Ou seja, obrigatóriamente você terá que manipular dados e certamente você vai cuidar para que essa manipulação de dados não seja exagerada, O framework não vai ficar executando um processo infinito ocupando toda bateria, memória e processamento do aparelho. Ele apenas vai facilitar a persistência e combrar seu preço por isso. No lugar de você fazer um:
Você vai fazer
A ideia é simples e sem grandes pretenções. Apenas facilitar o desenvolvimento! Como já disse e volto a repetir, nos projetos que trabalhei ele sempre foi uma mão na roda, por esse motivo ele está sendo compartilhado, se ele foi útil para os projetos da minha empresa, pode ser útil para outros projetos. Seu uso é extremamente simples, sem grandes complicações. Em poucos passos você já tem seu CRUD.
[/quote]
É nesse ponto que eu queria chegar. O sqlite foi concebido para ser extremamente simples e não precisar desse tipo de solução. Ele é desenvolvido para guardar coisas simples como listas, etc…
Essa informação toda nem precisa ser gravada em um banco, pode ser serializada em um arquivo xml.
Pode parecer que não, mas a questão da bateria é extremamente importante.[/quote]
Bom, nesse caso você está optando por trabalhar com outro forma de armazenamento. Se em seu projeto ela for mais conveniênte, então ela deve ser a melhor opção para você. E na verdade o SQLite não é tão simples não, ele tem um grande poder de armazenamento suportando varios GB. Na dúvida, dê uma olhada em http://pt.wikipedia.org/wiki/SQLite
E aposto que muitos desenvolvedores preferem SQL do que XML, a final entre acesso a disco em um XML ou SQLite, ainda fico com SQLite que é um banco de verdade e é muito mais simples de manipular. E outra, seguindo a discussão, o Veloster seria um possível gargalo em uma volumosa manipulação de dados, mas como sabemos, em um dispositivo limitado temos que armazenar só o necessário, reduzingo ao máximo a quantidade de dados, isso independênte do seu uso ou não. Então, se a manipulação de dados for grande, com Veloster ou sem Veloster, vai ser um gargalo. E quanto a bateria, tenho aplicações que rodam em background em celulares, e o uso da bateria é considerada dentro do normal. Então voltamos ao ponto inícial, onde tudo vai depender do objetivo da aplicação.
