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 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
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.