How to test activity kill -> recreate lifecycle with saveInstanceState - android

I try to write an instrumentation test that tests the activity lifecycle where my activity gets killed and it's instance state gets saved and then gets recreated with this instance state.
I can test this behavior manually by limiting the background process limit to "no background processes" in the developer settings of my device, but I want to be able to have an automated test that proves that my activity can be recreated.
My activity has a fragment with id R.id.content_frame.
So for I have this:
public class MainActivityInstrumentationTest extends ActivityInstrumentationTestCase2<MainActivity> {
public void testKillCreateLifeCycleWithProfileFragment() throws Throwable {
final Activity activity = getActivity();
navigateToProfile(activity);
Thread.sleep(5000);
runTestOnUiThread(new Runnable() {
#Override
public void run() {
activity.recreate();
}
});
getInstrumentation().waitForIdleSync();
Thread.sleep(5000);
assertProfileFragmentIsVisible((FragmentActivity) activity);
}
private void assertProfileFragmentIsVisible(FragmentActivity activity) {
FragmentManager supportFragmentManager = activity.getSupportFragmentManager();
Fragment currentFragment = supportFragmentManager.findFragmentById(R.id.content_frame);
assertEquals(ProfileFragment.class.getName(), currentFragment.getClass().getName());
}
}
activity.recreate goes through all the live cycle callback methods and ultimalty calls onCreate with the saved bundle but the fragmentManager in my assertProfileFragmentIsVisible method does not contain any fragments.
Also I'm not sure whether to use activity.recreate is a right way to go. I tried many other ways like calling each life cycle method manually with getInstrumentation().callActivityOn...but then ultimately found no way of creating the activity with the saved bundle..
Any ideas on how I can create such an instrumentation test would be appreciated!
Regards
Frank

Just in case anybody is interested in my final solution:
The problem was that I put the reference to the old activity to assertProfileFragmentIsVisible. But activity.recreate() creates a new activity instance.
The problem remains how to get this reference.
I managed to obtain a reference to the new activity by using the ActivityMonitor.
So my complete test now looks as follows:
public void testKillCreateLifeCycle() throws Throwable {
Instrumentation.ActivityMonitor mainActivityMonitor = new Instrumentation.ActivityMonitor(MainActivity.class.getName(), null, false);
getInstrumentation().addMonitor(mainActivityMonitor);
final Activity activity = getActivity();
mainActivityMonitor.waitForActivityWithTimeout(5000);
navigateToFragment(activity);
runTestOnUiThread(new Runnable() {
#Override
public void run() {
activity.recreate();
}
});
getInstrumentation().waitForIdleSync();
Activity newActivity = mainActivityMonitor.getLastActivity();
assertFragmentIsVisible((FragmentActivity) newActivity, getExpectedFragment());
}

Related

Android - App crashes at re-launch after app being force closed by OS because of permission disabled

