Veloster Framework - Persistência de dados para Android

Venho através desse tópico divulgar o projeto Veloster Framework, que se destina a persistência de dados em ambiente Android. O Veloster Framework já está sendo usado em alguns projetos e até o momento apresentou estabilidade e muitos recursos interessantes. O projeto já existe a mais de um ano, porém apenas agora ele está sendo divulgado publicamente, pois suas primeiras versões sofreram grandes modificações. Esse framework é desenvolvido pela Mobile Mind Empresa de Tecnologia www.mobilemind.com.br, que já conta com outros projetos Open Source www.mobilemind.com.br/openMind.

O projeto está licenciado sob a licensa GNU GPL V2. Projeto no google code https://code.google.com/p/veloster/

Algumas de suas funcionalidades são:

* Funciona em ambientes Desktop e Android
* API de Criteria
* API de validação
* Dynamic Finder
* Controle transacional
* Cascade
* Lazy Load
* Anotações
* Criação e Atualização de tabelas e campos
* Backup/Restore Integrado
* Natite SQL
* Result Transformer 

Mais detalhes do projeto, como exemplos e documentação podem ser encontrados em http://www.4minds.com.br/engine/show/26. Dúvidas, problemas e abertura de FAQ podem ser reportados diretamente em www.4minds.com.br.

Bacana!

Uma dúvida: existe a possibilidade de configurar a persistência sem anotações? Pergunto isso porque, em versões mais antigas do Android (se não me falha a memória, da 2.2 pra trás), usar Anotações em runtime tente a ser muito lento (por conta de uma implementação tosca do método getAnnotations).

Olá,

A única forma de cofiguração é por anotações mesmo.

[quote=ricardobocchi]Olá,

A única forma de cofiguração é por anotações mesmo.[/quote]

Uma pena…mas fica a dica :wink:

Claro. O projeto está em desenvolvimento e constantemente sendo melhorado. Se o o beneficio de ter outra maneira de configuração valer a pena, pode ser implementado em futuras versões.

Com certeza.

Me lembro de ter lido sobre isso quando estava usando o AndroidAnnotations, eles tiveram uma grande sacada de criar anotações que eram interpretadas em tempo de compilação pra gerar classes derivadas com as funcionalidades estaticamente codificadas em vez de usar códigos dinâmicos com reflexão. O resultado é que praticamente não há diferença de desempenho e o trade off é usar classes com “_” no final no android manifest.

Talvez você possa usar uma abordagem de separar os componentes com uma API pra se configurar e um componente que faz a configuração baseado em anotações e outro que o faz via arquivo ou algo do tipo (semelhante ao hibernate).

No mais, parabéns pelo projeto!

Muito bom!

