Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Sticky events and Producers + astroboy as a a demo of robofragments and roboguice events #28

Closed
wants to merge 8 commits into from

2 participants

@stephanenicolas

I just hacked RoboGuice and could achieve something that might interest you as a contribution :

  1. change astroboy FightForcesOfEvilActivity to a fragment. In portrait, the fragment is loaded in a separate activity. In landscape, the MasterConsoleActivity is split in two vertically and you can see the fragment with the buttons simultaneously. All buttons will remove the fragment, except the "fight forces of evil" button that will display the fragment.
  2. add support for some event : the fragment fires an event and the console activity observes it (using roboguice event manager mechanism).
  3. support for an event the other way around : the activity fires an event and the fragment observes it.

This example was developed to illustrate current roboguice features and, notably, events and fragments supports.

Nevertheless, it also pointed that, with respect to fragment life cycle, a fragment is only aware of events that occurs AFTER it is created. Thus, it is difficult for newly created fragments to fully reflect the state of the activity if an event has been triggered before they were created.

As a workaround, I contributed 2 different mechanisms :

  1. a new EventProducer interface : you can register an event producer to the event manager bus. Everytime a new listener is registered to the bus, the bus asks to a potential producer to produce an event that is fired to the new listener. You would typically implement producers as inner classes of activities and register them dynamically.
  2. a sticky event annotation : an event class can be annotated as sticky : in that case, the last instance of event of that class that is fired by the event manager will be kept in a map (class of event <-->event). The last event will be fired to a newly registered listener. This one is more handy and convenient than the previous mechanism.

Sorry for the long mail, I hope it might interest you, the idea is really to mimic something that dagger has and makes it much easier to communicate between activities and fragments with respect to their life cycles.

PS : I would like to create an annotation for producers, but I am not there yet.

@emmby
Owner

Thank you for this contribution, stephane. I'm not sure we're ready to add this kind of functionality into our event mechanism just yet. Can you point me to any docs for other event frameworks that support these two changes?

@emmby emmby closed this
@stephanenicolas

Such a feature is actually present in the 2 main event frameworks I know about :)

I am not sure I am very happy with the actual implementation I submitted (actually I don't remember its details), but I think RoboGuice should really have a feature like this.

Let's take a fragment, if you add to your activity, then if the activity fires an event, the fragment will get it.
BUT, if you do it the otherway around : first firing an event and then add the fragment, then the fragment will have lost that event. This will lead to code deduplication : 1) code to listen to the event and 2) code to set the fragment "manually" in a given state, no related to events. They will do the same stuff, but in a very different way, and with fragments it will lead to a huge amount of complexity to save their state in the arguments.

With producers/sticky events, the fragment could have received the event, even if it was added after the event was fired.

Producers offer a way to get an event lifecycle more independent from the Observer and Observable life cycles.

Oh, and last but not least : this pull request and feature enhancement has been motivated by a strong experience using RoboGuice with fragments. In my most recent project we made a quite big app (for a bank, over 50 000 lines of code, 1000 classes) and it used a lot of fragments, and events to communicate with activities...

I will not insist and I trust your experience but I would love to be convinced by arguments stronger than mine. ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.