Tengo una tarea común que hago con algunas Actividades: descargar datos y luego mostrarlos. Tengo la parte de descarga abajo pat; es, por supuesto, un poco complicado debido a la posibilidad de que el usuario cambie la orientación o cancele la actividad antes de que se complete la descarga, pero el código está allí. Hay suficiente código manejando estos casos como para no tener que copiarlo/pegarlo en cada Actividad que tengo, así que pensé crear una subclase abstracta Actividad en sí misma de manera que maneje una única descarga de fondo que luego lanza un método que llena la página con datos.¿Existe un patrón de diseño para reducir la duplicación de código al crear subclases de Actividades en Android?
Todo esto funciona. El problema es que, debido a la herencia única, me veo obligado a recrear exactamente la misma clase para cualquier otro tipo de actividad; por ejemplo, uso Activity, ListActivity y MapActivity. Para usar la misma técnica para los tres, se requieren tres clases duplicadas, excepto que cada una amplía una Actividad diferente.
¿Hay algún patrón de diseño que pueda reducir la duplicación de código? Tal como está, ya he ahorrado mucha duplicación, pero me duele ver exactamente el mismo código en tres clases solo para que cada subclase tenga un tipo diferente de actividad.
Editar: Puesto que parece que necesito para ser un poco más específico ...
Supongamos que yo estoy tratando de resolver el problema de un fondo AsyncTask descarga durante los cambios de orientación. La solución que tengo ahora es usar devoluciones de llamada; hay un administrador de descargas que tengo que inicia estas descargas, y luego hago que Activity active una devolución de llamada. Cuando la orientación cambia, la actividad se destruye y luego se recrea; durante este proceso, desconecto la devolución de llamada de la actividad anterior y luego adjunto una nueva devolución de llamada de la nueva actividad.
Los cambios de orientación son un problema común, y en Actividades múltiples comienzo la Actividad con una vista de progreso mientras se cargan los datos. Lo que estoy tratando de resolver es no tener que volver a implementar esta lógica de manejo de la orientación diez veces; mi solución inicial fue subclasificar Actividad, pero luego obtuve el problema anterior.
Entiendo este concepto perfectamente, pero hacer composición en este caso significaría casi tanta duplicación de código como simplemente implementarlo en cada clase. Cada clase tendría que implementar onCreate(), onRetainNonConfigurationInstance(), onResume(), onPause(), onDestroy() y llamar al delegado. Preferiría no tener que pensar en este aspecto de implementación para cada actividad que escribo. Podría convencerme de lo contrario, pero en este caso la composición da como resultado tanta duplicación, a menos que me falte algo. –
Ick. Eso sugiere que las Actividades de Android son demasiado grandes, y probablemente no tengas control sobre eso. Supongo que podría escribir una DelegatingActivity con esas funciones (y asignarDelegate() o somesuch) ya escritas, y heredar de eso. Como lo ha descrito hasta ahora, eso no tiene mucha ventaja sobre una simple intercalación de Actividad, pero podría dar sus frutos en el futuro. –
La manera en que funcionan las actividades es que tienen diferentes métodos que se llaman en diferentes estados (por ejemplo, "onCreate()" y "onDestroy()"). Cuando implementa su propia actividad, sublima y extiende estos métodos para definir el comportamiento. Tu publicación me ha dado una idea, que es seguir creando múltiples subclases de diversas actividades, pero para que cada aplicación implemente un delegado dentro de ella; de esa manera no estoy implementando el mismo código cada vez. Aún así, esperaba una solución un poco menos desordenada. –