Autore Topic: Come comportarsi coi thread in caso di destroy()  (Letto 594 volte)

Offline Phate

  • Utente junior
  • **
  • Post: 123
  • Respect: +6
    • Mostra profilo
  • Dispositivo Android:
    Samsung galaxy S
  • Sistema operativo:
    Windows 7
Come comportarsi coi thread in caso di destroy()
« il: 15 Maggio 2012, 01:15:01 CEST »
0
Ciao a tutti, ho un'activity che, nel suo onCreate, instanzia un thread di questo tipo:
Codice: [Seleziona]
public void run(){
 while(active){

   readfromsocket() //bloccante!
   ...loop...
 }

}

public void stop(){
   active = false; //cosi il run esce dal loop e il thread termina in modo safe
}

Ora, il problema è quel maledetto movimento del cell a 90° che causa la distruzione e la conseguente ricreazione dell'activity: ho verificato che così il vecchio thread resta nel sistema, e la ri-creazione crea un secondo thread che immancabilmente interferisce con l'altro!

Una cosa del genere:
Codice: [Seleziona]
public void onDestroy(){
super.onDestroy();
myThread.stop();
}
sembra andare e non andare, nel senso che, stando ai log, il primo thread viene fermato DOPO l'onCreate() e soprattutto dopo aver ricevuto qualcosa dal server remoto a causa della chiamata bloccante...suggerimenti?

Offline zaxxon

  • Nuovo arrivato
  • *
  • Post: 34
  • Respect: +4
    • Mostra profilo
  • Dispositivo Android:
    Archos 101 G9
  • Sistema operativo:
    Ubuntu 10.04
Re:Come comportarsi coi thread in caso di destroy()
« Risposta #1 il: 15 Maggio 2012, 18:32:12 CEST »
0
Se provi a chiamare il metodo interrupt() del tuo Thread dopo lo stop() cosa succede? Magari esce velocemente dalla chiamata bloccante.

Seconda opzione: la funzione di lettura dal socket deve essere per forza bloccante? Non riesci a gestirla in altro modo?

Offline Phate

  • Utente junior
  • **
  • Post: 123
  • Respect: +6
    • Mostra profilo
  • Dispositivo Android:
    Samsung galaxy S
  • Sistema operativo:
    Windows 7
Re:Come comportarsi coi thread in caso di destroy()
« Risposta #2 il: 16 Maggio 2012, 10:13:09 CEST »
0
Ho visto anche queste soluzioni ma alla fine ne ho trovata una, credo, migliore: ho salvato l'oggetto thread all'interno dell'applicazione e l'ho ripristinato col metodo onRestoreState.
Infatti il problema in questo caso era il cambio di orientamento del cell: l'utente non vuole uscire ma solo cambiare grafica quindi ha senso non distruggere il thread, in questo modo:
1)Non c'è l'overhead dovuto alla creazione di un nuovo thread.
2)Non devo fare la receive non bloccante, cosa che cmq costa un po' di overhead a seconda del timer tra una receive e l'altra.