2012-11-07 13 views
7

ho iniziato ad usare OTTO da Square ieri, finora ho avuto un buon inizio.OTTO e frammenti in altri activitys

Otto grandi opere fuori dalla scatola quando si hanno le Frammenti già ospitato in un FragmentActivity e hai solo bisogno di comunicare tra Frammento ospitato da quel FragmentActivity.

Quando ospitato già, il vostro #onResume() Methode viene chiamato e il frammento può registrarsi sul EventBus:

@Override 
public void onResume() 
{ 
    super.onResume(); 
    BusProvider.getInstance().register(this); 
} 

mio problema:

il frammento che è incorporato in un più L'attività che dovrebbe ricevere l'evento tramite Eventbus è la seguente:

public AnotherFragmentHostedInSomeActivity extends Fragment 
{ 
     ..... 

    @Subscribe 
    public void onSomethingHappend(final Event event) 
    { 

      final SomeObject deliveredObject = event.getSomeObject(); 

Ma sembra che le cose sono ancora complicate quando si desidera chiamare un'altra attività che ospita un frammento come questo Codice non:

public class SomeFragmentSendingDataToAnotherFragment extends Fragment 
{ 
      ... 
    private void sendData() 
    { 
      final Intent intent = new Intent(applicationContext, SomeActivity.class); 
      applicationContext.startActivity(intent);         
      BusProvider.getInstance().post(new Event(someObject)); 

Come si può già vedere, questo codice è poco raccomandabile. Avvio di un'attività e invio di dati al frammento ospitato da tale attività non può funzionare a causa del ciclo di vita. Quindi l'attività viene creata e anche le frazioni. Ad un certo momento viene richiamato il metodo onResume per consentire a Fragement di registrarsi tramite @Subscribe. Ma tutto questo succede dopo il l'evento è già stato pubblicato tramite l'EventBus. Quindi il frammento di interrest non viene mai chiamato da EventBus.

Qualcuno sa come farlo in modo intelligente?

Alcune informazioni extra: Ieri ho avuto un bel playaround con OTTO. Il problema è disponibile solo nel mio progetto quando ho bisogno di inviare dati a un'altra attività, che nel mio caso accade sempre quando l'APP funziona su uno smartphone, non su un tablet. Prima di inviare tutti i dati tramite Intent e Parcelable. Otto ridurrebbe la necessità di scrivere oggetti Parcleable, quindi mi piacerebbe andare in questo modo.

Grazie per le risposte

risposta

16

Con il tempo inizia la seconda attività, la vostra attività originale è andato. Come altri hanno sottolineato, se si desidera passare i dati da un'attività all'attività, l'utilizzo di Intents è probabilmente la migliore.

Se si vuole veramente un bus evento, è necessario un oggetto che rimane attivo anche dopo la prima attività va via. In Android, questo è qualcosa legato al contesto dell'applicazione o se si utilizza Dagger o Guice, un @Singleton.

Questo Singleton è dove si utilizza @Produce annotazioni di Otto. Quando la seconda attività si abbona al bus, riceverà tutti i dati dal metodo @Produce.

+0

Grazie Eric per averlo chiarito. Ho avuto un'impressione diversa di ciò che il Bus può fare. Il Lifecycle semplicemente non gioca lì. Quindi ho ancora bisogno di sapere se il mio frammento è in una sorta di 'modalità' Tablet o telefono per sparare all'evento. – Kitesurfer

0

Hai provato a usare l'annotazione @Produce? Quando il frammento nella seconda attività si registra sul bus, verrà eseguito qualsiasi metodo @Subscribe con un metodo @Produce corrispondente.

+0

Ho provato questo. Ho aggiunto anche alcuni Sottoscrittori DeadObject per ottenere tutti gli Oggetti non consegnati. Vedo ancora che è stato chiamato. Ho scavato tru il codice OTTO. Per me il Problema sembra che l'attività venga incrementata da Async a OTTO, ad un certo punto viene chiamato onResume, ma questo è il modo per arrivare in ritardo allo scenario. Devo posticipare la chiamata dopo l'OTTO per far funzionare questo aspetto, che è dubbiamente aswel. \t \t IntentTool.showForecastActivity (getSherlockActivity(). GetApplicationContext()); \t \t BusProvider.getInstance(). Post (new Event (oggetto)); – Kitesurfer

+0

A me sembra che tu stia utilizzando il bus eventi in modo errato. Se devi pubblicare un evento mentre un'attività sta iniziando, passa i dati attraverso l'intento. – SeanPONeil

+0

Beh, l'ho fatto prima. Se vuoi mantenere le cose semplici, voglio usare il Bus se possibile. Come altrimenti ho due metodi che sono responsabili nella gestione dei dati in arrivo. – Kitesurfer

1

È possibile controllare la risposta di Jake Wharton postato su GitHub Otto issue. È possibile utilizzare @Producer.

quando si effettuano richieste HTTP e si mantiene la risposta memorizzata in cache da qualche parte (ad esempio, un elenco di dipendenti). La maggior parte delle persone darebbe il via ad una richiesta e la loro attività agisce direttamente quando arriva una risposta su un callback. I problemi sorgono qui quando quella richiamata avviene dopo onPause e prima di onResume, come accade quando un dispositivo viene ruotato. Quello che puoi invece fare è pubblicare un evento quando la chiamata HTTP ritorna sul bus in modo che chiunque lo ascolti lo riceva e lo invii anche alla cache. Quindi puoi avere un produttore che parla alla cache per produrre i risultati della chiamata HTTP, se qualche nuovo abbonato è interessato alla risposta. In questo modo, quando interrompi la tua attività (e cancella la registrazione) e ottieni il ritorno della chiamata, una volta che riprendi (e ti registri nuovamente) il produttore verrà chiamato e l'attività verrà notificata.

Problemi correlati