Minha dica é usar APT (http://docs.oracle.com/javase/1.5.0/docs/guide/apt/GettingStarted.html) para gerar código em tempo de compilação e usar menos reflexão!

O interessante é seguir o padrão do JPA, pois ficaria mais simples para quem já usa o mesmo hoje utilizar seu framework!

Veja os códigos do Dagger (http://square.github.com/dagger/). É um framework IOC para Android que usa reflexão.

Valeu.

Minha opnião.
Desnecessário o uso de xml para configuração em vez de annotations. Celulares hoje com Android com versão inferior a 2.2 é quase nula, se não nula. Adaptar o framework para isso seria perder tempo.

[quote=MauNunes]Minha opnião.
Desnecessário o uso de xml para configuração em vez de annotations. Celulares hoje com Android com versão inferior a 2.2 é quase nula, se não nula. Adaptar o framework para isso seria perder tempo.[/quote]

Ainda temos cerca de 13% de dispositivos rodando Android 2.2 ou inferior, então é algo a se preocupar pra quem faz aplicativos de ampla visibilidade.

E usar reflexão anula o JIT, o que significa perder um pouco em desempenho. No caso de dispositivos móveis, pode significar um consumo maior de bateria. Por isso o pessoal do AndroidAnnotations optou por usar anotações em tempo de compilação pra gerar código a partir delas. Seria muito bom se o Veloster pudesse usar uma abordagem como essa, mesmo que híbrida. Isso iria dar uma boa otimizada no framework.

Outra coisa: em momento algum eu disse que seria usada configuração via xml. Muita gente prefere usar configuração programática e isso pode atrair mais gente ainda. Não há nada demais em ter um componente pra configurar a persistência e outro pra automatizar a configuração. Dessa forma você flexibiliza mais a solução.

O Veloster tem sido testado a partir da versão 2.2 do Android, como o MauNunes disse o número de usuários de versões anteriores é pequeno e tende a dimnuir ainda mais. E como eu disse, o framework está em desenvolvimento e estamos sempre pensando em melhorias, então toda opinião e dica é válida! Quanto as anotações, acredito que não seria um grande diferencial de desempenho fazer de outra maneira, por que elas são processadas sob demanda e ficam armazenadas em cache, e o uso da reflexão é bem maior para criação dinamica de objetos, criterias e dynamic finders. Até o momento não tivemos problemas com desempenho, até por que sabemos que uma aplicação para celular não pode nascer com o objetivo de processar grandes quantidades de dados. Então até agora os custos (uso de memória, espera) valeram os beneficios (produtividade, facilidade, códigos mais legiveis). Nã vou dizer que é melhor framework que existe, pois com certeza tem seus problemas, mas se analisarem, verão que ele tem muitos recursos interessantes de “gente grande” que facilitam e muito nosso dia-a-dia.

Já respondendo para o jrdalpra, a maioria das anotações tem os mesmos nomes e padrão do Java Persistence API. O número de anotações é bem reduiza se comparado ao JPA, e como o framework não é pra ser um cópia, e sim trazer alguma coisa diferênciada, ele não segue o mesmo padrão engessado do JPA.

[quote=jrdalpra]Muito bom!

Minha dica é usar APT (http://docs.oracle.com/javase/1.5.0/docs/guide/apt/GettingStarted.html) para gerar código em tempo de compilação e usar menos reflexão!

[/quote]

Apenas para avisar que o apt foi deprecated e será removido. Em vez disso, o processamento de anotações acontece com a JSR 269

Tentei baixar o framework pelo link https://code.google.com/p/veloster/ e me parece estar com algum problema.

Edson

Olá Edson,

Você pode encontrar as dependências para download aqui http://www.4minds.com.br/artigo/show/27 e a referência para uso aqui http://www.4minds.com.br/artigo/show/26

[quote=Ataxexe][quote=ricardobocchi]Olá,

A única forma de cofiguração é por anotações mesmo.[/quote]

Uma pena…mas fica a dica :wink: [/quote]
É uma pena mesmo já nascer só com mapeamento gambiarra.

Mas qual a vantagem de usar persistência de dados em um dispositivo com hardware limitado como telefones e tablets? Já é barra conseguir desempenho em servidores com memória de sobra. Em telefones o custo seria muito consumo de bateria como citaram acima, congelamento do sistema, etc…

Qual a vantagem desse framework para dispositivos que foram projetados para serem “clientes”?

[quote=juliocbq]Mas qual a vantagem de usar persistência de dados em um dispositivo com hardware limitado como telefones e tablets? Já é barra conseguir desempenho em servidores com memória de sobra. Em telefones o custo seria muito consumo de bateria como citaram acima, congelamento do sistema, etc…

Qual a vantagem desse framework para dispositivos que foram projetados para serem “clientes”?[/quote]
Boa pergunta, eu nunca desenvolvi nada nativo para mobile, mas os casos que já vi não usaram nenhum framework de persistência, falaram que é até mais gostoso de desenvolver sem parafernálias.

[quote=juliocbq]Mas qual a vantagem de usar persistência de dados em um dispositivo com hardware limitado como telefones e tablets? Já é barra conseguir desempenho em servidores com memória de sobra. Em telefones o custo seria muito consumo de bateria como citaram acima, congelamento do sistema, etc…

Qual a vantagem desse framework para dispositivos que foram projetados para serem “clientes”?[/quote]

Olá juliocbq,

Se você deu uma olhada nas funcionalidades do framework, você verá os beneficios que ele oferece quando falamos em legebilidade de código, produtividade e facilidade. Com certeza, como qualquer outro framework, ele cobra seu preço no desempenho, mas como já comentei, até o momento em meus projetos foi um preço baixo a se pagar. Se você acha que não vale a pena usar um framework de persistência em um dispositivo móvel, eu não vou discutir, acho que cada umdeve escolher seus caminhos de desenvolvimento como acha melhor. Esse projeto foi disponibilizado para quem se interessar em usar, é gratuito e já tem algumas empresas usando, então acho que alguns desenvolvedores podem ver seus beneficios e estão dispostos a pagar o preço pelo seu uso.

E quando você fala em dispositivos para “Clientes”, estamos falando em processadores dual ou quad core, com muita memória, muitas vezes melhor do que o pc de mesa que temos em casa. E se colocarmos no jogo a internet no Brasil, percebemos que é quase inevitavel desenvolver um aplicativo que trabalhe off-line e tenha que manipular uma quantidade minima de dados, ainda mais quando falamos no mundo corporativo.

[quote=javaflex][quote=Ataxexe][quote=ricardobocchi]Olá,

A única forma de cofiguração é por anotações mesmo.[/quote]

Uma pena…mas fica a dica :wink: [/quote]
É uma pena mesmo já nascer só com mapeamento gambiarra.[/quote]

Olá javaflex,

Que bom que o assunto chamou sua atenção. Respeito sua opinião, mesmo ela sendo bem vaga. Há muitos outros tópicos de discusão sobre uso ou não uso de anotações, acho que esse assunto de “gambiarra” ficaria melhor em um desses tópicos. Anotações são uma especificação java, se é gambiarra ou não, é um padrão e ponto final! Sempre fui adepto de anotações no lugar de arquivos xml, mas cada qual tem sua opinião e preferência. E além do mais, ninguém está te apontando uma arma na cabeça para você usar o Veloster, é apenas uma questão de escolha.

Acho que só é válido tocar nesse ponto se seu aplicativo for específico para somente um dispositivo (talvez no caso de uma aplicação corporativa para os smartphones de última geração dos gerentes). Em aplicativos para uma ampla gama de dispositivos isso é algo que nem deve ser pensado.

Outro ponto: acho que comparar os processadores de smartphones de última geração com processadores de desktops pré-históricos não vem ao caso. Quem tem um smartphone bom dificilmente terá um desktop ruim a ponto de ter o desempenho (relativo, claro) inferior ao do smartphone.

Eu acho que o Veloster pode ter, sim, seu lugar no mercado. Mas somente para apps bem específicos para dispositivos bem específicos, o que torna esse mercado muito restrito.

[quote=ricardobocchi][quote=juliocbq]Mas qual a vantagem de usar persistência de dados em um dispositivo com hardware limitado como telefones e tablets? Já é barra conseguir desempenho em servidores com memória de sobra. Em telefones o custo seria muito consumo de bateria como citaram acima, congelamento do sistema, etc…

Qual a vantagem desse framework para dispositivos que foram projetados para serem “clientes”?[/quote]

Olá juliocbq,

Se você deu uma olhada nas funcionalidades do framework, você verá os beneficios que ele oferece quando falamos em legebilidade de código, produtividade e facilidade. Com certeza, como qualquer outro framework, ele cobra seu preço no desempenho, mas como já comentei, até o momento em meus projetos foi um preço baixo a se pagar. Se você acha que não vale a pena usar um framework de persistência em um dispositivo móvel, eu não vou discutir, acho que cada umdeve escolher seus caminhos de desenvolvimento como acha melhor. Esse projeto foi disponibilizado para quem se interessar em usar, é gratuito e já tem algumas empresas usando, então acho que alguns desenvolvedores podem ver seus beneficios e estão dispostos a pagar o preço pelo seu uso.

E quando você fala em dispositivos para “Clientes”, estamos falando em processadores dual ou quad core, com muita memória, muitas vezes melhor do que o pc de mesa que temos em casa. E se colocarmos no jogo a internet no Brasil, percebemos que é quase inevitavel desenvolver um aplicativo que trabalhe off-line e tenha que manipular uma quantidade minima de dados, ainda mais quando falamos no mundo corporativo.[/quote]

Em nenhum momento eu coloquei a questão “gosto” na pergunta.

Só gostaria de saber algumas vantagens em usar um framework de persistência em um dispositivo que suporta somente “uma” database que é o sqlite.