Cooking is hard work that’s often hard to be passionate about. Once I started seeing the similarities to coding, the whole process became a lot more interesting to me.
March 9 came and I started to look into recipes about "Mucenici" or "fluffy baked eights" (romanian traditional bakery). Talking around about this I found out that there are different views about this culinary desert, and I must explain myself clear what I want to accomplish.
Beyond satisfying my guests with a new recipe, there’s one more important person to keep happy in my career as an Android Developer, the Future Me!
Future Me will always have a lot of questions about how and why I coded things the way I did. So good communication is the crucial component of making goals reachable and Future Me happy.
Today I want to bake some awesome "mucenici" and explain an easy and clear communication mechanism in Android.
Android apps can send or receive messages from the Android system itself or other Android apps. These messages are sent when an event of interest occurs. For example, the Android system can send a message when the device starts charging and apps that might be interested in are notified.
Similarly, when my friends came by and ordered some excellent "mucenici" they didn’t necessarily know which cook will prepare their dish. They just give the order to me, which I posted it to the kitchen in order to be prepared by the available cook. In this way, they issued a request without knowing the receiver. The request was encapsulated as an object and sent it off. How to complete the request is another mechanism.
Breaking this down using EventBus, a popular Android Framework that supports this communication pattern we have the following diagram:
"new excellent mucenici" – is the Event. Event is an object that can be triggered by user input, server data, or pretty much anything else in your app. You can create specific subclasses which carry data as well:
This pattern works its magic at run-time, but Future Me might have a little trouble tracing this pattern unless the readability of the code is easy and definitely, I should not overuse it.
The Android SDK provides a component called LocalBroadcastManager which, basically, publishes Intents (events) for its subscribers to receive in execution time. So BroadcastReceiver is an abstract class that by extending it we detail what kind of Intents we expect to receive and what to do in case one is received. Based on this approach the EventBus library came alive to replace LocalBroadcastManager and allowing any Activity (screen where user interact with your app) to register itself easily, to implement a callback later for each type of Event you want to have control of.
The advantage is that it is no longer necessary to extend the class BroadcastReceiver, neither to modify the Manifest according to this, Events and callbacks are simply created for them inside the Activities, which is far more legible and easier to implement.
Ability to change the receiver thread easy to be done
If you abuse it, you lose control over who’s notifying who
I believe you have a great recipe to surprise the world with. Put it to practice and start thinking at Future You. The end results — whether they be a Micheline restaurant or smartphone app — have the potential to invoke the full range of human emotions.
Thank you for reading this. If you have any questions, comments or funny jokes comment below.
Does front-end development as a we know it still exist; or has the role evolved into something we no longer recognise? As with evolution in nature, the evolution of "front-end" has resulted in several distinct flavours --- and in my opinion --- an identity crisis.