This is chapter 3 of our series Mastering Android Context. We will cover types of Context present in Android and which one to use when. If you have not read Chapter 2, we recommend to spend 5 minutes understanding types of Context.

From chapter 2 we understood simplified version of Context and divided Context into 2 buckets. UI and Non-UI Context. Keep in mind, Context is a short living object except Application context.

I am Confused! Where to use what!

Rule of thumb:

* Do you need to access UI related stuff? Use UI-Context.
* Otherwise, Use Non-UI Context.

Now the question arises what will go wrong if you a context at wrong place.

Short answer: Your bank balance dies. Follwing are few scenarios.

Scenario 1
Lets say you are inflating a layout and you use Non-UI Context. What may go wrong? You can guess in this case, you will not get themed layout and cat eyes of your designer will catch it when they are half asleep. Not so bad, hmmm! Bearable.

Scenario 2
You pass UI-Context to someplace where all it needs is resource access OR file system access. What can no wrong? Short Answer: Nothing. Remember, UI-Context = Context + Theme. It will gladly serve as context for you.

Scenario 3
You pass UI-Context to someplace where all it needs is resource access OR file system access BUT it is a long operation in background. Say downloading a file. Now what can go wrong? Short Answer: Memory leak. If you are lucky and download completes soon, the object is released and everything is fine. Sun is shining and birds are chirping. This is one of the most common mistake developers make. They pass reference of UI-Context to long living objects and sometimes it has zero side effect.

However, sometimes irrespective of long running object life; Android wants to claim memory for either one of your next component requirement OR other component requirement and woooshhhh!!! You greet out of memory in your app. Don’t worry we will explain. It is not the worst thing we can do after what we have done to our planet.

Memory Leak OR Crash! Thats it.

Yes this is the worst case scenario when you use context at wrong place. If you are new to app development world, let me share a wisdom. Memory leaks are inversely proportional to your experience. Every Android developer has leaked memory. There is no shame in doing so. Shame is when you repeat the mistake again and leak it same way. If you leak memory with different way everytime, congrats you are growing. Don’t know what is memory leak? We got you covered with our insane story.

Suppose your mom has $60 and you are 3 children at home inluding your father. When someone visits city, they take $20 with them for emergency. It is law you can’t bypass. Everytime they come back, they return $20 to mother. So max 3 people can visit city anytime.

One night, you had a party and you came drunk. Next morning you woke up late, You think you returned money to your mom but she could not find $20 from you. By this time unaware of situation, your sibling and father left the home. Your sibling lent $20 to his friend thinking he will return by evening but his friend got stuck and your sibling had to return without $20. Your father found a good deal and bought bunch of flowers for your mom and a pair of T-Shirt for you both. Remember he is anaware of your sibling situation and your situation.

Next morning, you all are left with nothing and crisis happens. You hit rock bottom and call it Out of Money. Suddenly your sibling friends arrives and hands you $20 which he lent. You are saved, till one more drunken night.

Thats what happens in app world, RAM is a precious resource. It is reusable entity and you are not allowed to lose it. If you lose permanently, you meet OOM. If you lose for sometime, you meet OOM when it does not return when needed. That’s why the reproduction scenario are very difficult, hence the solution.

When an object is out lived than desired time, we call it is leaked. When that object has lot of weight, we say F***k. By weight I mean it is holding lot of memory, which means bits. Could be in any form: byte array,bitmaps, so many objects and so on. As in mobile world, you deal with bitmaps a lot and you are prone to keep reference to it. Sometimes you just pass your object which is holding the bitmap and make it live longer than its supposed life, you introduce a leak.

Okay I get it but what is relation of Context here?

Say it aloud Bad Design Spotted, Almost everything in Android needs access to Context. Naive developers pass UI-Context because thats what they have access to very easily. They pass short-living context usually Activity context to long living objects and before the memory/money is returned back to Mom, you hit crisis. Woooshhh!!! Simplest form is Async Task OR Broadcast Receiver. I can’t explain in detail here. I am not sorry.

Wait, this chapter has become more of memory leak chapter than Context chapter. Reason behind that is you pay price when you use context at wrong place and sometimes the price is trust. If your app deals with user money and it crashes in between of a payment, you lose credibility. If your app crashes your competitor app without letting them know, you get bonus. Dog eat Dog world we live in.

Summary

  • Do you need to access UI related stuff? Use UI-Context. Inflating Views and showing dialogs are the two use cases I can think of.
  • Otherwise, Use Non-UI Context.
  • Make sure you do not pass short-living context to long-living objects
  • Do not forget to read next chapter to learn more about Context

Click here to read Chapter 4.

Subscribe to newsletter and keep learning good stuff

Email

👉 If you like article, click on ♥️ recommend and share on social 👥 media.
👉 Feel free to comment 💬
👉 Follow me 👀 for the more interesting articles. Twitter Medium
👉 Subscribe to newsletter and keep learning