Develop Reference

Is it possible to stop idling for an AsyncTask to complete?

I am trying to set up a test for my project - to test that a progress bar is displayed when my app performs a server request.
The code under test uses an AsyncTask to perform the network call.
I have created a blocking server (MockWebServer) to catch and hold the network call - it receives request but doesn't provide a response until i call ".release()". This allows me to verify before the server response occurs.
My logic flows like this:
// Mock server will catch the next network request
BlockingServer blockingServer = createBlockingServer();
// onResume() activity performs network request and shows Progress Spinner
activityTestRule.launchActivity(null);
// onView() waits on UiController.loopUntilIdle() <- Fails here due to timeout.
onView(withId(progressBar)).check(matches(isDisplayed()));
// Tells the server to respond to the network request
blockingServer.release();
onView(withId(progressBar)).check(matches(not(isDisplayed())));
My problem is that because the Code Under Test uses AsyncTask for the server request, Espresso naturally blocks on the verify call (onView()) in order to wait for the AsyncTask to complete before verifying.
What I need is to temporarily stop Espresso idling while waiting for AsyncTask in order to perform the verify while the server is blocking the app logic flow.
(Changing the Code Under Test is not an option)
Can someone help?

So... this is the answer I've arrived at and some working out behind it:
Espresso (specifically calls to onView(), onData(), injectEvent and Actions) uses UiControllerImpl.loopMainThreadUntilIdle() to wait until all "idle-causing" signals are false. It loops over AsyncTask, CompatAsyncTask and something called dynamicIdle to all be idle.
When this method returns the main flow continues.
loopMainThreadUtilIdle() checks an IdleNotifier to check the idle state of each of those three elements. Obviously if you want to stop espresso waiting for AsyncTask the asyncIdle is of particular interest to you.
The IdleNotifier classes are fed into UiControllerImpl at it's construction - this takes place via dagger so you'll need to look at DaggerBaseLayerComponent which uses Providers to grab the construction arguments and pass them into the UiControllerProvider to construct it.
Everything in all of these classes is locked down very tightly. Method and class visibility is usually protected or package-private and final.
The only way I found was to create my own Espresso.java class (onView() and onData()) which used custom DaggerBaseLayerComponent allowing me to use either: My own Providers or My own UiController.
I found however this doesn't solve the whole problem. There is one more mechanism that needs to be coded around - When you're starting activities they use a waitForIdleSync in the Instrumentation class. Usually this is the Runner which is provided in your gradle file. I created my own AndroidJUnitRunner and provided this in gradle to allow me to return from waitForIdleSync on command.
And finally, in startActivitySync in the Instrumentation base class, it uses an array of ActivityWaiter objects to hold up your launchIntent() calls. I couldn't think of a reasonable way of avoiding this so I cheated and created this method in my Runner:
public void clearActivityWaitQueue() {
Object mSync = Whitebox.getInternalState(this, "mSync");
List mWaitingActivities = Whitebox.getInternalState(this, "mWaitingActivities");
if (mSync != null && mWaitingActivities != null) {
mWaitingActivities.clear();
synchronized (mSync) {
mSync.notifyAll();
}
}
}
It uses PowerMock to give me the convenience Whitebox methods to set internal state of Instrumentation:
// Used to give access to Whitebox
androidTestImplementation 'org.powermock:powermock-reflect:1.6.5'
And that's it! Easy right?
(Please tell me it's easier than this and how!!)

AsyncTaskLoader: deliverResult does not trigger call back to onLoadFinished if data has not changed

I would like to clarify something about AsyncTaskLoader (and probably other loaders as well) that seems to be asked a lot but never answered. I have noticed that if I cache data in a Loader and try to avoid a reload of the data, a call to deliverResult will not trigger a callback to onLoadFinished, if the data passed has not change since the last time the loader provided the data. This means that even though the Loader has a copy of the data, it does not provide it to the listener (the Activity). This is clearly the case as show here in the LoaderInfo code:
if (mData != data || !mHaveData) {
mData = data;
mHaveData = true;
if (mStarted) {
callOnLoadFinished(loader, data);
}
}
I think this is a really important to realize. Many tutorials online indicate that one should cache data in the loader as an instance variable then check if it has been set in onStartLoad and set it in deliverResult. Example:
...
String[] mWeatherData = null;
#Override
protected void onStartLoading() {
if (mWeatherData != null) {
deliverResult(mWeatherData);
} else {
mLoadingIndicator.setVisibility(View.VISIBLE);
forceLoad();
}
}
....
public void deliverResult(String[] data) {
mWeatherData = data;
super.deliverResult(data);
}
The expectation here is that the call to deliverResults in onStartLoading will deliver the data via the onFinishedLoading call back and avoid a call to loadInBackground when the loader already has the data cached. However as show above this will not occur if the data has not changed and the Loader has already run. This seems contrary to the point of Loaders.
If your Activity maintains data in a field that is not persisted by Android during a configuration change (such as a TextView) you would expect the Loader to provide that data via the callback after the config change. There is no way to get the cached data from the LoaderInfo object so it remains up to the app to save the data itself, which I though was one of the important responsibilities of the Loader. The fact that the LoaderManager does cache its own copy of data via the LoaderInfo makes this all the more bizarre to me.
Some people have proposed using restartLoader instead of initLoader as a solution but this also defeats the purpose of the caching the data (both in your implementation of the Loader and via the LoaderManager). The only correct solution I have come up with is to pass a reference of the activity to the Loader and use the deliverResults method to pass the data in the Activity. To avoid memory leaks this means maintaining a weak reference to the activity bla bla bla. Even that does not answer the question: why does the LoaderManager maintain a cached copy of the data but not provide any way for the app to get it when it needs it (after config change or the like)?
Is there possibly another lifecycle event that causes the LoaderManager to callback to the listener with the cached data?

Why should one consider using AndroidObservables in RxJava

As i understand AndroidObservable helps ensure that :
a Subscriber always observes on the main thread
when a fragment/activity is detached/stopped, then the observation stops immediately, and framework related components (like ui textviews etc.) are not updated.
However, in order to ensure that the context is released (preventing leakage), most examples I see typically say that you have to anyway do an .unsubscribe onDestroyView/onDestroy, which essentially halts the subscription, and prevents the subscriber from receiving these updates anyway.
So my question is:
Is there any other advantage to using AndroidObservables, if i manually indicate that the subscription should happen on the main thread, by way of .observeOn(AndroidSchedulers.mainThread() ?
Is there any difference in the below two approaches?
_subscription1 = AndroidObservable.bindFragment(MyFragment.this, myCustomAwesomeObservable()) //
.subscribeOn(Schedulers.io()) //
.subscribe(...);
_subscription2 = myCustomAwesomeObservable()
.subscribeOn(Schedulers.io()) //
.observeOn(AndroidSchedulers.mainThread()) //
.subscribe(...);
#Override
public void onDestroyView() {
_subscription1.unsubscribe();
_subscription2.unsubscribe();
super.onDestroyView();
}

You are right. What AndroidObservable.bindFragment currently does is:
This helper will schedule the given sequence to be observed on the main UI thread and ensure that no notifications will be forwarded to the activity in case it is scheduled to finish.
-- part of the source code comment
So, it does not really make a difference which of the implementations you use.
But, still it's a good idea to use the AndroidObservable as additional functionality could be added in the future.

It doesn't exist anymore since 1.0 release of RxAndroid. I guess you could say it's deprecated or discontinued. I don't think it's a good idea to use this anymore.

Using AsyncTask to update UI

I have problem when implementing AsyncTask. I have to rotate my phone in order to get a recent information. Below is my class:
GamerObject gamer;
….
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
ip = "134.188.204.155";
// Set the name of the gamer
gamername = (TextView) findViewById(R.id.gamer_name);
// Set the gamerstatus:
gamerstatus = (TextView) findViewById(R.id.tvgamer_status_msg);
// set the job status
jobstatus = (TextView) findViewById(R.id.tvJob_status_msg);
new Operation().execute();
}
private class Operation extends AsyncTask<Void, Void, Void> {
#Override
protected Void doInBackground(Void... params) {
gamer= new GamerObject(ip);
gamer.UpdateAllData();
}
#Override
protected void onPostExecute(Void result) {
updateUI();
}
}
private void updateUI() {
gamer.updateAllData();
// Set the name of the gamer
TextView gamername = (TextView) findViewById(R.id.gamer_name );
gamername.setText(gamer.gamername);
gamername = gamer.gamername ;
// Set the gamer status:
…
// set the job status
…
}
Before I was using a Intent for Refresh the Interface, but now I want to try using AsyncTask so that it can compatible with Android version 4. Anybody knows how to get the information updated without rotating the phone ?
EDIT:
If I'm not wrong, Why my UI didn't refresh if there is new value, it is because new Operation().execute(); only use once in onCreate. AsyncTask will be executed if onCreate has been called, which means every time I rotate my phone, it will go to onCreate . Anybody knows how to keep the AsyncTask executed?

AsyncTask will only be executed once, so whenever system calls onCreate on your activity dueto some lifecycle event, asyncTask will be executed.
One, simple but naive approach, would be to create a new Thread and use Handler to update your UI. Some more information can be found eg. here and of course in Android doc.
Better approach, but more complicated would be to use Loader and LoaderCallback along with ContentProvider as #metter mentioned. This will require implementing you own ContentProvider and force you to add more "abstraction layers" to your app but will allow to separate network base code and ui code.
So this is as always tough decision to make either use "simple" but ugle solution with threads or "harder" but elegant solution with ContentProvier

I want to get the inofrmation updated automatically without have to rotating the phone.
Doing that requires some more work. Unfortunately, we can't see what your Async task actually does. If it is reading data from a database and you wan't your UI to be informed about any changes to the database, then your content resolver could call it's notifyChange and your Activity would listen to these changes and then call the async task again. For that, you would use a Content Observer. However, if your task is downloading data from the web, then there are two methods to get informed if the data online changed. One is called polling and means that you periodically connect and check the server. You should never do that on a mobile device due to limitations in battery, performance and data traffic. The other is called pushing and requires you to set up some infrastructure.
I hope that helps you.

How can I start two asynchronous threads which join to common execution once both are complete?

I'm looking for a design pattern or approach for the following scenario. I wish to kick off two separate background threads for data retrieval from different sources. I then want one method (on the UI thread) to be called once both background threads have completed their work. As the data from the two sources must be combined to be useful, I must wait until both have finished retrieving before manipulating the data. How can I achieve this on the Android platform?

Edit: My first version has been bothering me, and I didn't like the necessary added boolean with it, so here's another version. Call it with this from onPostExecute of each added task.
ArrayList<AsyncTask> tasks;
public void doStuffWhenDone(AsyncTask finishedTask)
{
tasks.remove(finishedTask);
if(tasks.size() > 0)
return;
... do stuff
}
I'll keep the older one up also, since they both work, but I think the above is much cleaner. Now to go tidy up one of my earlier projects.
ArrayList<AsyncTask> tasks;
boolean hasBeenDone = false;
public void doStuffWhenDone()
{
for(int i=0;i<tasks.size();i++)
if(hasBeenDone || (tasks.get(i).getStatus() != AsyncTask.Status.FINISHED))
return;
hasBeenDone = true;
... do stuff
}
It's easily extendable to however many tasks you have, and there's no need for a thread to handle the threads. Just call the method at the end of each task. If it's not the last one done, nothing happens.
Edit: Good point, but I don't think it needs to be atomic. Since both AsyncTasks' onPostExecute methods run on the UI thread, they'll be called one after the other.

Use a CountDownLatch, like this:
CountDownLatch barrier = new CountDownLatch(2); // init with count=2
startWorkerThread1(barrier);
startWorkerThread2(barrier);
barrier.await(); // it will wait here until the count is zero
doStuffWithTheResult();
when a worker thread finishes, call barrier.countDown() from it.

You can use AsyncTask and an int to know if both jobs are finished...