Sequenza di comando per passare i metodi di attività dell'applicazione?

Question

Dopo aver letto l'articolo Avoiding memory leaks da @RomainGuy ho capito che la mia attuale applicazione Android è afflitta dall'errore di passare l'attività principale dell'applicazione. Quindi ogni volta che posso, posso semplicemente sostituire quel parametro di attività con Activity.getApplicationContext().

Ma ci sono alcune classi nella mia applicazione che hanno ancora bisogno di eseguire metodi che possono essere solo membri dell'attività principale dell'applicazione.

Così stavo pensando di utilizzare eventualmente il Command Pattern per risolvere questo limite.

Il problema è che, se guardiamo l'esempio:

public class SomeCommandExecuableOnlyByActivity implements Command 
{ 
    public void execute(Object data) 
    { 
     doIt(((MyActivity)data).getWindow()); 
    }  
} 

Sono in esecuzione di nuovo nel vicolo cieco di avere bisogno del passaggio intorno all'attività (questa volta travestito da dati Object).

Come uscire da questa situazione "chicken & the egg"?

C'è un modo migliore per affrontare questo problema?

Answer 1

Penso che quello che potrebbe mancare qui è una giusta separazione delle preoccupazioni. Se dici che devi passare la tua attività principale ad altre attività per richiamare alcune funzionalità su di essa, allora mi sembra che l'architettura della tua app abbia alcuni difetti di progettazione fondamentali.

Se non utilizzare lo schema di comando qui non lo so, ma quello che farei in genere è identificare quei metodi che richiedono l'accesso condiviso, spostarli in una classe separata e quindi tenere un'istanza separata di quella classe in tutte le attività che richiedono questa funzionalità o se è necessario condividere lo stato dell'istanza, crearla nel contesto dell'applicazione globale e fornire un percorso di accesso globale (non desiderabile, ma senza un framework DI come RoboGuice è molto difficile implementare DI su Android, poiché i costruttori sono resi nulli.)

A mio parere, in un'applicazione Android ben progettata, un'attività è priva di logica aziendale e fornisce solo operazioni che modificano lo stato dell'interfaccia utente. Il flusso dell'interfaccia utente o di qualsiasi altro calcolo verrebbe lasciato ad altre classi. Lo Model-View-Presenter pattern aiuta enormemente a mantenere il codice strutturato in base alla responsabilità.

Senza darci più informazioni su ciò che stai cercando di ottenere, è difficile dare un consiglio specifico.