如何得到我的活动背景?

我真的不知道这整个事情是如何运作的,所以如果我有一个类 A,需要一个类 B的上下文,它扩展了 Activity,我如何得到这个上下文?

我正在寻找一种比将上下文作为类 A构造函数的参数更有效的方法。例如,如果类 A将有数百万个实例,那么我们最终将有数百万个指向 Context的冗余指针,而我们应该能够以某种方式只有一个地方和一个 getter 函数..。

294972 次浏览

you pass the context to class B in it's constructor, and make sure you pass getApplicationContext() instead of a activityContext()

Ok, I will give a small example on how to do what you ask

public class ClassB extends Activity
{


ClassA A1 = new ClassA(this); // for activity context


ClassA A2 = new ClassA(getApplicationContext());  // for application context.


}

You can create a constructor using parameter Context of class A then you can use this context.

Context c;

A(Context context){ this.c=context }

From B activity you create a object of class A using this constructor and passing getApplicationContext().

You can use Application class(public class in android.application package),that is:

Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml's tag, which will cause that class to be instantiated for you when the process for your application/package is created.

To use this class do:

public class App extends Application {


private static Context mContext;


public static Context getContext() {
return mContext;
}


public static void setContext(Context mContext) {
this.mContext = mContext;
}


...


}

In your manifest:

<application
android:icon="..."
android:label="..."
android:name="com.example.yourmainpackagename.App" >
class that extends Application ^^^

In Activity B:

public class B extends Activity {


public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.sampleactivitylayout);


App.setContext(this);
...
}
...
}

In class A:

Context c = App.getContext();

Note:

There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.

If you need the context of A in B, you need to pass it to B, and you can do that by passing the Activity A as parameter as others suggested. I do not see much the problem of having the many instances of A having their own pointers to B, not sure if that would even be that much of an overhead.

But if that is the problem, a possibility is to keep the pointer to A as a sort of global, avariable of the Application class, as @hasanghaforian suggested. In fact, depending on what do you need the context for, you could even use the context of the Application instead.

I'd suggest reading this article about context to better figure it out what context you need.

The best and easy way to get the activity context is putting .this after the name of the Activity. For example: If your Activity's name is SecondActivity, its context will be SecondActivity.this

In Kotlin will be :

activity?.applicationContext?.let {
it//<- you context
}

The MainActivity class has those properties you can use:

  • applicationContext
  • baseContext
  • this

See here for differences: difference and when to use getApplication(), getApplicationContext(), getBaseContext() and someClass.this

I dont know who may need this at this point but: @hasanghaforian is correct, and contrary to what @gezdy says here, no, using registerActivityLifecycleCallbacks is not a solution, no matter how you look at the problem, it doesn't even make sense...

One could... maybe create a working version that uses the registerActivityLifecycleCallbacks option but it would be unnecessarily complex and slower.

The aim is to: Proactively retrieve the top most desired Activity.

Now the problem with Hasan's answer and gezdy's answer is that neither acknowledges the fact that, the same way Fragments stack one on top of each other, Activities can ALSO be stacked, so we need a LinkedDeque...

public class ActivityRegistry extends Application {
private final LinkedList<Activity> activities = new LinkedList<>();
public<A extends Activity> boolean register(A activity) {
return !contains(activity) && activities.offerLast(activity);
}
public void unregister() {
activities.pollLast();
}


public<A extends Activity> A getLastActivity(Class<A> componentTYpe) {
Activity current = getLastActivity();
return componentTYpe.isInstance(current) ? componentTYpe.cast(current) : null;
}


public<A extends Activity> boolean contains(A activity) {
return activities.contains(activity);
}


public void clear() {
activities.clear();
}


private Activity getLastActivity() {
return activities.peekLast();
}
}

You must take into consideration that the register(A activity) method adds ONLY IF object is NOT PRESENT.

Since BOTH answers are registering Activities during the RESUME phase of the lifecycle, and then unregistering them during the DESTROY. The Registration - Unregistration cycle is NOT a CLOSED LOOP.

This means that if the app goes to the background and then to the foreground again 2 instances will be added, since the RESUMED phase gets called twice without traversing the DESTROY. My solution prevents that, but another alternative is to register during the onCreate() phase of the Activity..

Now as to the "Memory Leak" issue from the Activity perspective.

There is NO NEED to assign the context to a field, IF the context can be accessed from a method, IN FACT, methods are provided precisely to avoid MemLeaks, since, if there would be NO danger of it leaking, the variable could be easily passed via constructor parameter.

This is Gezdy's code:

public class MyBaseActivity extends Activity {
protected MyApp mMyApp; //This field will create a Memory Leak


public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mMyApp = (MyApp)this.getApplicationContext();
//If app context can be accessed via method, we dont need to assign it to a field.
}
protected void onResume() {
super.onResume();
mMyApp.setCurrentActivity(this);
}
protected void onPause() {
clearReferences();
super.onPause();
}
protected void onDestroy() {
clearReferences();
super.onDestroy();
}


private void clearReferences(){
Activity currActivity = mMyApp.getCurrentActivity();
if (this.equals(currActivity))
mMyApp.setCurrentActivity(null);
}
}

Instead do this:

public class MyBaseActivity extends Activity {


public void onCreate(Bundle savedInstanceState) {
((ActivityRegistry)getApplicationContext()).register(this);
super.onCreate(savedInstanceState);
}


protected void onDestroy() {
((ActivityRegistry)getApplicationContext()).unregister();
super.onDestroy();
}
}

Now the Activity can be retrieved like this:

    MyActivity activity = ((ActivityRegistry)getApplicationContext()).getLastActivity(MyActivity.class);
//If activity returns null, it means the last Activity was NOT of type MyActivity.class.
//If you pass Activity.class instead, it will always get you the last Activity.
//And the you must FORCE CAST into what you believe it to be the type.

Where MyActivity extends MyBaseActivity