¿Cuál es el criterio para el código limpio en el desarrollo de Android?

Esta pregunta no tiene una respuesta correcta. Depende de las características para las que esté optimizando.

Por ejemplo, trato de mantener mis componentes de Android lo más independientes posible. Esto significa:

  • Cree bibliotecas genéricas de Java (no bibliotecas de Android) siempre que sea posible. Por ejemplo, las clases modelo no deberían tener dependencias de Android.
  • No cree nada dentro de las clases Actividad o Fragmento, excepto enviar eventos a una biblioteca de pubsub. Esto significa que es libre de modularizar sus componentes y hacerlos independientes y verificables de forma aislada porque los mensajes que provienen de la biblioteca pubsub pueden provenir del código de prueba en lugar de solo una Actividad.
  • Use una biblioteca para guardar y restaurar automáticamente el estado de la interfaz de usuario y poner todo en la clase de estado. Del mismo modo, use una biblioteca para enviar y devolver parámetros de fragmentos y actividades para evitar el trabajo tedioso y propenso a errores que empuja parámetros individuales en un intento y los recupera.
  • Convierta la actividad principal de la aplicación en un shell que inicie la Actividad que tiene la actividad personalizada principal. Esto le permite crear fácilmente diferentes versiones de la aplicación que le permite probar varias versiones de la aplicación simultáneamente en el mismo teléfono.

Si va a comenzar desde cero, estas notas describen algunos de los principios mínimos (en mi opinión) de diseño de software específicamente para aplicaciones de Android que serían necesarios para el código “limpio”.

No conozco ninguna base de código que los haga todos.

Puede dejar que Android Studio lo guíe para escribir un código limpio.

También verifique los resultados de Lint de Android Studio.

Por último, someta el proyecto a Codacity y vea lo que sugiere.

PD. Supongo que revisaste muchas guías de estilo de Android antes de hacer esta pregunta. Si no, hazlo en primer lugar.

Generalmente hay dos criterios si el código limpio:

  1. Facilidad de soporte
  2. Facilidad de prueba

Otro es solo un toque de moda. El principio principal es organizar el proyecto de tal manera que un extraño pueda comenzar a ofrecer nuevas funciones rápidamente.