juliocbq:
ricardobocchi:
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.
Alguns gb em comparação com dezenas de teras é um coisa simples sim. O sqlite foi desenvolvido para trabalhar com embarcados e por isso é simples.
A opção de usar o xml é o que você mesmo acabou de dizer, pois vai apenas guardar coisas simples. Por isso perguntei sobre as vantagens do framework em relação a custo benefício.
Sobre a aplicação rodar em background não tem relação com consumo de energia. O que dita isso é a quantidade de instruções que você joga no processador. No caso está intimamente relacionada com o processamento e logicamente voltamos a questão de ser vantagem ou não usar framework de persistência em dispositivos com poder de processamento, memória e energia limitados.
Então, o que venho querendo dizer é que o beneficio dele é exatamente a facilidade para implementação da camada de persistência e a facilidade na menutenção. A questão bateria é impôrtante sim, por isso mesmo deve ser pesado se é valido o uso do framework no projeto ou não. No meu caso, foi muito válido, sendo que a questão de bateria e desempenho não me forçaram a abandonar os recusros do framework, em meus projetos o preço pago foi o esperado. Tenho aplicações com centenas de registros em tabelas, como nunca processo tudo de uma vez só, não tive maiores problemas. Sempre uso recursos de paginação e lazy para recuperar somente o que realmente preciso. Certamente não vou dizer que o framework aumenta desepenho e aumenta o tempo de vida da bateria, por que isso é irreal, mas como em meus projetos dou um peso diferênciado para produtividade, manutenção e facilidade no CRUD, acredito que sempre saí ganhando.
Baseando-se em um framework como Hibernate, teriamos a mesma discussão, pois ele também cobra um preço bem alto na aplicação, em complexidade e desempenho. Mesmo tendo servidores com grande poder de processamento, para obtermos um bom nível de desempenho, temos que “tunar”, muitas vezes usar SQL’s nativas, pois toda camada que é adicionada para facilitar o trabalho degrada a performance. Tem muita gente que não usa ORM, pois acha “gambiarra” como tem muitos outros que gostam da ideia, isso vai de projeto para projeto.
Agora se considerar que o desempenho e uso de bateria devem passar por cima da produtividade, então não tem benefícios. Por que ele é pensando em produtividade e tenta usar o mínimo de recursos possíveis para se manter, mas mesmo sendo o mínimo, é maior que nada. A questão é: Se você precisa saber exatamente o que está acontecendo em todo o trexo de código da aplicação, você deve optar em usar a API nativa do Android para SQL’s, ou usar XML, como preferir. Se quiser ter maior flexibilidade e facilidade na manipulação da api de acesso a dados, você coloca o Veloster como uma camada intermediaria.
Mas o que todos querem ouvir é o que todo mundo já sabe, se comparado a API nativa com o Veloster perde em desempenho e uso de bateria, e não preciso nem fazer testes para saber isso, pois ele é uma camada intermediaria entre sua aplicação e a API de acesso a dados do Android. Seria a mesma coisa comparar o codigo que roda na vm do android com o código nativo que vai pro processador, mesmo assim, com a perda de desempenho e uso de recursos, eles decidiram usar uma linguagem de alto nível como Java para facilitar a vida do desenvolvedor. Então, tudo é uma questão de custo X benefício.
