On Mon, Mar 21, 2016, at 14:54, Hans-Christoph Steiner wrote: > >> If we're sticking all this stuff in NetCipher anyway, then > >> going the full Android approach is more appealing to me. > > > > I do not know what "the full Android approach" means here. > > I mean using Android patterns rather than Java patterns, like > BroadcastReceiver/LocalBroadcastManager instead of callbacks and > interfaces.
LocalBroadcastManager is an in-process event bus. It's not the only such event bus (greenrobot has theirs, Square has Otto, etc.). Nor is it the only way of handling asynchronous events (e.g., RxJava stuff). Using callbacks/listeners is the lowest-common denominator. Developers can use them directly or adapt them to their favorite asynchronous approach (e.g., write an Rx adapter). > I think the callbacks are clean, I guess my head has been more in > event-based messaging and Android APIs. The only time the Android SDK uses "event-based messaging", and exposes that plumbing, is when the events are IPC-driven (e.g., all those implicit Intent actions). So, for example, while the Android SDK *offers* LocalBroadcastManager, I cannot think of anything in the SDK itself that *requires* LocalBroadcastManager to consume some event. Usually, it is a callback/listener pattern, whether explicitly or implictly (e.g., component lifecycle callbacks). -- Mark Murphy (a Commons Guy) https://commonsware.com | https://github.com/commonsguy https://commonsware.com/blog | https://twitter.com/commonsguy _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
