2015-01-15 13 views
8

Il programma in questione, quando viene eseguito su Android, controlla i dispositivi Bluetooth (slave) slave. Ha pochi pulsanti che abilitano diverse funzioni dei dispositivi peer.Controllo del flusso del programma Android in presenza di startActivityForResult call

Bluetooth non è abilitato per impostazione predefinita sul dispositivo Android e la connessione viene stabilita per brevi periodi dopo il clic del pulsante (i).

Così, il flusso dopo ogni scatto del tasto è:

  1. Assicuriamo BT abilitato (startActivityForResult() con BT consentire intento se non)
  2. connettersi al dispositivo remoto
  3. abilitare alcune funzioni del dispositivo remoto
  4. disconnessione dal dispositivo

il mio problema è che se BT non è abilitato, quindi un ca ll a startActivityForResult() in # 1 "interrompe" il flusso del programma. Successivamente, quando viene chiamato il numero onActivityResult(), voglio riprendere il flusso dal punto in cui è stato "interrotto".

A tal fine ho definito campo di membro aggiuntivo e poche costanti e li usavano in onActivityResult():

private int mRerunMethodIndex = 0; 
private static final int RERUN_METHOD1 = 1; 
private static final inr RERUN_METHOD2 = 2; 
... 
public void onActivityResult(int requestCode, int resultCode, Intent data) { 
    switch (requestCode) { 
     case REQUEST_ENABLE_BT: 
      if (resultCode == Activity.RESULT_OK) { 
       int rerunMethodIndex = mRerunMethodIndex; 
       mRerunMethodIndex = 0; 
       switch (rerunMethodIndex) { 
        case (RERUN_METHOD1): 
         method1(); 
         break; 
        case (RERUN_METHOD2): 
         method2(); 
         break; 
        // ... the same for other cases 
       } 
      } 
      break;  
     default: 
      break; 
    } 
} 

Ora, un'altra complicazione: onActivityResult() sarà chiamato prima dell'attività di onResume(). Ciò cambierà se uno qualsiasi degli deve modificare la gerarchia delle viste. Nel mio caso questi metodi sostituiscono alcuni frammenti e se questa operazione viene eseguita da onActivityResult() viene lanciata un'eccezione.

Per risolvere questo problema aggiuntivo, il brutto switch da onActivityResult() migra a onPostResume().

L'approccio descritto sopra funziona, ma è uno dei più brutti pezzi di codice che io abbia mai scritto: methodX() "registri" se stesso per "replica" assegnando RERUN_METHOD_X costante a mRerunMethodIndex, onActivityResults() set di qualche "bandiera replica" dopo BT è abilitato, onPostResume() controlla il flag, cancella questo flag, cancella mRerunMethodIndex e ripete l'appropriato methodX().

Esiste un approccio più elegante (preferibilmente limitato a 1 o 2 metodi)?

risposta

3

È possibile utilizzare runnable per organizzare il flusso di lavoro senza utilizzare le costanti del passo. Ad esempio:

public void Runnable mMethod1 = new Runnable() { 
    public void run() { 
     // your code for method 1 
    } 
} 

public void Runnable mMethod2 = new Runnable() { 
    public void run() { 
     // your code for method 2 
    } 
} 

public void Runnable mMethod3 = new Runnable() { 
    public void run() { 
     // your code for method 3 
    } 
} 

private void startMethod(Runnable method) { 
    mCurrentMethod = method; 
    method.run(); 
} 

... 

public vond onPostResume() { 
    if (mCurrentMethod != null) { 
     mCurrentMethod.run(); 
     mCurrentMethod = null; 
    } 
} 
+0

Sembra una variazione del modello di progettazione Command. Non sono del tutto sicuro che questo approccio semplificherà il codice, ma è davvero interessante. Proverò a vedere come funziona la prossima volta che mi trovo in questa situazione. – Vasiliy