Steps to produce the problem.
1) Launch Tasks.class activity
2) Hit home button puting the app in the background
3) Go to Settings->permissions and disable a permission which results in my app being force closed by the OS
4) Open app from launcher ---> app resumes Tasks.class activity instead of opening MainActivity --> CRASH
It crashed at listView.setAdapter(mAdapter); because listView was now null as were all class variables; Here is my activity. It uses the TasksFragment class as data retainer to handle orientation changes. When the TasksFragment is created it starts loading data with an AsyncTask and notifies the Activity when new data are fetched using the callbacks
public class Tasks extends FragmentActivity implements TasksFragment.TaskCallbacks{
TasksFragment f;
FragmentManager fm;
String TASKS_TAG="TASKS";
searchList = new ArrayList<Task>();
TaskAdapter mAdapter;
ListView listView;
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_tasks);
.
.
.
fm = getSupportFragmentManager();
f = (TasksFragment) fm.findFragmentByTag(TASKS_TAG);
if (f == null) {
f = new TasksFragment();
fm.beginTransaction().add(f, TASKS_TAG).commit();
}
else{
preLoad();
postLoad();
}
}
#Override //TaskFragmentCallback
public void onPreExecute() {
preLoad();
}
#Override //TaskFragmentCallback
public void onProgressUpdate(Task task) {
searchList.add(task);
mAdapter.notifyDataSetChanged();
}
#Override //TaskFragmentCallback
public void onCancelled() { }
#Override //TaskFragmentCallback
public void onPostExecute() {
postLoad();
}
public void preLoad(){
searchList = new ArrayList<Task>();
mAdapter = new TaskAdapter(this,searchList,true);
listView.setAdapter(mAdapter);
}
public void postLoad(){
searchList.clear();
searchList.addAll(f.taskList);
mAdapter.notifyDataSetChanged();
}
}
I managed to make it not crash replacing the onPreExecute callback with
#Override //TaskFragmentCallback
public void onPreExecute() {
if(listView!=null){
preLoad();
}
}
I used log statements to determine the sequence of events and I saw the following:
First app launch and lauch Tasks.class
ON ACTIVITY CREATE
ON FRAGMENT CREATE
on pre execute callback
preload called by callback
ON ACTIVITY RESUME
On reopen after app termination while Tasks.class was open and app was put to background
ON FRAGMENT CREATE
on pre execute callback //this is where it would crash
ON ACTIVITY CREATE
preload called by activity because fragment!=null
ON ACTIVITY RESUME
I can't understand why the fragment is created before the activity...who called this fragment to be created? Though the if(listView!=null) condition solved my problem I think it's a bandaid and not a real solution. Can someone shed some wisdom on this problem ?
What I believe is happening (somebody correct me if I'm wrong) is that because you're artificially shutting down the application with System.exit(0) which is not a recommended practice (so far as I know) in Android, your Fragment isn't being cleanly detached. This results in the Fragment being resumed when you open the app back up.
The check you're doing if (listView != null) works because your Fragment is sort of a ghost. It still exists, but it's not attached to the activity and so it can't obtain a reference to the ListView you're trying to use. A similar, but more "valid" check might be if (this.getActivity() != null).
From android System documentation
Causes the VM to stop running and the program to exit with the given exit status. If runFinalizersOnExit(boolean) has been previously invoked with a true argument, then all objects will be properly garbage-collected and finalized first.
Not sure it it will make a difference. Generally I never exit() an android program.

Android: Is There A Way To Wait Until A Fragment Attaches To An Activity?

So Adopting The Design Pattern described here whereby a Async Task wrapped around a retained fragment via the setRetainInstance as seen described here
http://www.androiddesignpatterns.com/2013/04/retaining-objects-across-config-changes.html
Im having an issue where a task is started before the worker fragment can attach to the activity leaving the mCallBack to be null at the same time onPreExecute is called which throws a nullPointerException/
This is largely due to the fact that the async task is started via a method call (a start method which creates an instance of the inner async task) and not inside onCreate or OnActivityCreated since the task can be started again (under a new instance of it) and cannot be done so in onCreate or OnActivity created since the life cycle of these methods only call 1 time because of the setRetainInstance as far I as know.
My question is where a way to program some sort of routine whereby a wait until fragment has attached to activity routine and if so do the task that you need to do?
Many thanks.
Update1: Code Posted
This is how the worker fragment is being added. When the user presses the send feedback button. This OnClick Listener is invoked. The final if statement you see is what starts the async task. Note that this code is inside another fragment.
#Override
public void onClick(View v)
{
// TODO Auto-generated method stub
FragmentManager fm = getActivity().getSupportFragmentManager();
mThreadFragment = (ConnectToServerForResults) fm.findFragmentByTag(ConnectToServerForResults.class.getName());
if(mThreadFragment == null)
{
mThreadFragment = new ConnectToServerForResults();
fm.beginTransaction().add(mThreadFragment, ConnectToServerForResults.class.getName()).commit();
}
if(!mThreadFragment.isRunning())
{
mThreadFragment.startSendFeedBack(3, preventSQLInjections(),getResources().getString(R.string.app_name));
}
else
{
//Work in progress :D
}
}
Worker Fragment Start Task Method
public void startSendFeedBack(int requestCode,String feedback,String appName)
{
XAMPP_URL ="http://10.0.2.2/testStuff/feed.php";
http = new HTTPConnection();
http.execute(String.valueOf(requestCode),XAMPP_URL,feedback,appName);
mRunning = true;
}
Worker Fragment OnAttach
#Override
public void onAttach(Activity activity)
{
// TODO Auto-generated method stub
super.onAttach(activity);
Log.d("ERSEN", "onAttach");
if(!(activity instanceof ResultAsyncTaskCallbacks))
{
throw new IllegalStateException("activity must implement the AsyncTaskCallbacks interface.");
}
mCallback = (ResultAsyncTaskCallbacks) activity;
}
so I made a solution which solved the problems. May not be the best solution but my problems appear resolved.
I added a call back to my interface called onThreadFragmentAttached()
public static interface ResultAsyncTaskCallbacks
{
void onPreExecuteResults();
void onCancelledResults();
void onPostExecuteResults();
void onThreadFragmentAttached();
}
I added a class variable to the worker fragment
private boolean isFirstTime=true;
This Boolean at the start says that the fragment is being added for the first time
In OnActivityCreated I can safely assume that the fragment is attached because this is what that method signifies.
In there is this logic. Check if firstTime is true (yes would be if the fragment is added for the first time). If call onThreadFragmentAttached();. Set firstTime to false because the fragment is added. This false is preserved through config changes because this fragment is retained.
if(isFirstTime == true)
{
mCallback.onThreadFragmentAttached();
isFirstTime = false;
}
In main activity which implements the callbacks
#Override
public void onThreadFragmentAttached(int fragmentCode)
{
FB = (FeedBack)fragmentManger.findFragmentByTag(FeedBack.class.getName());
FB.sendFeedback();
}
Find the feedback fragment (this was my fragment which needed to start a task) and call sendFeedBack method.
This is the method which simply calls the start method.
public void sendFeedback()
{
mThreadFragment.startSendFeedBack(3, preventSQLInjections(),getResources().getString(R.string.app_name));
}
In my onClick I have the following logic
//Check if there is not a task running at the moment
if(!mThreadFragment.isRunning()) //No task
{
//if its the first time worker fragment is being added it will start the task itself via the onThreadFragmentAttached callback (inside main activity) which then calls the sendFeedBack method that starts the task
if(mThreadFragment.getIsFirstTime() != true) //this is here in cases where the thread fragment is already attached and the task can be started as normal.
{
sendFeedback();
}
}
This checks if the fragment has already been added and just to go ahead and start the task. Note the getIsFirstTime method just returns the value of the class variable isFirstTime. If its false proceed as normal because its already attached. if it was true this would be bypassed and the task would start anyway via the onThreadAttachedCallback();

Listener behavior in relation to Activity lifecycle

I have an Activity with a private OnSharedPreferenceChangeListener, the listener's work is defined on the onCreate() method of the Activity. The listener is registered to the sharedPreferences of the application.
The change itself is triggered by a Service in response to an sms received intent.
Will the listener receive the callback when the Activity itself has died? are there cases where it will not?
The listener is defined (roughly):
private OnSharedPreferenceChangeListener _sharedPreferenceListener;
public void onCreate(Bundle bundle){
...
_prefs = PreferenceManager.getDefaultSharedPreferences(this);
_prefs.registerOnSharedPreferenceChangeListener(_sharedPreferenceListener);
...
_sharedPreferenceListener = new SharedPreferences.OnSharedPreferenceChangeListener(){ /*doing some work here*/};
...
}
please igonre the logic here if correct or not, assume that the code works, my main concern is how the listener reacts to changes in the lifecycle of the activity.
Thanks,
actually, since the listener doesn't know anything about the activity (and as such you can use it anywhere , not just in an activity), you will get notified no matter where you use it.
Also, since you can't know for sure what it does with the context , you should use the application context instead in this case (so that you won't have memory leaks, though I doubt it needs a reference to the activity).
Of course, if the listener itself is referenced by weak reference, and the activity doesn't have any reference to itself on any other class, the listener can be GC-ed too. You can see in the code of Android (or at least of API 19) that in the class "android.app.SharedPreferencesImpl" (example link here) , you have a WeakHashMap of listeners, so it might mean that the activity that hosts the listener can be GC-ed and so the listener will stop from being called. Here is the relavant code of Android:
private final WeakHashMap<OnSharedPreferenceChangeListener, Object> mListeners =
new WeakHashMap<OnSharedPreferenceChangeListener, Object>();
...
public void registerOnSharedPreferenceChangeListener(OnSharedPreferenceChangeListener listener) {
synchronized(this) {
mListeners.put(listener, mContent);
}
}
So, as I've written, best if you just put the application context in case you wish to keep listening to this event.
Or, in case you do wish to stop listening to this event, just unregister it when the activity is being destroyed.
to prove it, you can simply run your app...
here's my proof app:
MainActivity.java
public class MainActivity extends Activity {
#Override
protected void onCreate(final Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
final SharedPreferences preferences = PreferenceManager.getDefaultSharedPreferences(getApplicationContext());
preferences.registerOnSharedPreferenceChangeListener(new SharedPreferences.OnSharedPreferenceChangeListener() {
#Override
public void onSharedPreferenceChanged(final SharedPreferences sharedPreferences, final String key) {
android.util.Log.d("AppLog", "changed!");
}
});
new Handler().postDelayed(new Runnable() {
#Override
public void run() {
startActivity(new Intent(MainActivity.this, Activity2.class));
}
}, 1000);
finish();
}
}
Activity2.java
public class Activity2 extends Activity {
#Override
protected void onCreate(final Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_activity2);
//if you call here System.gc(); , you have a good chance that the listener won't be called
new Handler().postDelayed(new Runnable() {
#Override
public void run() {
//this may or may not cause the listener to write to the log
final SharedPreferences preferences = PreferenceManager.getDefaultSharedPreferences(Activity2.this);
preferences.edit().putBoolean("test", true).commit();
}
}, 1000);
}
}
Will the listener receive the callback when the Activity itself has died?
-> No, it won't. Because when your activity dies, the _prefs and _sharedPreferenceListener fields will be destroyed.
You could check this question for more details on OnSharedPreferenceChangeListener :
SharedPreferences.onSharedPreferenceChangeListener not being called consistently
You must un-register the listener in onDestroy() of activity, else Activity object will stay in memory.

