2

I just read Using context in a fragment cause I need to get a context in order to initialize a database. The 2 most voted answers where using Fragment#getActivity() to get the Context or doing it inside Fragment#onAttach(Activity) callback method.

The thing is, in order to maintain a well documented code, I want to avoid doing things the "alternate" way, but doing it the way it was supposed to.

Judging by Fragment life-cycle found in here: http://developer.android.com/guide/components/fragments.html#Creating seems like onAttach() is called before onCreate, which means getActivity() should NOT return null at this point.

Questions would be:

  1. is it meant to initialize a database inside onAttach()?
  2. is it possible for getActivity() to return null when called inside onCreate() even though onAttach() has already been called?
Community
  • 1
  • 1
Christopher Francisco
  • 15,672
  • 28
  • 94
  • 206
  • Did you solve this? Did you have a better answer you can add or can you accept another to close this question and get it off the unanswered android list, thanks! – Nick Cardoso Apr 27 '14 at 17:18
  • Yes, I ended up making my database a `Singletοn` so each of my fragments inside the `ViewPager` would have the same connection. Then I initialized it on my `Application#onCreate()` subclass – Christopher Francisco Apr 27 '14 at 17:44
  • You're allowed to answer your own questions - you should do just to tidy up the unanswered list – Nick Cardoso Apr 27 '14 at 17:46

2 Answers2

1

It seems like you would be better off creating a ContentProvider to do setup at the correct time. This allows you to access the DB easily from anywhere via the content resolver.

Nick Cardoso
  • 20,807
  • 14
  • 73
  • 124
  • 1
    +1 because i love using CP ... added values will be also: that CP are compatible with Loaders, by adding data through CP you shouldn't be worry about ListView refreshing - it will be done automagically:) – Selvin Feb 17 '14 at 21:21
  • Creating a ContentProvider can be an unnecessary chore. The question was about Context not ContentProvider. – Alexander Kulyakhtin Feb 17 '14 at 21:54
-1

To initialize a database the ApplicationContext is sufficient.

You can create your own Application subclass like follows (you also have to define it in your manifest)

  class MyApp extends Application {

    private static Application mInstance;

    public void onCreate() {
       super.onCreate();
       mInstance = this;
    }

    public static void context() { return mInstance.getApplicationContext(); }
}

Then from any place where you need your application context you can call MyApp.context()

In your manifest:

<application android:name="MyApp"/>
Alexander Kulyakhtin
  • 47,782
  • 38
  • 107
  • 158
  • 1
    I really don't understand why you would do something like that. Calling `getApplicationContext()` from within a `Application` instance is basically just the same as using `this`. – Squonk Feb 17 '14 at 21:09
  • @Squonk I can use this way when calling not from Activity, I can use that in any class. Or do you mean getApplicationContext is the same as Application.this. I never thought of that, getApplicationContext() seems to be more explicit. – Alexander Kulyakhtin Feb 17 '14 at 21:10
  • Many places require an Activity context, so the App Context wouldn't be useful. Even disregarding that point, creating a static method to do things goes against OO principals and as Squank mentioned, getApplicationContext() exists – Nick Cardoso Feb 17 '14 at 21:33
  • @Nick Cardoso Could you, please, elaborate how it goes against OO pronciples? – Alexander Kulyakhtin Feb 17 '14 at 21:53
  • @Alex : I'm not sure of Nick's reasoning but think of it like this...there is only one instance of an Application object in an Android process. As it directly extends ContextWrapper (which exposes getApplicationContext()) your approach to maintaining a static reference to the Application and using that to call getApplicationContext() is redundant. Also, because ContextWrapper extends Context and there is exactly one instance of Application object, then MyApp IS your Application Context. So basically your approach uses several ways of doing the same thing which aren't necessary. – Squonk Feb 18 '14 at 08:31
  • 1
    @Alex : (continued, ran out of room). Also on a side note as Nick suggested there are cases where you must use an Activity Context (although as you say in your answer the Application Context is fine for DB stuff). The reason why you might need an Activity Context is the Application Context is only a partial Context and simply won't work right for many UI-related tasks (an Application has no UI and no concept of what a UI needs). – Squonk Feb 18 '14 at 08:42