Status Update
Comments
ab...@gmail.com <ab...@gmail.com> #2
This actually has nothing to do with NavHostFragment, but is the behavior of NavController's setGraph().
When you call navController.setGraph(R.navigation.navigation_graph), it stores that ID and will restore that ID automatically.
If you were to instead use:
NavInflater navInflater = new NavInflater(this, navController.getNavigatorProvider());
navController.setGraph(navInflater.inflate(R.navigation.navigation_graph));
Then NavController would not restore the graph itself and the call to restoreState() you point out would only restore the back stack state, etc. but would wait for you to call setGraph again.
You're right that the inconsistency between the two setGraph methods is concerning. We'll take a look.
When you call navController.setGraph(R.navigation.navigation_graph), it stores that ID and will restore that ID automatically.
If you were to instead use:
NavInflater navInflater = new NavInflater(this, navController.getNavigatorProvider());
navController.setGraph(navInflater.inflate(R.navigation.navigation_graph));
Then NavController would not restore the graph itself and the call to restoreState() you point out would only restore the back stack state, etc. but would wait for you to call setGraph again.
You're right that the inconsistency between the two setGraph methods is concerning. We'll take a look.
pa...@gmail.com <pa...@gmail.com> #3
Turns out, we already had a tracking bug for this issue, will follow up on that other one.
bu...@gmail.com <bu...@gmail.com> #4
Thank you for promptly replying to my report. You are right that the issue you've just mentioned is similar to mine. I shall continue observing the progress over there.
p....@blueesoteric.com <p....@blueesoteric.com> #5
Confirming this error for rules-0.5 as well. The workaround in #1 is functional, so thanks for that. But as expected, it adds much more time to these tests. Would love an update to fix this! Thanks
ma...@telepon.com.br <ma...@telepon.com.br> #6
I ran with Parameterized class and got the following results:
with rules-0.4 - 7/10 tests failed
with rules-0.5 - 5/10 tests failed
Workaround on #1 returned no failed tests.
with rules-0.4 - 7/10 tests failed
with rules-0.5 - 5/10 tests failed
Workaround on #1 returned no failed tests.
bs...@salesforce.com <bs...@salesforce.com> #7
Thanks for this bug report, I also spent a ton of time trying to figure this out.
For a workaround, I copied ServiceTestRule source and reset the problematic CountDownLatch in ServiceTestRule#shutdownService.
For a workaround, I copied ServiceTestRule source and reset the problematic CountDownLatch in ServiceTestRule#shutdownService.
Description
Version used: 0.3
Class in question: android.support.test.rule.ServiceTestRule
There appears to be a bug in ServiceTestRule.ProxyServiceConnection that introduces a race condition that causes ServiceTestRule.bindService() to sometimes (for me, often) return null after the first invocation.
The problem is that ServiceTestRule.ProxyServiceConnection defines the following static variable:
public static CountDownLatch mConnectedLatch = new CountDownLatch(1);
This latch is decremented by one in onServiceConnected(), causing ServiceTestRule.bindService() to unblock and return the Binder. However, since mConnectedLatch is declared as *static* its value is already zero the next time that ServiceTestRule.bindService() is invoked; this causes ServiceTestRule.bindService() to not wait at all for onServiceConnected() to be invoked and therefore often returns *before* it is invoked, in which case the Binder is null.
A possible fix might be to remove the "static" modifier from ServiceTestRule.ProxyServiceConnection.CountDownLatch
Here is a sample test that will expose the issue:
@RunWith(AndroidJUnit4.class)
public class TestBoundService {
@Rule
public final ServiceTestRule mServiceTestRule = new ServiceTestRule();
@Test
public void test1() throws Exception {
assertBindServiceReturnsNonNull();
}
@Test
public void test2() throws Exception {
assertBindServiceReturnsNonNull();
}
private void assertBindServiceReturnsNonNull() throws Exception {
final Context context = InstrumentationRegistry.getTargetContext();
final Intent intent = new Intent(context, SomeService.class);
final IBinder binder = mServiceTestRule.bindService(intent);
assertNotNull(binder); // <-- this assertion will fail when the 2nd test is run
}
}
For now, as a workaround, I am binding to my service explicitly and not using ServiceTestRule, as I need to repeatedly bind to and unbind from my service in various tests in my test suite.