Android: modello per il controllo dei requisiti all'avvio?

Non sono sicuro che questa sia la soluzione migliore, ma questo è ciò che ho finito per fare:

Ho inserito tutti i miei controlli dei requisiti nella onResume() di un frammento senza testa e l'ho aggiunto alla mia attività in onCreate(...) . Se uno qualsiasi dei requisiti non viene soddisfatto, il frammento senza testa mostra frammenti di dialogo che spiegano cosa deve fare l'utente prima di portarlo alle impostazioni di sistema. Quando tutti i requisiti sono soddisfatti, chiama un metodo sull'attività. (Potrei cambiarlo per trasmettere un evento per separare completamente il frammento dall'attività.)

Questo non rende la logica della sequenza di controlli meno disordinata, ma almeno sposta tutto il codice fuori dall'attività, rendendo entrambe le parti più facili da navigare e capire.

Modifica: sei mesi dopo, ho rifattorizzato la soluzione di cui sopra in qualcosa di molto più OO.

public interface Requirement {
    /**
     * Checks a system requirement and calls {@link
     * StartActivity#nextRequirement()} when it's satisfied.
     *
     * @param activity the current activity
     */
    void check(final StartActivity activity);
}

A List<Requirement> viene iniettato nell'attività utilizzando Dagger2. Posso facilmente aggiungere altri requisiti e il loro ordine è facile da vedere e modificare nel modulo di Dagger.

@Inject List<Requirement> mRequirements;
private Iterator<Requirement> mRequirementsIterator;

void checkRequirements() {
    mRequirementsIterator = mRequirements.iterator();
    nextRequirement();
}

void nextRequirement() {
    if(mRequirementsIterator.hasNext()) {
        mRequirementsIterator.next().check(this);
    }
    else {
        onRequirementsSatisfied();
    }
}

chiamo checkRequirements() da onResume() . Qualsiasi frammento di finestra di dialogo visualizzato da Requirement si disattiva nel proprio onPause() , poiché verranno visualizzati di nuovo se il requisito non è ancora soddisfatto al successivo riavvio dell'attività.

Abbiamo usato un unico metodo che non ha fatto altro che determinare quali cose dovevano essere impostate e restituire un valore che è stato passato in un secondo metodo che era in realtà solo una gigantesca affermazione dell'interruttore. Ogni elemento (come isGpsAvailable) ha il proprio metodo che è stato inserito nel caso appropriato a seconda dell'ambiente.