Call fragment from another fragment after some delay

I searched all over the web, couldn't find a good reference on how to call fragment from another fragment.
Fragment A -> Fragment B (fragment A calls fragment B after 3 seconds)
Well, first of all you need to consider that it's a very bad idea to keep somehow a direct reference from FragmentA to FragmentB. Why:
FragmentB may be recreated and you may keep a reference to an older reference of FragmentB. So you have a memory leak.
FragmentB may be not created, added or visible. So you would have a null/unusable reference.
For this reason you need to consider methods that base on sending messages from FragmentA to FragmentB. I see several options:
Send a broadcast message using a custom action from FragmentA. FragmentB registers itself as a receiver for this kind of message (in onCreate/onResume/onAttach and de-register in onDestroy/onPause/onDetach) and when the message arrives it can handle it. This is very suitable if you have no data to send from FragmentA to FragmentB or if you do these are primitive types or easy-to-implement Parcelables. Here's an example:
Have this in FragmentA:
private void sendMessageToFragmentB(String someData) {
Intent messageIntent = new Intent("com.your_package.A_TO_B_ACTION");
messageIntent.putExtra("DATA_VALUE", someData);
LocalBroadcastManager.getInstance(getActivity()).sendBroadcast(messageIntent);
}
While in FragmentB you could have this:
public class FragmentB extends Fragment {
private BroadcastReceiver messagesFromAReceiver = new BroadcastReceiver() {
#Override
public void onReceive(Context context, Intent intent) {
if ("com.your_package.A_TO_B_ACTION".equals(intent.getAction())) {
String dataFromA = intent.getStringExtra("DATA_VALUE");
dataFromAReceived(dataFromA);
}
}
};
protected void dataFromAReceived(String data) {
// here you have the data
}
#Override
public void onActivityCreated(Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
IntentFilter messageFromAIntentFilter = new IntentFilter("com.your_package.A_TO_B_ACTION");
LocalBroadcastManager.getInstance(getActivity()).registerReceiver(messagesFromAReceiver,
messageFromAIntentFilter);
}
#Override
public void onDestroy() {
super.onDestroy();
LocalBroadcastManager.getInstance(getActivity()).unregisterReceiver(messagesFromAReceiver);
}
}
Use the hosting activity as a proxy: The host activity implements some kind of interface defined in FragmentA and when requested it can search if it can find FragmentB and if so call some method in there. The advantage is that you can send any data, no matter its weight. The base idea is descrived in Android dev articles. To exemplify, you could have FragmentA as:
public class FragmentA extends Fragment {
public static interface CallerProxy {
public void sendCustomMessage(Object... dataParams);
}
private CallerProxy proxyActivity;
#Override
public void onAttach(Activity activity) {
super.onAttach(activity);
if (activity instanceof CallerProxy) {
this.proxyActivity = (CallerProxy) activity;
}
}
#Override
public void onDetach() {
super.onDetach();
this.proxyActivity = null;
}
private void sendMessageToFragmentB(String someData) {
if (proxyActivity != null) {
// send whatever data
proxyActivity.sendCustomMessage(new Integer(1), new Object());
// or don't send anything ...
proxyActivity.sendCustomMessage();
}
}
}
The proxy activity would have at least these methods and signature:
public class MyProxyActivity extends FragmentActivity implements CallerProxy {
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// call setContentView and then make sure you've added FragmentA and
// FragmentB.
}
#Override
public void sendCustomMessage(Object... dataParams) {
// FragmentB must be identified somehow, either by tag,
// either by id. Suppose you'll identify by tag. This means you've added
// it previously with this tag
Fragment fragment = getSupportFragmentManager().findFragmentByTag("FragmentB-TAG");
if (fragment != null) {
FragmentB fragB = (FragmentB) fragment;
fragB.dataFromAReceived(dataParams);
}
}
}
While in FragmentB all you need is a method that can be called with above sent parameters:
public void dataFromAReceived(Object ... data) {
// here you have the data
}
Use or implement some sort of event bus. Some general details here. For Android I remember that Otto event bus was very handy and easy to use. Here's a link with this. This is very similar to first option as you need anyway to register and un-register.
In the end it depends on what you need to send as a message, when should it be received and how flexible does it need to be. ... your choice!
Enjoy programming!
Fragments are not supposed to connect to each other directly, that may be your problem in finding a decent guide to do this.
Your approach makes the assumption that a fragment B will always be reachable (and ready) for a fragment A to interact, and that is actually not true, will kill the flexibility of your Fragment and will cause you problems in the future.
A better approach to interaction of Fragments is to talk only through interfaces that talk directly to a activity that can handle who is alive when where and should receive what.
-> http://developer.android.com/training/basics/fragments/index.html
This Android guide above, specifically on the last topic, shows you how to do this.
i hope this code help you..
in your first fragment add this code
onCreateView
LocalBroadcastManager broadcastManager = LocalBroadcastManager.getInstance(getActivity());
IntentFilter intentFilter = new IntentFilter("update");
// Here you can add additional actions which then would be received by the BroadcastReceiver
broadcastManager.registerReceiver(receiver, intentFilter);
#Override
public void onDestroyView() {
LocalBroadcastManager.getInstance(getActivity()).unregisterReceiver(receiver);
super.onDestroyView();
}
private BroadcastReceiver receiver = new BroadcastReceiver() {
#Override
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
if (action != null && action.equals("update")) {
// perform your update
getOngoingOrderData();
}
}
};
in your second fragment add this code where you send broadcast..
Intent intent = new Intent("update");
LocalBroadcastManager broadcastManager = LocalBroadcastManager.getInstance(getActivity());
broadcastManager.sendBroadcast(intent);

