Hence, the recipe for the activity-or-Notification pattern is:
Define an action string you will use when the event occurs that you want to go to the activity or notification (e.g., com.commonsware.java.packages.are.fun.EVENT).
Dynamically register a BroadcastReceiever in your activity, with an IntentFilter set up for the aforementioned action string and with a positive priority (the default priority for a filter is 0). This receiver should then have the activity do whatever it needs to do to update the UI based on this event. The receiver should also call abortBroadcast() to prevent others from getting it. Be sure to register the receiver in onStart() or onResume() and unregister the receiver in the corresponding onStop or onPause() method.
Register in your manifest a BroadcastReceiver, with an <intent-filter> set up for the aforementioned action string. This receiver should raise the Notification.
In your service (e.g., an IntentService), when the event occurs, call sendOrderedBroadcast().
And that’s it. If the activity is on-screen, its receiver will be registered, so it will get the event, process it, and cancel the broadcast. If the activity is not on-screen, its receiver will not be registered, so the event will go to the default handler, in the form of your manifest-registered BroadcastReceiver, which will raise the Notification.
Kiran Kuppa on 30 Mar 13Using Java annotations, developers can show their intent and let AndroidAnnotations generate the plumbing code at compile time. Few Features are * Dependency injection: inject views, extras, system services, resources, ... * Simplified threading model: annotate your methods so that they execute on the UI thread or on a background thread. * Event binding: annotate methods to handle events on views, no more ugly anonymous listener classes! * REST client: create a client interface, AndroidAnnotations generates the implementation. * AndroidAnnotations provide those good things and even more for less than 50kb, without any runtime perf impact!
