Come gestire una connessione Bluetooth su Android attraverso le modifiche alla configurazione?

Question

Domanda:
Come posso gestire (collegare, leggere, scrivere, disconnettere) una connessione Bluetooth che permane attraverso le modifiche di configurazione?

Preferisco soluzioni che siano compatibili con la versione dispositivo 2.2 "Froyo" utilizzando ActionBarSherlock.

problemi ...

• Né BluetoothDevice né BluetoothSocket possono essere conservati in onSaveState.

• Per il keep my app responsive, il blocco di 12 secondi BluetoothSocket.connect() deve essere eseguito su una filettatura separata. L'avvio di un Runnable è il metodo consigliato per eseguire il thread di attività lunghe, ma è un incubo che tenta di ripristinare una modifica di configurazione. I documenti ufficiali indicano tre diverse soluzioni.

  • Utilizzare getLastNonConfigurationInstance(), che è deprecato (sul serio ?!).

  • Impostare android:configChanges="keyboardHidden|orientation" come BluetoothChat Sample. Tuttavia, questo non tiene conto di tutti i tipi di modifiche alla configurazione.

  • Annulla & attività di riavvio come Shelves Example. In questo caso, questo potrebbe potenzialmente sprecare altri 12 secondi.

Aggiornamento 1

• ulteriori ricerche mi hanno portato a asyncTaskLoader, ma sembra che questo può solo aggiornare l'interfaccia utente al termine, e non può fornire gli aggiornamenti.

• campione Il BluetoothHDP utilizza un servizio. I servizi sembrano incentrati sulla comunicazione tra processi e sulla necessità di andare oltre il ciclo di vita dell'attività. Non ho bisogno di nessuna di queste funzionalità.

Aggiornamento 2

As pointed out by Reuben, Fragment.setRetainInstance(bool) ha sostituito il deprecato getLastNonConfigurationInstance(). A questo punto, sembra che l'opzione migliore sia quella di creare un frammento persistente non-UI usando setRetainInstance(true).

Answer 1

C'è un sacco di soluzioni a questo. Se non stai usando Fragments, l'opzione più semplice è sovrascrivere onRetainNonConfigurationInstance(). Non importa che l'API sia deprecata, è solo perché vogliono che tu usi Fragments (dove, per essere onesti, Fragment.setRetainInstance() rende questo intero problema il gioco da ragazzi che dovrebbe sempre essere stato). Questa API non andrà da nessuna parte per molto tempo.

Quello che mi piacerebbe fare è ignorare onRetainNonConfiguration() per restituire 'questo', cioè un riferimento all'istanza di attività morti, e poi copiare gli arbitri devi da onCreate(), vale a dire:

Object obj = getLastNonConfigurationInstance(); 
if (obj != null) { 
    MyActivity deadActivity = (MyActivity)obj; 
    this.foo = deadActivity.foo; 
    this.bar = deadActivity.bar; 
    ... 
} 

In alternativa si può utilizzare un servizio, ma personalmente non mi piace. Utile per fare roba cross-process, senza dubbio, ma per il resto sono una soluzione alla ricerca di un problema.

Infine, come punto generale dell'ordine è possibile inserire dati "globali" nel contesto dell'applicazione. Per fare ciò, sottoclassi android.app.Application e usa l'attributo android: name = "MyApp" > di android < nel tuo manifest. È utile anche mantenere un riferimento all'oggetto Application nei dati statici globali qui, in modo che AsyncTasks e altro codice context-less possano sempre accedere al contesto dell'applicazione senza dover passare i parametri di contesto in giro senza motivo.

class MyApp extends Application { 
... 

    public static MyApp context; 
    ... 

    @Override 
    public void onCreate() { 
     super.onCreate(); 

     context = this; 

     ... set up global data here ... 
    } 
... 
} 

Answer 2

vorrei risolvere questo problema utilizzando un Service che avrebbe gestito la connessione Bluetooth, e fare che il Servizio parlare di nuovo al vostro attività, come descritto nella this answer.

Quindi, è possibile utilizzare l'AsyncTask per mostrare semplicemente/nascondere un finestra di dialogo, e annulla/riavvia ASyncTasks sulla rotazione, che è fatto da Shelves Example come hai menzionato.

I servizi non sono poi così orribili e potrebbero essere lo strumento migliore per il tuo problema.

Answer 3

Si può provare con lo singleton pattern che può gestire tutto e chiamare l'attività principale quando è necessario.

Quindi è un metodo statico ottenere un'istanza dell'oggetto MySingleton, la stessa istanza ogni volta che si chiama getInstance. Puoi "memorizzare" tutti gli oggetti bluetooth in esso contenuti, non sarà distrutto e accessibile da ogni attività.

public class MySingleton { 
    private static MySingleton instance; 
    public static MySingleton getInstance() { 
     if (null == instance) { 
      instance = new MySingleton(); 
     } 
    return instance; 
} 

    private MySingleton() { 
    } 
} 

Answer 4

Non posizionare mai App Model (logica o dati) nei componenti Visual/UI. Come vedi, vanno e vengono e cambiano.

Luoghi da tenere roba non legati UI come raccolte di dati, collegamenti in diretta, fili ecc:

• classe Application. Avvolge il ciclo di vita di tutti gli altri componenti. Quasi come un singleton globale. Puoi usarlo per la memorizzazione temporanea.

esempio:

public class App extends Application { 

    private static Beer sBeer; 

    public static void brbHoldMyBeer(Beer b){ 
    sBeer = b; 
    } 

    public static Beer imBackWheresMyBeer(){ 
    return sBeer; 
    } 

} 

Inoltre, avere un servizio di filo Executor statico nella classe Application, contribuirà a mantenere le attività in esecuzione.

• Un servizio in background. A quali attività, frammenti ecc. Possono legare/separare e pubblicare comandi/richieste. Questo è il posto consigliato per i processi e i dati in esecuzione su tutta l'App.

• Un frammento non visivo con setRetainInstance(true). Qui non visivo significa che è un frammento fittizio allegato all'Attività, ma non mostra alcuna vista. È usato solo come porta oggetti conservabile per un'attività. Questo è raccomandato per i processi e i dati a livello di attività.