Ho un compito comune che faccio con alcune attività: scaricare i dati e visualizzarli. Ho scaricato la parte download pat; è, ovviamente, un po 'complicato a causa della possibilità che l'utente cambi l'orientamento o annulli l'attività prima che il download sia completato, ma il codice è lì. C'è abbastanza codice per gestire questi casi in modo tale che non voglio doverlo copiare/incollare su ogni attività che ho, quindi ho pensato di creare una sottoclasse di attività astratta in modo tale che gestisca un singolo download in background che poi avvia un metodo che riempie la pagina di dati.Esiste un modello di progettazione per ridurre la duplicazione del codice durante la sottoclasse di attività in Android?
Tutto questo funziona. Il problema è che, a causa dell'ereditarietà singola, sono costretto a ricreare esattamente la stessa classe per qualsiasi altro tipo di attività: ad esempio, utilizzo Activity, ListActivity e MapActivity. Utilizzare la stessa tecnica per tutti e tre richiede tre classi duplicate, tranne che ciascuna estende un'attività diversa.
Esiste un modello di progettazione che può ridurre la duplicazione del codice? Così com'è, ho già salvato molte duplicazioni, ma mi fa male vedere lo stesso codice in tre classi solo in modo che ciascuna sottoclasse un diverso tipo di attività.
Edit: Poiché sembra che ho bisogno di essere un po 'più specifico ...
Supponiamo che sto cercando di risolvere il problema di un AsyncTask background Scaricate durante i cambi di orientamento. La soluzione che ho adesso è usare i callback; c'è il download manager che ho che avvia questi download, e poi ho l'attività allegare un callback ad esso. Quando l'orientamento cambia, l'attività viene distrutta e quindi ricreata; durante questo processo, scollego il callback della vecchia attività, quindi allego un nuovo callback dalla nuova attività in seguito.
Le modifiche di orientamento sono un problema comune e in più attività avvio l'attività con una vista di avanzamento durante il caricamento dei dati. Quello che sto cercando di risolvere non è il dover reimplementare questa logica di gestione dell'orientamento dieci volte; la mia soluzione iniziale era di sottoclasse Attività, ma poi ho avuto il problema sopra.
Capisco perfettamente questo concetto, ma fare la composizione in questo caso significherebbe solo la duplicazione del codice tanto quanto semplicemente implementandola in ogni classe. Ogni classe dovrebbe implementare onCreate(), onRetainNonConfigurationInstance(), onResume(), onPause(), onDestroy() e chiamare il delegato. Preferirei non dover pensare a questo aspetto dell'implementazione per ogni attività che scrivo. Potrei essere convinto del contrario, ma in questo caso la composizione produce altrettante duplicazioni, a meno che non manchi qualcosa. –
Ick. Ciò suggerisce che le attività di Android sono troppo grandi e probabilmente non ne hai il controllo. Suppongo che potresti scrivere un DelegatingActivity con quelle funzioni (e assignDelegate() o somesuch) già scritte e ereditate da questo. Come l'hai descritto finora, questo non ha molto vantaggio su una semplice interclasse di attività, ma potrebbe ripagare la strada. –
Il modo in cui le attività funzionano è che hanno metodi diversi chiamati in stati diversi (ad esempio "onCreate()" e "onDestroy()"). Quando implementi la tua attività, sottolisti e estendi questi metodi per definire il comportamento. Il tuo post mi ha dato un'idea, che è quella di creare ancora più sottoclassi di varie attività, ma di avere ogni implementare un delegato all'interno di esso; in questo modo non sto implementando lo stesso codice ogni volta. Tuttavia, speravo in una soluzione leggermente meno caotica. –