How to force main Acivity to wait for subactivity in Android?

I am calling a subactivity from main activity. This subactivity should take few numbers from user (i'm using Edit text control to achieve this), save them to static variable in another class and terminate. I want main activity to wait for subactivity but both are just running simultaneously. Even doing sth like that doesn't help:
Thread t = new Thread(new Runnable(){
public void run(){
Log.v("==================", "run "+new Date());
startActivityForResult(new Intent(ctx,myCustomSubactivity.class),1);
} });
Log.v("==================", "calling run "+new Date());
t.start();
try {
t.join();
} catch (InterruptedException e) {Log.v("==================", "can't join");}
Log.v("==================", "back from activity "+new Date());
do you know how to force main activity to wait? Thread.wait() method is not supported in Android(program throws error).
May be I'm missing something but why don't just use startActivityForResult and onActivityResult mechanism? You could get result from you subactivity from intent it was resulted with.
Edit: BTW as far as I understand, if you will run Object.wait() from Activity code if will hold UI tread whitch can result in Application not responding error.
I agree with Nikolay this is definitely the android way to do this.
Start the subactivity with startActivityForResult in the sub activity use setResult to add an result code and an intent with all the numbers you need in the data bundle.
In your first activity overwrite onActivityResult and retrieve the numbers from the Intent.
If you use the static variable this seems easier in the first moment but it is very insecure and there are some cases this may not work. If your program is send to the background your activities will be saved but if the phone runs low on memory the system will close your program and after the user resumes it everything looks like the moment the user left it but the static variables will be recreated to their initialization value.
Try to get used to the way the android activity lifecycle works. Using this approach will result in fewer used memory and a much better user experience.
Check out the Notepad example, it covers exactly this situation. And as others have said, the Android way is to have your first activity start up your second activity (not sub-activity!) and asynchronously listen for a response (not pause or wait, no need for joining, etc.).
Well... you can do it like this (btw, there's not straight forward way):
Have a singleton class, let's call it Monitor:
public class Singleton
{
private Singleton() { }
private static Singleton instance = new Singleton();
public static Singleton getInstance() {
return instance;
}
}
public class ParentActivity extends Activity
{
private void startAndWait()
{
Intent i = new Intent();
// initialize i
startActivityForResult(i);
Singleton si = Singleton.getInstance();
synchronized(si)
{
si.wait();
}
//do remaining work
}
}
public class ChildActivity extends Activity
{
protected void onCreate(Bundle savedInstance)
{
//do all the work
Singleton si = Singleton.getInstance();
synchronized(si)
{
si.notify();
}
}
}
I'm not here to judge if it's a good pattern or not but if you really need an activity to wait for a sub-activity, you can try this approach:
define an object (lock) over which the two activities get synchronized; this can (should) also work as the object to exchange data between those two activities and thus should be defined as static
in parent activity, start an async task (as the UI main thread cannot be in waiting state)
in the async task, start your sub-activity
the async task waits on the lock till it gets notified
the sub-activity does whatever it needs and notifies the waiting thread when it finishes
I did a similar thing in my app and IMHO had a good reason for this (not to bother a user with login screen upon app start or resume, the app tries to re-use credentials stored in a secured place and only in case it fails, it shows this login screen. So yes, basically any activity in my app can get "paused" and waits till the user provides correct credentials in the login activity upon which the login screen finishes and the app continues exactly where it got paused (in the parent activity).
In the code it would be something like this:
ParentActivity:
public class ParentActivity extends Activity {
private static final String TAG = ParentActivity.class.getSimpleName();
public static class Lock {
private boolean condition;
public boolean conditionMet() {
return condition;
}
public void setCondition(boolean condition) {
this.condition = condition;
}
}
public static final Lock LOCK = new Lock();
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.parent_layout);
// do whatever logic you need and anytime you need to stat sub-activity
new ParentAsyncTask().execute(false);
}
private class ParentAsyncTask extends AsyncTask<Boolean, Void, Boolean> {
#Override
protected Boolean doInBackground(Boolean... params) {
// do what you need and if you decide to stop this activity and wait for the sub-activity, do this
Intent i = new Intent(ParentActivity.this, ChildActivity.class);
startActivity(i);
synchronized (LOCK) {
while (!LOCK.conditionMet()) {
try {
LOCK.wait();
} catch (InterruptedException e) {
Log.e(TAG, "Exception when waiting for condition", e);
return false;
}
}
}
return true;
}
}
}
ChildActivity:
public class ChildActivity extends Activity {
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.child_layout);
// do whatever you need in child activity, but once you want to finish, do this and continue in parent activity
synchronized (ParentActivity.LOCK) {
ParentActivity.LOCK.setCondition(true);
ParentActivity.LOCK.notifyAll();
}
finish();
// if you need the stuff to run in background, use AsyncTask again, just please note that you need to
// start the async task using executeOnExecutor method as you need more executors (one is already occupied), like this:
// new ChildAsyncTask().executeOnExecutor(ChildAsyncTask.THREAD_POOL_EXECUTOR, false);
}
}

Categories

Resources