Android – Cómo evitar el código duplicado entre actividades

Esto es un poco de una cuestión general, pero voy a dar un ejemplo específico para usted.

Tengo un montón de actividades en una aplicación. En todas las actividades, hay un botón de Facebook. Cuando haces clic en el botón, te lleva a una página específica de Facebook. Deseo que el botón se comporte exactamente de la misma manera en cada página.

Ahora, en cada actividad, creo un onClickListener() para el botón de Facebook y hacer la intención y comenzar la actividad. Es el mismo código en cada actividad.

¿Cuál es la mejor manera de escribir este código una vez e incluirlo en múltiples actividades? ¿Hay de todos modos incluir otros archivos .java?

Una solución que sé que funcionaría, es hacer una clase base de CustomActivity que extiende la Activity y luego tener todas las actividades de extender CustomActivity . Luego coloco mi código onClickListener() en CustomActivity . Soy nuevo en Java sin embargo y no estaba seguro de si ese era el mejor enfoque o no. Algunas de mis actividades ya ampliar otras clases de actividades personalizadas como es, por lo que ampliar las cosas que se extienden más cosas puede ser un poco desordenado, no sé.

ACTUALIZAR

Jugando el defensor del diablo aquí: Digamos que fui con la ruta de la herencia y creo algo de CustomActivity que quiero que mis actividades se extiendan. CustomActivity contendría un montón de código general que necesito usar para todas las actividades, incluyendo pero no limitado a la funcionalidad del botón de Facebook. ¿Qué sucede cuando hay una actividad que necesito para usar código genérico de CustomActivity pero no hay ningún botón de Facebook en esa actividad específica?

Una clase base común es tal vez el mejor enfoque. (No funciona muy bien si algunas de sus actividades se extienden Actividad y algunas subclases de actividad de extensión (como ListActivity).

Un acercamiento alternativo es crear una clase separada que implemente la lógica de su oyente del tecleo. Esto no elimina todo el código duplicado – cada actividad todavía necesita instanciar y registrar un oyente – pero la lógica para qué hacer sólo tendrá que ser escrita una vez en la clase de escucha.

En cualquier alternativa, puede considerar asignar el atributo android:onClick al botón. De esta manera, no es necesario registrar un oyente de clics; sólo tiene que implementar el método de destino en cada actividad. Esto es particularmente útil con el enfoque de clase base.

ACTUALIZAR

Supongamos que usted va a la ruta de la herencia y desea una actividad sin botón de Facebook. Si está utilizando la técnica de android:onClick , entonces no tiene que hacer nada diferente en su código – ya que ningún botón invocará su método onClick, el método se quedará sentado sin hacer nada. Si está instalando OnClickListener en código, entonces sólo necesita probar que el botón existe (es decir, que findViewById() no devolvió null ) antes de registrar el oyente.

Generalmente, una clase base común NO es el mejor enfoque (aunque ciertamente es válido).

Esto me llevó (y cada programador de OO que "obtiene" OO que sé) un tiempo para realmente grok, pero debe utilizar la herencia tan escasamente como sea posible. Cada vez que lo haga usted debe preguntarse si realmente no hay otra manera de hacer esto.

Una forma de averiguar es ser muy estricto con la prueba "es-a" – si llama a su actividad base una "Actividad de Facebook", ¿podría realmente decir que cada niño "es" una actividad de Facebook? Probablemente no. También si decidiste añadir en Twitter a algunas de las páginas (pero no a otras), ¿cómo haces esto?

No es que la herencia está completamente fuera! Una gran solución podría ser extender un control para lanzar su actividad de Facebook y llamarla un botón de facebook – que tenga encapsulado todas las cosas que necesita hacer para conectarse a Facebook. Ahora puede agregar esto a cualquier página que desee simplemente arrastrándola (estoy bastante seguro de las herramientas de Android le permiten agregar nuevos componentes a la paleta). No es "Libre" como ampliar su clase de actividad, pero a largo plazo le costará mucho menos estrés.

Usted probablemente no me creerá ahora, todos tenemos que aprender de nuestra propia experiencia, sólo tiene esto en mente y utilizarlo para evaluar su código a medida que evoluciona con el tiempo.

–edit, comentario respuesta–

Puedes encapsular cualquier actividad de Facebook que creas que vas a utilizar mucho en su propia clase – conseguir que a un mínimo necesario para que pueda agregar a cualquier clase en un solo forro.

En algún momento, sin embargo, usted puede decidir que es TODAVÍA demasiado boilerplate, entiendo totalmente. En ese momento usted podría utilizar una actividad de base abstracta como usted sugiere, pero yo no código duro para manejar facebook explícitamente, en su lugar tendría que soportar comportamientos como facebook (y tal vez otros), y activar estos comportamientos como se desee. A continuación, podría decirle que no para agregar el comportamiento de Facebook a una pantalla determinada si lo desea, o agregar en Twitter a algunos de ellos.

Usted puede hacer este mínimo estándar, por ejemplo, si desea funcionalidad "Estándar", no debería tener que hacer nada especial, si desea desactivar facebook que podría iniciar su constructor con:

 super(DISABLE_FACEBOOK_BEHAVIOR); 

y si quieres uno que también permite Twitter se puede utilizar:

 super(DISABLE_FACEBOOK_BEHAVIOR, ENABLE_TWITTER_BEHAVIOR); 

con un constructor como AbstractAction (BehaviorEnum … comportamientos).

Esto es más flexible y en realidad se puede decir que cada uno si sus actividades IS-A "actividad de apoyo al comportamiento" con una conciencia limpia.

Es, por supuesto, un enfoque perfectamente bueno para ser menos flexible al principio y refactorizar en un patrón como este más tarde cuando sea necesario, sólo estar en el look-out de su modelo de herencia causando problemas para que no deje que el lío usted por mucho tiempo antes de arreglarlo.

Bueno, extender las cosas es el principio de OOP, así que no creo que sea un problema tener más de un nivel de subclases. La solución que usted pensó es en mi opinión la mejor.

Absolutamente. Utilice la herencia para obtener algo de reutilización como debería con OOP. Encontrarás, a medida que avances, que habrá más y más cosas que te gustaría reutilizar en tus actividades – cosas más complejas que un onClickListener para un botón FB – por lo que es una gran idea empezar a construir un agradable, reutilizable "super" actividad de la que se puede heredar.

  • ¿Podemos usar Optionals en la programación de Android?
  • La fusión manifiesta falló: uses-sdk: minSdkVersion 8 no puede ser menor
  • Editar encabezados de MultiPartEntity
  • Cuenta de método jar / dex Android en ventanas
  • Dar permiso de actividad en AndroidManifest
  • ¿Cómo puedo enviar desde el lado del servidor (Google App Engine, Cloud Endpoints) la información a mi cliente?
  • N-Puzzle pseudo-aleatorio barajar?
  • ¿Cuál es la diferencia entre Factory y Factory2 de LayoutInflater?
  • ¿Cómo utilizar el paquete java.nio.file en android?
  • Establecer el agente de usuario en httpclient de Java y permitir redireccionamientos a true
  • ¿Cómo se inyecta impl de alguna interfaz en una actividad de Android utilizando Guice
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.