0

In Android programming the single most used parameter that is passed almost everywhere is Context. And we know the purposes it serves. But we can't find out why we should pass it for those purposes, and why not accessing it from a global static place.

Based on Uncle Bob's Clean Code, one way of getting cleaner code is by reducing parameters, making them more meaningful to the task you're doing. Based on this, and based on DRYing parameters, we decided to give it a shot, and create a fully-featured application that has activities, fragments, foreground and background services, notifications, media, etc. and uses many device APIs like camera, GPS, etc. and is a real-world application, and only have one static context initialized at the application creation.

So in the application creation we created a public static Context context variable, and we initialized it using getApplicationContext() method in onCreate() override.

Then instead of passing context like this, getContext, etc. throughout code, we simply used App.context, and we didn't pass it as a constructor parameter to our adapters and other utility functions.

Now after venturing this bold movement, we don't see any problem with our app. Everything works just fine, battery consumption is not changed, at least it's not measureable to us so it's very low. Memory consumption is not changed and we can't measure it. Application performance and speed is not changed measurably.

So we have this really big question in our mind that, what are the downsides on our approach? Why Android guys don't just expose a global context that can be initialized and remove all context parameters from the entire ecosystem, only accessing that global variable anytime they need it?

mohammad rostami siahgeli
  • 6,787
  • 9
  • 49
  • 89
  • have you read this https://stackoverflow.com/questions/7026507/why-are-static-variables-considered-evil – AskNilesh Jul 20 '18 at 07:55
  • https://stackoverflow.com/questions/3826905/singletons-vs-application-context-in-android – AskNilesh Jul 20 '18 at 07:56
  • 1
    You can read this https://www.philosophicalhacker.com/2015/07/14/why-static-references-to-application-contexts-are-probably-not-the-best-idea/ – Amrita Jul 20 '18 at 08:03

3 Answers3

1

Please read this blog carefully you will understand Context better.

Static variables defined at global scope of the class and so they also refereed as class member.

  1. You can not control creation and destruction of static variable. Usefully they have been created at program loading and destroyed when program unload.
  2. Since static variable are class member, all threads tries to access them has to be manage.
  3. If one thread change value of a static variable that can possibly break functionality of other threads.
Sagar Bhagwat
  • 103
  • 1
  • 9
0

In my projects, I use the static application context for everything except graphics. The fact is that the application context does not contain information about the style and if you create a widget based on it, then it will have a default style.

On this moment, I have never faced the problems of this approach. Importantly, I do not write tests for my projects. But I'm sure that this will not be a problem.

I also will be very grateful if you point me to the problems of such use of the context. (except testing)

Zeon
  • 535
  • 8
  • 23
0

Your application doesn't break because you are using the Application Context: this may not be THE best practice, but it is generally fine.

What you are missing there is that Context is an abstract class with many different implementations (an Activity is a Context, a Service is a Context, the Application is a Context) with different properties and capabilities. The Activity has an entire graphic context associated whit it and a full view hierarchy that can occupy megabytes in memory.

One common mistake (that I did myself in my early days) was to store the Activity in a static field: this led to memory leaks by having two entire views hierarchy in memory as soon as the user puts the app in background, the Activity reaches onDestroy(...) callback and the user opens the app again.

spacifici
  • 2,186
  • 2
  • 16
  • 28