Aggiungere più responsabilità alle attività in modo flessibile

Question

Sto considerando come posso aggiungere attività alle attività Android in modo flessibile. Posso solo usare l'eredità dell'implementazione solo per una cosa in Java e vorrei usarlo, se lo uso, per qualcos'altro.

Penso di dover disegnare il dominio Prima un po ':

Attività Le finestre dell'interfaccia utente sono fondamentalmente, con responsabilità del ciclo di vita intrinseche applicate dall'API. Il compiti Parlo sono popover Ui-visibili che fanno alcune cose offline e poi scompaiono. Derivano da asinctask. Il codice di tutto ciò non è un problema, ho già questo, anche piuttosto generalizzato con le interfacce. Sto cercando ulteriori miglioramenti del design che posso apportare.

Esistono molti tipi di attività e potrebbero lavorare con alcuni tipi di compiti. Per esempio Una finestra di ricerca avrebbe un'attività che aggiunge uno dei risultati di ricerca, diciamo che è un libro, alla raccolta di libri nell'applicazione principale. Ti consente di aggiungere più, quindi 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 navigare attraverso la tua collezione, ma deve mostrare una barra di avanzamento in quanto potrebbe richiedere un po 'di tempo per esportare.

Un'attività specifica esiste come classe nidificata in un'attività specifica. Deve essere salvato e restaurato 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 compiti attivi (o solo un membro per un'attività). Alcuni eventi dell'interfaccia utente creerà un nuovo compito e lo aggiungerà all'elenco, a la onClick(): ATask task = new ATask(); task.execute(something);.

Ecco cosa ho considerato finora:

• Ereditarietà dell'implementazione

  Basta spostare questa attività di attività in una super classe astratta di tutte le attività specifiche.

• Modello decoratore

  Crea un decoratore TaskActivity che aggiungerà questa responsabilità a qualsiasi attività. Il decoratore dovrebbe imitare l'intera interfaccia di attività fornita dall'API, per lo più passthrough. Quindi questo potrebbe essere già un po 'troppo pesante. Dovrebbe anche aggiungere gli eventi/pulsanti dell'interfaccia utente che avviano l'attività, il che potrebbe non essere sempre possibile se l'azione è più consequenziale.

  Ma il problema più grande che potrei trovare qui è che Android usa un manifesto per abbinare vagamente tutte le attività insieme. Qui devi dichiarare ogni attività specifica o non può essere utilizzato. Questo è un problema perché il decoratore funzionerebbe in fase di esecuzione, con composizione. Non posso dichiarare il decoratore e aggiungere le informazioni di cui ha bisogno per avvolgere un'attività specifica.

  Insieme a Android Mi sembra di finire con l'eredità dell'implementazione molto più di quanto mi piacerebbe. Quindi ho troppo accoppiamento o duplicazione del codice. Le attività crescono sempre facilmente a grandi classi grassi. Ho ragione a dire che ciò è in parte dovuto alle scelte di progettazione esistenti nel framework Android, come il manifesto che toglie le soluzioni di composizione o l'oggetto di contesto? Ho ragione a dire che fin dall'inizio taglia una quantità significativa di modelli di progettazione stabiliti nelle aree chiave, incluso il modello MVC.

• Decoratore con involucri:

  Che non riesco a specificare il decoratore e l'attività specifica a cui si applica insieme nel manifest, non significa che non posso creare classi che rappresentano e organizzano questa composizione. Ovviamente potrei creare molte classi di decorazione specifica, che implementano anche l'interfaccia di attività e agire come il decoratore, e quindi avvolgere nell'attività specifica reale. Non sono sicuro che però risolva il mio problema. Sembra un sacco di lavoro, molte lezioni di spazzatura e mi porta lontano dal mio obiettivo originale.

• Modello di strategia:

  Se non riesco a scuoiare l'attività, è meglio esternalizzare parte del suo coraggio. Questo mi darà ancora più connessioni, anche se le attività dovranno sapere sulla strategia. La strategia stessa tuttavia sarà più leggera come decoratore. Eppure non sembra tanto una strategia in cui esiste una scelta di quale, ma piuttosto solo spostarsi della classe in un'altra classe. Lo chiamerei TaskManager. E avrei comunque tirato su le strategie la conoscenza in un'attività super classe?

• Qualche altro modello?:

Quale schema è la scelta migliore? Non evitare la tua opinione sul caso Android specifico. Non c'è bisogno di parlare in particolare di compiti.