12

currently, in my App I have the following class:

public class MyApp extends Application {

    private static Context context;

    public void onCreate(){
        super.onCreate();
        MyApp.context = getApplicationContext();
    }

    public static Context getContext() {
        return MyApp.context;
    }
}

I use this to have Context in classes that are neither Activities nor Fragment. It's there any difference between use the context stored on this class and use and activity as context? It is a good practice to have this class or should I provide an activity as context to any class who needs it?

Thanks.

mario595
  • 3,671
  • 7
  • 34
  • 57
  • Providing an Activity context can lead to memory leaks if you store it in the object you're passing it to and the object lives longer than the Activity, what you posted can not. But some times you need the Activity context, see CommonsWare answer. – Steve M Jan 24 '14 at 15:38

3 Answers3

16

It's there any difference between use the context stored on this class and use and activity as context?

Yes. Please read Dave Smith's epic blog post on the subject. In summary: only use an Application when you know why Application is the right answer... and it rarely is.

It is a good practice to have this class

IMHO, not usually. You may sometimes need an Application object, but you do not need your own custom subclass, and you do not need to make it a singleton.

should I provide an activity as context to any class who needs it?

You supply the right Context instance to any method that needs it. As Dave Smith describes in that blog post, not all Context instances are created equal. Only use Application when Application is the right sort of Context.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
6

Yes, this is fine. Having a static reference to the Application's Context will not cause any memory leak. This Context exists as long as the process is alive.

David Wasser
  • 93,459
  • 16
  • 209
  • 274
0

If you need to do this then I think you need to rethink your design. You shouldn't need Context (that I can think of) outside of an Activity, Fragment, Service, etc. Everything should stem from the basic application components and you should be able to appropriately pass down the Context without needing to do this. For example, you can call getContext() from Views to grab it. If you need to use it in a POJO then it should be somewhat tied to an application component and have it passed in through the constructor.

edit: Seems like you might be fine with the memory leak issue? I remember reading about screen orientation changes wrecking havoc when someone did this. In any case, it doesn't make much sense from a design point of view to me.

edit2: You guys are right. I was incorrectly remembering Romain's blog article about it.

telkins
  • 10,440
  • 8
  • 52
  • 79
  • 1
    Actually, there are many places where you need a `Context` outside of an `Activity` or a `Fragment`. Here's a few examples: 1) I need a string resource to generate a log message; 2) I need to read data from a file in the projects assets; 3) I want to generate a `Toast` – David Wasser Jan 24 '14 at 15:11
  • 2
    @DavidWasser All of those seem like you could pass down a Context rather than doing it statically. – telkins Jan 24 '14 at 15:13
  • 1
    Sorry, beg to differ. I've done this before and sometimes it requires passing the `Context` through many layers of abstraction. In my opinion this is completely unnecessary, counter-intuitive, confusing and is difficult to maintain. In my opinion, the `Application` class should have a static method to get the application's `Context` anyway. – David Wasser Jan 24 '14 at 15:18
  • I agree with David, there are many places where this pattern is helpful and there are not any gotchas involved. However, CommonsWare also makes good points. – Steve M Jan 24 '14 at 15:31