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.
- OnConfigurationChanged () no se dispara para keyboardHidden
- ¿Cuál es el uso de return statement en una función void
- Uso del protocolo SMB en la URL mientras se utiliza la biblioteca JCIFS en Android
- ¿Qué significa el "m" para el código java
- Cómo obtener el evento de finalización de llamada en la aplicación para Android
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?
- ¿Puedo acceder a los datos almacenados en AsyncStorage de React Native desde la capa java?
- Reutilización de vistas en Android Listview con 2 diseños diferentes
- Cómo crear dibujos vectoriales para Android?
- Establezca todos los valores de ArrayList <Boolean> a false en instatiation
- Cómo establecer una altura máxima con contenido de recapitulación en android?
- No se puede emitir desde el tipo de origen al tipo de destino (JNIEnv.GetArray <Java.Lang.Object> (pudis.Handle);)
- ¿Cuál es el equivalente androide de java.awt.geom.Area?
- ¿Cómo forzar la clase derivada a llamar al método super? (Al igual que Android)
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.
- El clic largo no funciona con ListView
- Cómo evitar que una preferencia compartida sea clara al establecer