Então você está afirmando que se eu usar o Veloster em uma aplicação eu vou ter um maior consumo de bateria a ponto de não ser uma vantagem utiliza-lo? Afinal é disso que eu estou falando, não devemos comparar o caso da utilização de um serviço Restful/Aplicação Web VS Aplicação nativa usando veloster… A comparação a ser feita deve ser Aplicação Nativa sem veloster VS Com… Na minha opinião são nichos diferentes e devem se tratados como tal…
[quote=juliocbq][quote=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.[/quote]
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.[/quote]
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.
Concordo com você. Sobre a questão da bateria eu a levantei porque realmente é um ponto a se conversar sobre. Existem bibliotecas que fazem processamento de imagem intensivo, com filtros complexos(detectar e reconhecer formas geométricas e rostos) e o custo de energia também é aceitável. Eu não acredito que um framework de persistência consumiria mais que elas.
A questão de produtividade também é importante.
A pergunta (que você respondeu em parte com o caso do sistema de pedidos) era porque usar isso no dispositivo em vez de usar no servidor e porque seria melhor que possíveis alternativas (como o dump que eu citei). É bacana você mostrar isso pra justamente convencer mais pessoas a usarem o framework.
No caso da sua resposta. Eu posso ter o mesmo ganho em produtividade se eu usar o servidor pra fazer essas coisas e um serviço rest. O ponto é: por quê eu irei precisar de algo que vá contra a filosofia da simplicidade do sqlite e onerar o dispositivo com operações que um serviço externo pode fazer (representando uma economia de bateria)? É uma pergunta que as pessoas vão ter quando olharem a premissa do framework.
Eu tirei algumas conclusões sobre ele, tanto que afirmei que ele tinha um mercado restrito. Eu gostaria de ter visto mais debates sobre as alternativas frente ao Veloster e não ao que o Veloster me oferece (que já tinha sido citado antes).
O ponto da bateria é muito crítico (na PlayStore muitas pessoas reclamam sobre o consumo de bateria de alguns apps). As pessoas não compram um smartphone pra usar somente um aplicativo, então não podemos assumir que os 1 GB e 4 processadores do celular estarão lá só pro nosso app, isso tudo será compartilhado entre muitos outros serviços. O simples fato de ignorarmos as permissões de leitura de chamada (para pausar alguma coisa no app caso o usuário receba uma ligação, por exemplo) já pode botar aplicativo lá embaixo.
Não estou querendo gerar flames, acho legal a iniciativa (como eu já havia dito no início do post), dei algumas dicas, mas fiquei com algumas dúvidas e achei que a melhor pessoa pra me responder seria o criador da ferramenta, mas não esperava ler isto:
Por que não? Estou sendo realista. Acho que seu uso não é tão restrito, acredito que a maioria das aplicações faz uso de banco de dados. O caso do pedido off-line mostra que além de ter boa parte da regra de negócio na app, também vamos ter boa parte dos dados localmente. O fato é que se você acha que não vale a pena usar uma camada entre sua aplicação e a api de acesso a dados, dificilmente vou fazer você mudar de ideia, e também esse não é meu objetivo. Sim, eu quero que as pessoas usem, até por que coloquei muitas horas de desenvolvimento nesse framework, mas não quero “convencer” ninguém a usar, e sim que quem estiver interessado e achar que pode ter algum ganho, use ele. Vou ser bem honesto, acho que é quese impossível fazer um framework simples e útil que não cobre seu preço no desempenho.
E certamente estamos ai para criticas e sujestões, caso contrario o framework estaria apenas em uso interno. Não estou dizendo que ele vai ocupar todos os recursos do dispositivo, mas também não será tão rápido quanto não usar.
A pergunta (que você respondeu em parte com o caso do sistema de pedidos) era porque usar isso no dispositivo em vez de usar no servidor e porque seria melhor que possíveis alternativas (como o dump que eu citei). É bacana você mostrar isso pra justamente convencer mais pessoas a usarem o framework.
No caso da sua resposta. Eu posso ter o mesmo ganho em produtividade se eu usar o servidor pra fazer essas coisas e um serviço rest. O ponto é: por quê eu irei precisar de algo que vá contra a filosofia da simplicidade do sqlite e onerar o dispositivo com operações que um serviço externo pode fazer (representando uma economia de bateria)? É uma pergunta que as pessoas vão ter quando olharem a premissa do framework.
Eu tirei algumas conclusões sobre ele, tanto que afirmei que ele tinha um mercado restrito. Eu gostaria de ter visto mais debates sobre as alternativas frente ao Veloster e não ao que o Veloster me oferece (que já tinha sido citado antes).
O ponto da bateria é muito crítico (na PlayStore muitas pessoas reclamam sobre o consumo de bateria de alguns apps). As pessoas não compram um smartphone pra usar somente um aplicativo, então não podemos assumir que os 1 GB e 4 processadores do celular estarão lá só pro nosso app, isso tudo será compartilhado entre muitos outros serviços. O simples fato de ignorarmos as permissões de leitura de chamada (para pausar alguma coisa no app caso o usuário receba uma ligação, por exemplo) já pode botar aplicativo lá embaixo.
Não estou querendo gerar flames, acho legal a iniciativa (como eu já havia dito no início do post), dei algumas dicas, mas fiquei com algumas dúvidas e achei que a melhor pessoa pra me responder seria o criador da ferramenta, mas não esperava ler isto:
Por que não? Estou sendo realista. Acho que seu uso não é tão restrito, acredito que a maioria das aplicações faz uso de banco de dados. O caso do pedido off-line mostra que além de ter boa parte da regra de negócio na app, também vamos ter boa parte dos dados localmente. O fato é que se você acha que não vale a pena usar uma camada entre sua aplicação e a api de acesso a dados, dificilmente vou fazer você mudar de ideia, e também esse não é meu objetivo. Sim, eu quero que as pessoas usem, até por que coloquei muitas horas de desenvolvimento nesse framework, mas não quero “convencer” ninguém a usar, e sim que quem estiver interessado e achar que pode ter algum ganho, use ele. Vou ser bem honesto, acho que é quese impossível fazer um framework simples e útil que não cobre seu preço no desempenho.
E certamente estamos ai para criticas e sujestões, caso contrario o framework estaria apenas em uso interno. Não estou dizendo que ele vai ocupar todos os recursos do dispositivo, mas também não será tão rápido quanto não usar.[/quote]
Leia de novo sua frase. Parece que se eu não usar o Veloster é porque eu não acho que produtividade é um ganho. Sendo que existem muitas outras formas de ser produtivo em dispositivos móveis. O Veloster não é a única coisa produtiva no mundo Android e sua frase deu a entender isso. Você só precisava argumentar em cima da alternativa de dump ou serialização em vez de armazenar no sqlite (benchmarks seriam legais pois de repente o custo é o mesmo pra determinado volume de informações - o que seria ideal pra você mostrar o quanto seu projeto é interessante).
Bom, cansei. Temos outro Prevayler: um projeto interessante, mas defendido de forma errada.
[quote=Ataxexe]
Leia de novo sua frase. Parece que se eu não usar o Veloster é porque eu não acho que produtividade é um ganho. Sendo que existem muitas outras formas de ser produtivo em dispositivos móveis. O Veloster não é a única coisa produtiva no mundo Android e sua frase deu a entender isso. Você só precisava argumentar em cima da alternativa de dump ou serialização em vez de armazenar no sqlite (benchmarks seriam legais pois de repente o custo é o mesmo pra determinado volume de informações - o que seria ideal pra você mostrar o quanto seu projeto é interessante).
Bom, cansei. Temos outro Prevayler: um projeto interessante, mas defendido de forma errada.[/quote]
Desculpe se me expressei mal, mas não foi a intenção dizer que ele é a meneira mais produtiva do mundo e sim seguir o raciocinio do uso ou não uso do Veloster, que no caso, está implicito no tópico. Você pode sim ser produtivo de diversas maneiras, e o Veloster é uma delas. Não é por que a discussão ficou “calorosa” que o projeto está sendo defendido de maneira errada e sim que ele é interessante o suficiente para gerar uma boa lista de discussão. Acredito que todas as ideias expostas foram entendidas, e isso é muito válido.
[quote=ricardobocchi][quote=Ataxexe]
Leia de novo sua frase. Parece que se eu não usar o Veloster é porque eu não acho que produtividade é um ganho. Sendo que existem muitas outras formas de ser produtivo em dispositivos móveis. O Veloster não é a única coisa produtiva no mundo Android e sua frase deu a entender isso. Você só precisava argumentar em cima da alternativa de dump ou serialização em vez de armazenar no sqlite (benchmarks seriam legais pois de repente o custo é o mesmo pra determinado volume de informações - o que seria ideal pra você mostrar o quanto seu projeto é interessante).
Bom, cansei. Temos outro Prevayler: um projeto interessante, mas defendido de forma errada.[/quote]
Desculpe se me expressei mal, mas não foi a intenção dizer que ele é a meneira mais produtiva do mundo e sim seguir o raciocinio do uso ou não uso do Veloster, que no caso, está implicito no tópico. Você pode sim ser produtivo de diversas maneiras, e o Veloster é uma delas. Não é por que a discussão ficou “calorosa” que o projeto está sendo defendido de maneira errada e sim que ele é interessante o suficiente para gerar uma boa lista de discussão. Acredito que todas as ideias expostas foram entendidas, e isso é muito válido.[/quote]
Entendo. Sem prooblemas.
Uma boa opção pra você é fazer algum benchmark utilizando o volume de dados processados como parâmetro. Acredito que pode mudar a concepção de muita gente sobre o uso da ferramenta.
E ai pessoal…
Realizamos o benchmark do Veloster, vocês podem conferir os resultados em http://ricardobocchi.blogspot.com.br/2013/04/veloster-benchmark.html
Até!