as isRegistered to API with internal protection. about otto HOT 4 CLOSED

We debated this early on and opted not to add it at the time. What we found was that in all of the cases where we thought this would be necessary we had either overlooked an unregistration point or had a bug in our code. For example, fragments and activities have onResume/onPause and views have onAttachedToWindow/onDetachedToWindow.

Do you have a specific use case where you are seeing this not be enough?

from otto.

That makes sense in terms of playing nice and registering/unregistering.

I'm wanting to incorporate Otto in objects running tasks on other threads (like data models). This allows android to handle on configuration changes and gives me the ability to use a producer to get the last model results if they happened to be returned on the screen rotation.

Looking ahead though I feel this won't work great because the models/objects will have to be unregistered on the subscriber callback. This was just an idea, not a must...

Would love to hear your thoughts on this.

from otto.

Hey @jjNford,

Not sure if you saw that we just merged #12 which allows for @Produce methods to return null. This means that whenever you have any long-lived classes which manage some state (e.g., last known location) they don't have to worry about registering and unregistering.

With this change a class should register immediately. When the @Produce method is called you can return null to indicate that you don't yet have anything to say. In keeping with the example, once a location is known you would post that event onto the event bus and cache the location (for any further calls to the producer method).

In regard to your follow-up question, we use another Square library called Retrofit which always gives us callbacks on the main thread to eliminate the possibility of race conditions. Since we have this behavior we always know that any posts that occur as the result of a network callback will always be on the correct thread. If you receive your callbacks on a background thread I suggest that you post a runnable to the main thread which takes the action of posting the event to the bus.

from otto.

No worries, I just have a handler in my libraries activity class with a getActivityHandler() call - I just reconnect here, works fine. Right now I'm having more trouble with ABS than anything - currently haven't found a solution. On 2.3.6 & 2.3.7 devices items added to the bar from the onCreateOptionsMenu in a SherlockFragment (used in a SherlockFragmentActivity) cause the application to crash. We could take this conversation off GitHub if you want (jj.n.ford at gmail.com).

from otto.