Sto considerando come posso aggiungere attività alle attività Android in modo flessibile. Posso usare l'ereditarietà dell'implementazione solo per una cosa in Java e mi piacerebbe usarlo, se lo uso, per qualcos'altro.
Penso di aver bisogno di disegnare il dominio prima un po ':
Le attività sono fondamentalmente finestre dell'interfaccia utente, con le responsabilità intrinseche del ciclo di vita imposte dall'API. I compiti di cui parlo sono popover visibili all'interfaccia utente che eseguono alcune cose offline e quindi scompaiono. Derivano da AsyncTasks. Il codice di tutto questo non è un problema, ho già questo, anche piuttosto generalizzato con le interfacce. Sto esaminando ulteriori miglioramenti del design che posso apportare.
Esistono molti tipi di attività e tutti possono lavorare con alcuni tipi di attività. Ad esempio una finestra di ricerca avrebbe un'attività che aggiunge uno dei risultati della ricerca, diciamo che è un libro, alla raccolta di libri nell'applicazione principale. Ti permette di aggiungere più, da qui il popover. Una finestra che visualizza la raccolta ha un'attività che consente di esportare un libro in un formato di file esterno. Non ti impedirà di sfogliare la tua raccolta, ma ha bisogno di visualizzare una barra di avanzamento in quanto potrebbe richiedere un po 'di tempo per l'esportazione.
Una specifica attività esiste come classe nidificata in un'attività specifica. Deve essere salvato e ripristinato insieme agli eventi del ciclo di vita: c'è un onSaveInstanceState(Bundle) e onRestoreInstanceState(Bundle) per questo, tra gli altri. L'attività ha un elenco di attività attive (o solo un membro per un'attività). Un evento UI creerà una nuova attività e la aggiungerà all'elenco, a la onClick(): ATask task = new ATask(); task.execute(something); .
Ecco cosa ho considerato finora:
-
Ereditarietà dell'implementazione
Sposta questa attività commerciale a una super classe astratta di tutte le attività specifiche.
-
Modello decoratore
Crea un TaskedActivityDecorator che aggiunga questa responsabilità a qualsiasi attività. Il decoratore dovrebbe imitare l'intera interfaccia di attività come fornita dall'API, principalmente i passthrough. Quindi questo potrebbe essere già un po 'troppo pesante. Dovrebbe anche aggiungere gli eventi / pulsanti dell'interfaccia utente che lanciano l'attività, il che potrebbe non essere sempre possibile se l'azione è più consequenziale.
Ma il problema più grande che ho potuto fare qui è che Android utilizza un manifest per unire liberamente tutte le attività insieme. In questo caso è necessario dichiarare ogni attività specifica o non può essere utilizzata. Questo è un problema perché il decoratore avrebbe funzionato in fase di runtime, con composizione. Non posso dichiarare il decoratore e aggiungere le informazioni di cui ha bisogno per avvolgere un'attività specifica.
Con Android mi sembra di finire con l'ereditarietà dell'implementazione molto più di quanto mi piacerebbe. Quindi ho troppo accoppiamento o duplicazione del codice. Le attività crescono sempre facilmente a classi di grandi grassi. Ho ragione nel dire che ciò è in parte dovuto alle scelte progettuali esistenti nel framework Android, come il manifest che rimuove le soluzioni di composizione o l'oggetto Context? Ho ragione nel dire che fin dall'inizio cancella una quantità significativa di modelli di progettazione stabiliti in aree chiave, incluso il pattern MVC.
-
Decoratore con wrapper :
Che non posso specificare il decoratore e l'attività specifica a cui si applica insieme nel manifest, non significa che non sia possibile creare classi che rappresentano e organizzano questa composizione. Naturalmente potrei creare molte classi SpecificDecoratorActivity, che implementano anche l'interfaccia Activity e si comportano come il decoratore, e quindi avvolgono l'attività specifica reale. Non sono sicuro che risolva il mio problema. Sembra un sacco di lavoro, un sacco di lezioni di spazzatura e mi allontana dal mio obiettivo originale.
-
Modello di strategia :
Se non riesco a scuoiare l'attività, allora farei meglio a esternalizzare parte del suo coraggio. Questo mi darà ancora più connessioni, anche se le attività dovranno conoscere la Strategia. La stessa strategia tuttavia sarà più leggera come decoratore. Eppure non sembra molto simile a Strategia dove c'è una scelta di quale, ma piuttosto semplicemente spostando parte della classe in un'altra classe. Lo chiamerei TaskManager. E continuerei a portare le conoscenze sulle strategie in una super classe di attività?
-
Qualsiasi altro pattern? :
Quale modello è la scelta migliore? Non evitate la vostra opinione sullo specifico caso Android. Non è necessario parlare in modo specifico delle attività.