You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
getCurrentActivitySafe() has to be called instead getCurrentActivity() because checkCondition can run outside of the UI thread, causing an error.
My suggestion is to make getCurrentActivitySafe() an utility function, or to rename it to getCurrentActivity() and make it a method of Instruction.
Another alternative is to make checkCondition a method that receives the current activity as an argument, like this checkCondition(Activity currentActivity)
Hello :)
Thank you for enjoying simple thing as ConditionWatcher. Your proposition about retrieving Activity in test thread is interesting. It's simply waiting for ActivityLifecycleMonitor to return non-null instance.
You said that you don't get how I am doing it. Well my solution is to write your own runner and extend Application object used by your app under test.
public class MyAppTestRunner extends AndroidJUnitRunner {
@Override
public Application newApplication(ClassLoader cl, String className, Context context)
throws InstantiationException, IllegalAccessException, ClassNotFoundException {
return super.newApplication(cl, MyAppTestApplication.class.getName(), context);
}
}
So now my app will use MyAppTestApplication instead of MyAppApplication. And in MyAppTestApplication I use interface of ActivityLifecycleCallbacks. Whenever any Activity will call onResume the callback will trigger and save new reference to Activity. I can get access to it anytime.
public class MyAppTestApplication extends MyAppApplication implements Application.ActivityLifecycleCallbacks {
private Activity currentActivity;
@Override
public void onCreate() {
super.onCreate();
registerActivityLifecycleCallbacks(this);
}
@Override
public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
}
@Override
public void onActivityStarted(Activity activity) {
}
@Override
public void onActivityResumed(Activity activity) {
currentActivity = activity;
}
@Override
public void onActivityPaused(Activity activity) {
}
@Override
public void onActivityStopped(Activity activity) {
}
@Override
public void onActivitySaveInstanceState(Activity activity, Bundle outState) {
}
@Override
public void onActivityDestroyed(Activity activity) {
}
public Activity getCurrentActivity() {
return currentActivity;
}
public static MyAppTestApplication getInstance(){
return ((MyAppTestApplication)(InstrumentationRegistry.getTargetContext().getApplicationContext()));
}
}
And with that you can do static imports of MyAppTestApplication.getInstance().getCurrentActivity() which will allow you to simply call getCurrentActivity() wherever you want. I agree with the fact that it can be null - but since last year I never had problem with this as I am aware of it and I simply use null checks :) Well. I think I like your idea - it is a little bit more complicated but takes care of your null checks. I would like to run it with my code for a while and see if there are no any problems/side effects.
What do you think about memory leak threat in both cases?
Didn't know about that solution, so thanks for the share ;) you should put it in the docs! :)
Between the two solutions I don't know which one is more is more reliable, I would have to go deeper into it to find out. The one you proposed is a bit too verbose, though.
Nonetheless, I don't mind so much which solution gets picked, what I do think is important is to make it easy for the user to get the current activity. So whatever solution we go with, it should be wrapped in a function and exposed as an utility function (or passed as an argument, if it's commonly used).
Memory leaks wise it looks to me that both solution are the same, the getCurrentActivitySafe might be a bit safer, since it holds no references.
Activity
FisherKK commentedon Mar 6, 2017
Hello :)
Thank you for enjoying simple thing as ConditionWatcher. Your proposition about retrieving Activity in test thread is interesting. It's simply waiting for ActivityLifecycleMonitor to return non-null instance.
You said that you don't get how I am doing it. Well my solution is to write your own runner and extend Application object used by your app under test.
So now my app will use
MyAppTestApplicationinstead ofMyAppApplication. And inMyAppTestApplicationI use interface ofActivityLifecycleCallbacks. Whenever any Activity will call onResume the callback will trigger and save new reference to Activity. I can get access to it anytime.And with that you can do static imports of
MyAppTestApplication.getInstance().getCurrentActivity()which will allow you to simply callgetCurrentActivity()wherever you want. I agree with the fact that it can be null - but since last year I never had problem with this as I am aware of it and I simply use null checks :) Well. I think I like your idea - it is a little bit more complicated but takes care of your null checks. I would like to run it with my code for a while and see if there are no any problems/side effects.What do you think about memory leak threat in both cases?
rfreitas commentedon Mar 6, 2017
Didn't know about that solution, so thanks for the share ;) you should put it in the docs! :)
Between the two solutions I don't know which one is more is more reliable, I would have to go deeper into it to find out. The one you proposed is a bit too verbose, though.
Nonetheless, I don't mind so much which solution gets picked, what I do think is important is to make it easy for the user to get the current activity. So whatever solution we go with, it should be wrapped in a function and exposed as an utility function (or passed as an argument, if it's commonly used).
Memory leaks wise it looks to me that both solution are the same, the
getCurrentActivitySafemight be a bit safer, since it holds no references.FisherKK commentedon Mar 9, 2017
Did your solution work for you?
For me it doesn't seems to block anything and I receive massive amount of null pointers from getCurrentActivity() in Instructions.
rfreitas commentedon Apr 8, 2017
It did, but I made a slight alteration.