Buy @ Amazon

Search This Blog

August 27, 2017

Android Activity's onDestroy() Ain't Your Reliable Friend



Look at the Android Activity life-cycle events in the picture beside.

The lifecycle isn't something new. You're familiar with it right? You're also that good Android developer that writes clean code, wherein you consciously override onDestroy() method to include resources clean-up code and save some state, right?

Per Android doc, it is okay and usually the practice to write cleanup code in this method but not anything beyond that.

So if you are to write code to persist state in this method, or anything else beyond resource clean-up (like threads associated with an activity), you're better off to push it up the life-cycle, either in onStop() or onPause() method.

That is how I settled in the first iteration of new learning but wasn't happy. Why? To quote Android Doc:

August 26, 2017

Android - Don't Keep Activities - Developer Options



"Don't Keep Activities" - are you aware of this must turn-on developer setting in your Android device?

Not sure about you. The first time I saw this in the developer setting, I laughed out wondering why on earth a developer would want to do this, assuming that this would hide the app performance issues.

I was so damn wrong. Contrary to my assumption, turning on this developer setting actually helps you identify performance issues. It helps you identify memory leaks of an activity.

Where do I find this? See picture attached.

How it works? When the developer option - Don't Keep Activities - is checked-on, in the device, all activities that are stopped will be destroyed almost immediately. It simulates the Android Operating System behaviour when your app is in the background and the system is short on memory; because of which it will destroy your background activities.

How is it useful? It is intended to help developers debug their apps for testing saved instance states and detecting memory leaks.

When to use it? Turn it on - always. If you find any unexpected behaviour of your app like freezes and force closures, it is a sign of bad code that requires fix.

References
1. Knowledge boost for junior Android developers — Part I
2. Don't keep activities - What is it for?

August 25, 2017

Notes On Android Notification

This post is my notes drawn from Official Android Docs and Android O: How to Use Notification Channels.

A notification is a message you display to the user outside of your apps UI.

When you tell the system to issue a notification, it first appears as an icon in the notification area like below:

To see the details of the notification, the user opens the notification drawer like below:

Both the notification area and the notification drawer are system-controlled areas that the user can view at any time.

August 21, 2017

Book Review - The Checklist Manifesto



It's a well written book shedding light on the importance of Checklists at work even if it is very critical with regards to time, cost, size of team/project etc. The author shares stories and anecdotes on how right kind of checklists can avert serious damages/mistakes.

I particularly like the way the author catches the attention of the reader in the beginning of the book. As the book gets to the later chapters, it gets dense in the domain that may or may not interest the reader.

I would recommend you get your copy from Amazon for cheaper price. Have fun reading it..

When do you use map vs flatMap in RxJava?

 Learning RxJava is an overwhelming exercise because it is a paradigm shift in the way you solve your coding problems. During this learning process, of the many doubts you'll have, one such would be, "When do you use map vs flatMap in RxJava?".

ProTip : Get used to understanding the Marble Diagram for understanding the basic concepts of Reactive Extensions.


Here is a simple thumb-rule that I use help me decide as when to use flatMap() over map() in Rx's Observable.

Once you come to a decision that you're going to employ a map transformation, you'd write your transformation code to return some Object right? If what you're returning as end result of your transformation is:
  • a non-observable object then you'd use just map(). And map() wraps that object in an Observable and emits it.
  • an Observable object, then you'd use flatMap(). And flatMap() unwraps the Observable, picks the returned object, wraps it with its own Observable and emits it.

Say for example we've a method titleCase(String inputParam) that returns Titled Cased String object of the input param. The return type of this method can be String or Observable<String>.
  • If the return type of titleCase(..) were to be mere String, then you'd use map(s -> titleCase(s))
  • If the return type of titleCase(..) were to be Observable<String>, then you'd use flatMap(s -> titleCase(s))

Hope that clarifies. And if this post helped you pick the concept, I'd appreciate you share the post and upvote this answer in StackOverflow. Thanks in advance :)

August 20, 2017

Book Review - Scalability Rules

 Scalability Rules

A book for Scalability enthusiasts

A good book that should serve as ready reference or guidance for anyone interested in the topic of availability and scaleability. Even though, the guidance/rules that this book mentions, seem  simple and seemingly intuitive, in the real-world situations you'll find violating these giving whatever excuse it be. Reading books like this re-affirms our own intuition and awakens you of risks the next time you come across situations that warrants you to apply these rules where appropriate.

The later chapters could have been better explained with examples. For instance, in the chapter on "Avoid or distribute scale", the author could have explained situations where these rules can be applied and where it does not. In the absence situational examples or use-cases, the reader might likely remain confused or worse with false sense of knowledge. The same applies in the chapter on async communication with Message Buseses, where the author talks about cost of data. Some real-world examples/use-cases would really make this book a rich resource for the reader. 

All said, this book deserves a place in the book-shelf of a developer, manager, architect or a CTO.

August 5, 2017

Book Review - Reactive Android programming


I read this book from SafariOnline. The book is a fantastic read, ridden with examples. The reader typically learns by example. It's a no fluff, just stuff to the point that saves you a lot of time. The book covers employing contemporary 3rd-party libraries where required depending on the use-cases, all blending well with the respective topic/situation.

I'd say this book is from one pragmatic programmer to a busy, impatient and hungry programmer wanting to get his hands dirty.