Sim, - vou dizer isso pela 3ª vez só hoje neste fórum - não reinvente a roda. rs
-- Márcio, se esse projeto for pequeno e vc tiver um deadline curto, o melhor a fazer seria usar muita herança, encapsulamento e wtf... Padrão Command, Façade e alguns factories poderiam ajudar.
Mas se realmente quer um conselho: NÃO FAÇA ISSO!
O Android-Way de se fazer as coisas é um pouco mais estruturado. Por exemplo:
- Vc pode usar um ContentProvider para acessar o banco de dados, ao invés de fazer tudo manualmente. Com ele vc pode inclusive isolar consultas e insert com as classe ContentResolverOperation. Há um tempo descobri um jeito muito bacana e prático, que reduz enormemente a tonelada de código do ContentProvider. Este projeto é um excelente exemplo de como fazê-lo.
- Se combinar o content provider com um ORM como o OrmLite (se quiser integrar com o Android Annotations vc economiza não só na criação dos Dao's, mas em diversas outras coisas praticamente sem impacto no desempenho do app), vc ganha na hora de fazer inserções/atualizações. Existe o método no Dao.createOrUpdate(<Objeto>) que faz a mágica toda.
- Para o caso da atualização/sincronização, use o SyncAdapter. É chatinho de implementar, mas o resultado é excelente e gerencia diversos aspectos sobre a sincronização. Coisas como verificar conexão, consumo de bateria, agendamento de atualização, forçar atualização manual, etc., já estão inclusos.
- SyncAdapter.onPerformSync() é onde tudo acontece, mas não existem muitos "tutoriais fáceis" ou meios recomendados de se fazer. Digo por experiência própria. Tudo o que há são meia dúzia de exemplos com poucos dados. Quando a coisa aperta o que vale é a criatividade e boas práticas...
Resumindo, coisas que costumo fazer:
- Usar a integração ContentProvider/ORM;
- Criar uma classe Contrato, que contém todos os nomes de campos e Uris de todos os modelos/tabelas;
- Usar uma classe "Discover", onde os modelos são registrados para criação das tabelas;
- Modelo base para todos os modelos com atributos/métodos comuns (Vc pode inclusive evoluir isso para um ActiveRecord da vida...);
- RoboSpice, Volley ou algo semelhante para abstrair a parte de networking, e Retrofit ou SpringRestTemplate se usar alguma API no servidor;
- Um algoritmo genérico (possivelmente baseado no modelo base) para "fazer o trabalho pesado";
- Algum tipo de conjunto de classes plugáveis/extensíveis para registrar de onde/para onde as informações de cada modelo/tabela devem ir;
Estou planejando uma série de artigos para registrar alguns patterns/boas práticas que fui encontrando ao longo do tempo em desenvolvimento Android. São temas bem comuns na verdade. Fique de olho.
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
0 comentários:
Postar um comentário