Cita: Originalmente Escrito por
manolazo
He mirado el codigo parece bastante enrevesado al menos para mi nivel , realmente no veo la sencillez del modelo
El modelo no tiene por qué ser sencillo ni complejo, sino fácilmente desgranable en partes más pequeñas que permitan tratarlas de forma independiente. Esto no es propio de Android, sino buena práctica del desarrollo en general.
También es cierto que utilizar este tipo de arquitecturas no es lo recomendable cuando simplemente estás aprendiendo, ya que la arquitectura termina siendo una forma de organizar tu código una vez has superado la barrera de entrada inicial (saber cómo obtener los resultados que deseas). Al final al usuario le da igual si lo tienes todo en una activity de 10000 líneas o si lo has separado utilizando una arquitectura hexagonal, el solo quiere que al darle al botón se vea lo que se tenga que ver.
Cita: Originalmente Escrito por
manolazo
anotaciones @NONNull pasandolas por parametro en las funciones
No es que esté pasando la anotación por parámetro, sino que la anotación está asociada al parámetro.
Esa anotación puede estar asociada a métodos que nunca pueden devolver null, o a parámetros que nunca pueden ser null.
Cita: Originalmente Escrito por
manolazo
uso de librerias retrofit2
El uso de esta librería es bastante común cuando se habla de hacer peticiones sobre HTTP, y además es bastante cómoda de utilizar. Es de las más utilizadas en la comunidad Android, te recomiendo que si algún día necesitas hacer peticiones de red le eches un ojo
Cita: Originalmente Escrito por
manolazo
Hasta que punto es mejor usar este modelo al modelo tradicional para este tipo de apps?
Como he puesto arriba,
Cita:
También es cierto que utilizar este tipo de arquitecturas no es lo recomendable cuando simplemente estás aprendiendo, ya que la arquitectura termina siendo una forma de organizar tu código una vez has superado la barrera de entrada inicial
Además, no es algo que se entienda en una leída de código, hay que pegarse con el hasta que tienes un poco el "momento ajá!" y entiendes por qué se hace cada cosa.
Ten en cuenta también que una arquitectura no es un estándar, cada uno puede adaptarla a sus necesidades.
---
Dicho esto, paso a hacer un par de comentarios sobre el código... Como siempre, la programación es el mundo del cuñadismo por excelencia (aka: "Pues yo esto lo haría de otro modo...")
1. Clase Network. Cada vez recreas un RetrofitService, cosa que es bastante costosa (ya que se hace por reflection). Te recomiendo que lo cachees y lo reutilices (ej: singleton, por ejemplo).
La aproximación que suelo utilizar en esos casos es utilizar Dagger2 e inyectarlo donde se necesite (lo mismo con el OkHttpInterceptor)
2. Retrofit. Generas la URL directamente desde código. Te recomiendo que le eches un ojo a las anotaciones de Retrofit, ya que puedes pasarle directamente los parámetros y el automáticamente te hace las concatenaciones:
http://square.github.io/retrofit (apartado URL Manipulation).
3. getContext en las vistas. En tu caso estás utilizando la propia vista como contexto. Ten cuidado, ya que eso puede llevar a que tengas memory leaks. Siempre que necesites un Context, deberías intentar llamar a .getApplicationContext, ya que ese contexto siempre está disponible mientras viva la aplicación y no está ligado a ninguna activity en concreto. Ya lo que sería genial sería que fuera parte del grafo de dependencias, y así podrías dejar la interfaz de la vista totalmente libre de Android, cosa que si planeas hacer tests para el presenter será de gran ayuda, ya que podrás ejecutarlos directamente desde JUnit.
Esas son las primeras opiniones después de echarle un ojo rápido al código. Espero que no te molesten!