this is my current code
public class ButtonActivity extends Activity {
int count = 0;
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
final Button button = (Button) findViewById(R.id.button);
button.setOnClickListener(new OnClickListener() {
#Override
public void onClick(View v) {
button.setText("Got Pressed:" + ++count);
}
});
}
}
My question why after each call of onDestroy() and the subsequent call of onCreate(), the count gets reset. I looked up on onDestroy() and saw "that is there to let your app have a final chance to clean things up before the activity does get destroyed but it does not mean that the activity will be called" My initial idea was that count is an instance variable and that onCreate() creates a new instance of my class ButtonActivity. Can anyone confirm or refute my intial thoughts ?
If you don't want it reset - make it static: currently the counter is per object
Making count static will solve your problem. (because static member don't belong to a particular instance)
But to be more precise : onCreate don't create a new instance of your activity. In fact : Android-OS create a new instance and give you a chance to initialize it by calling onCreate(...).
And, more generally : you can be sure that onCreate() will never be called twice on the same instance: if you see that onCreate() is called it's because Android-OS has just created a new instance of your Activity (it can be done for many reason, like screen rotation, ...).
More about activity lifecycle here (probably one of the most important concept to understand when you do Android development !)
Storing static data in your activity class, as was suggested here, is a bad practice
and should be avoided.
Why?
Because Android may destroy background activities TOGETHER with their static data
whenever it feels resources are running low. Thus you may declare static fields inside you activity, but you will not get the static behavior you aim for,
What can you do instead:
Option 1:
Create a custom Application class and place your static data there. You will
not even have to declare it as static since Application obj is a singleton and is
guaranteed to stay in memory for as long the the app is alive.
public class MyApplication extends Application {
private DataClass mydata;
// probably with a getter & setter
}
Remember to declare your activity in the manifest:
<application
android:name="mypackage.MyApplication" <--------
.....
Option 2: Serialize your data to shared preferences. This is what they are for.
Related
I am trying to read a list of integers inside of the doInBackground of AsyncTask. When I pass the list into the constructor of AsyncTask, it is full. But, by the time I get to the doInBackground function, it is empty. Any ideas?
public class floatingActionButtonClickListener implements View.OnClickListener{
#Override
public void onClick(View v) {
if(mAdapter.getDeleteModeStatus()){
// Delete items from database
ArrayList<Integer> IDsToDelete = mAdapter.getJournalIDsToDelete();
new DeleteDatabase().execute(IDsToDelete);
// Turn FAB back to regular button
mFAB.setImageResource(R.drawable.baseline_add_white_48); // Turn FAB to delete button
// Disable delete mode
mAdapter.exitDeleteMode();
// Load database
new LoadDatabase().execute();
}
else{
Intent intent = new Intent(getBaseContext(), AcitivtyJournal.class);
int journalType = Constants.JOURNALTYPE_FULL;
intent.putExtra(Constants.JOURNAL_TYPE, journalType);
startActivity(intent);
}
}
}
private class DeleteDatabase extends AsyncTask <ArrayList<Integer>, Void, Void> {
#Override
protected void onPreExecute() {
super.onPreExecute();
mProgressBarHolder.setVisibility(View.VISIBLE);
}
#Override
protected Void doInBackground(ArrayList<Integer>... arrayLists) {
ArrayList<Integer> IDsToDelete = arrayLists[0];
AppDatabase db = Room.databaseBuilder(getApplicationContext(), AppDatabase.class, "JournalEntries")
.build();
for(Integer idToDelete : IDsToDelete){
db.mJournalEntriesDao().deleteCompleteJournalEntry(idToDelete);
}
return null;
}
#Override
protected void onPostExecute(Void aVoid) {
mProgressBarHolder.setVisibility(View.GONE);
}
}
}
This is not how you use and AsyncTask. You need to declare the parameters and then recieve them in the callback.
Please also note that you are trying to access the same data(IDsToDelete) from two threads(Main and Background), in your way, without proper syncronization.
private class DeleteDatabase extends AsyncTask<ArrayList<Integer>, Void, Void> {
#Override
protected Void doInBackground(ArrayList<Integer>... arrayLists) {
ArrayList<Integer> params = arrayLists[0];
// Do what you need
}
}
ArrayList<Integer> IDsToDelete = mAdapter.getJournalIDsToDelete();
new DeleteDatabase().execute(IDsToDelete);
When you have multithreading you need to look for two things:
atomic execution of operations
memory visibility.
There is a shared memory and every CPU caches the data. When you create something from one thread you can't just expect that the second thread will just read it. In your case you are creating the AsyncTask and inject the params from one thread, but then you read them in doInBackground from another. In general when you go through a synchronized block or hit a volatile variable(I say in general, because I also don't fully understand how JVM works), the thread flushes it's cache to the main memory and then reads also from it. This is how the data is shared. That is why it is better to use the framework way, because the frame will take care of proper publication of your data between threads. You are ok with immutable data, but a List is not such thing. And even if you declare the reference as immutable, you might see the right object from both threads, but the data they are holding might be old.
Just to be clear. I am not saying that the previous way was not working. I am saying that it is on good will. You can't just share data betweeb threads and hope it works.
Figured it out. Posting for people in the future who may have similar questions.
Embarrasingly enough, the ArrayList<Integer> was coming empty because I was deleting it in the function mAdapter.exitDeleteMode(); after I call AsyncTask().execute().
I was not aware that when I send the list to the AsyncTask it was the exact address of the list and not just a new list (that is, until I posted the comment above, and then it clicked). I think I got that train of thinking from C++ or another language. I don't remember which.
Solution: The solution I came up with is to just move mAdapter.exitDeleteMode() into of onPostExecute()instead of having it in the onClick() method.
Another Potential Solution: I believe another solution that would work (but I did not test) would be to just insert a new ArrayList<Integer> () into the AsyncTask
I need to show an Activity each time a user is inactive for X amount of time. I am trying to achieve that with a custom CountDownTimer, which starts onUserInteraction in my BaseActivity:
#Override
public void onUserInteraction() {
super.onUserInteraction();
inactivityTimer.cancel();
inactivityTimer.start();
}
In my custom CountDownTimer, I start the desired Activity onFinish:
#Override
public void onFinish() {
BaseActivity baseActivity = new BaseActivity();
Log.i("TIMER ENDED: ", "NOW STARTING LOCKACTIVITY");
baseActivity.showLock();
}
And this is my showLock() method in BaseActivity
public void showLock() {
Intent intent = new Intent(getApplicationContext(), LockActivity.class);
startActivity(intent);
}
What I'm getting is a NPE every time the timer ends. (java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String android.content.Context.getPackageName()' on a null object reference) even though I tried using getApplication().getBaseContext(), this, this.getBaseContext(), this.getApplicationContext(), getApplicationContext()and
getBaseContext() instead of getApplicationContext()
However, if I set the Context in the method call like this:
#Override
public void onFinish() {
BaseActivity baseActivity = new BaseActivity();
Context context = MyApplication.getInstance().getApplicationContext();
Log.i("TIMER ENDED: ", "NOW STARTING LOCKACTIVITY");
baseActivity.showLock(context);
}
And this in showLock():
public void showLock(Context context) {
Intent intent = new Intent(context, LockActivity.class);
startActivity(intent);
}
This time I get another NPE (java.lang.NullPointerException: Attempt to invoke virtual method 'android.app.ActivityThread$ApplicationThread android.app.ActivityThread.getApplicationThread()' on a null object reference).
So my question is, how do I get a proper Context every time my showLock() is called from the current Activity, which will be calling that method?
Important note: each and every Activity in my project inherits BaseActivity, which on its own inherits AppCompatActivity.
EDIT
I gave Marcin's suggestion a try and after dealing with a couple of errors I ended up using his approach. If someone else is curious and wants to know how to open an activity after X amount of inactivity this worked for me:
Since all my Activities inherit one main BaseActivity I put there a custom Handler, which holds a WeakReference to said BaseActivity. I also overrode handleMessage, where I call my desired method:
private static class InactivityHandler extends Handler {
private WeakReference<BaseActivity> baseActivityWeakReference;
private InactivityHandler(BaseActivity baseActivity) {
baseActivityWeakReference = new WeakReference<>(baseActivity);
}
#Override
public void handleMessage(Message msg) {
BaseActivity baseActivity = baseActivityWeakReference.get();
if (baseActivity != null) {
baseActivity.showLock();
}
}
}
and in onUserInteraction send a Message to the queue after some time:
#Override
public void onUserInteraction() {
super.onUserInteraction();
inactivityHandler.removeMessages(MESSAGE_WHAT, MESSAGE_TOKEN);
inactivityHandler.sendMessageDelayed(inactivityHandler.obtainMessage(MESSAGE_WHAT, MESSAGE_TOKEN), DELAY_TIME);
}
And for the curious, here is my showLock method:
public void showLock() {
Intent intent = new Intent(this, LockActivity.class);
startActivity(intent);
}
From you description I assume that after the user is inactive for some time your app needs to present a lock screen where the user needs to reenter their credentials.
Unless the whole scenario has any counting involved (for example you display an actual count down), a CountDownTimer may not be the best to perform this task.
Instead you could use a Handler. In Android, the Main Thread has it's associated message queue. Handlers are able to post messages to this queue to receive them later, at the given time.
Your example implementation could look like that:
private static class LockScreenHandler extends Handler {
private WeakReference<BaseActivity> activityRef;
public LockScreenHandler(BaseActivity activity) {
activityRef = new WeakReference<>(activity);
}
#Override public handleMessage(Message msg) {
BaseActivity activity = activityRef.get();
if (activity != null) {
activity.showLock();
} // Otherwise the activity got destroyed in the meantime
}
}
You may send either Runnables or Messages with the Handler. In our case a Message is perfectly fine. Therefore in your Base Activity you may have some Message-related fields:
private static final int MESSAGE_WHAT = 1;
private static final Object MESSAGE_TOKEN = new Object();
And then you use your handler in onUserInteraction:
#Override public void onUserInteraction() {
super.onUserInteraction();
handler.removeMessages(MESSAGE_WHAT, MESSAGE_TOKEN);
handler.postDelayed(handler.obtainMessage(MESSAGE_WHAT, MESSAGE_TOKEN), INACTIVITY_DELAY);
}
If you decide to follow your CountDownTimer solution you may follow the same technique, by creating a static inner class and giving your activity in the constructor.
Whichever way you go, it is important to note, that your BaseActivity can be destroyed by the system and improper usage of Handler (and CountDownTimer which internally relies on Handler) can prevent the reference to this activity from being destroyed and therefore lead to a memory leak. Therefore:
If you use a Handler or a CountDownTimer as an inner class, make sure it is static. Non-static inner classes hold a reference to their enclosing classes. Messages hold references to their target Handlers, so as long as the message is in the queue it's handler cannot get destroyed.
Use a WeakReference to hold your activity for the same reason as outlined above. WeakReferences are cleared if nothing else holds a reference to the given object.
An Activity is a Context itself. So just use this within an Activity.
public void showLock() {
Intent intent = new Intent(this, LockActivity.class);
startActivity(intent);
}
If this is not an option because you are overriding a function you should use MainActivity.this (when the MainActivity is the name of your activity)
MainActivity.this.startActivity(MainActivity.this, ...);
I would like to know if it's possible to clear all activities from an old one. I would like to use enventBus to do this.
Example of a stack of activities:
startActivity(A) then startActivity(B) then startActivity(C) then startActivity(D)...
Activity B is registered onEvent(ClearStackFromHere()) with eventBus.
And from Activity D I want to post the event post(new ClearStackFromHere) with eventBus too.
So, is it possible to clear the stack of activities from B ?
What should I write inside my ClearStackFromHere().
Thanks,
I have implemented a similar solution in one of my projects.
What I needed was a way to keep only the most recent 3 activities in the back stack, and clear the others before them. This only applies to a certain Navigation flow within my application where it becomes possible that an infinite amount of Activities can be added to the back stack.
e.g. A opens B - which opens C, C can then open another instance of A or B... etc.
I should note that this solution uses EventBus 2.4.0 and there may be a better way to implement it with 3.0+.
First off, I defined a helper called ActivityTracker. It keeps track of what Activities are currently active, as well as an identifier for each activity. It also has methods that can be called to finish all activities in the back stack except for the most recent n amount.
public class ActivityTracker {
private static ArrayList<String> activityStack = new ArrayList<>();
//Notify the Tracker of a new Activity to track
public static void activityActive(String uuid){
addToBackStack(uuid);
}
//Notify the tracker of an Activity that should no longer be tracked
public static void finishing(String uuid){
removeFromBackStack(uuid);
}
//Call this to clear entire back stack
public static void killAllBackStackActivities(){
killPreviousActivities(0);
}
//Call this to clear back stack while keeping most recent X amount
private static void killPreviousActivities(int keepAmount){
if(activityStack.size() <= keepAmount) {
return;
}
//Copy to not manipulate while looping.
String[] tempList = activityStack.toArray(new String[activityStack.size()]);
int counter = activityStack.size();
for(String id : tempList){
if(counter == keepAmount){
return;
}
counter--;
//Send notification to kill specific activity
EventBus.getDefault().post(new ActivityShouldDieEvent(id));
}
}
private static void addToBackStack(String uuid){
if(!activityStack.contains(uuid)){
activityStack.add(uuid);
killPreviousActivities(3); //Always kill all activities except most recent 3.
}
}
private static void removeFromBackStack(String uuid){
if(activityStack.contains(uuid))
activityStack.remove(uuid);
}
}
Then, I defined a subclass of AppCompatActivity called BackStackTrackActivity. All relevant Activities in the app extend this class. The subclass looks like this:
public class BackStackTrackActivity extends AppCompatActivity {
//Random ID for activity to be identified by
protected String uuid = UUID.randomUUID().toString();
//Receive notification that activity should finish
public void onEvent(ActivityShouldDieEvent ev){
if(ev.getUuid().equals(this.uuid)){
finish();
}
}
#Override
protected void onDestroy() {
super.onDestroy();
//Unregister from EventBus
EventBus.getDefault().unregister(this);
//Tell tracker to stop tracking
ActivityTracker.finishing(uuid);
}
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//Register for events
EventBus.getDefault().register(this);
//Tell tracker to track activity
ActivityTracker.activityActive(uuid);
}
}
With some work, I think you will be able to adapt this solution into something that meets your needs.
I hope that helps.
My MainActivity on my Android application checks if the user is logged in (this is stored in SharedPreferences) and if it's not takes the user to the LoginActivity. I am trying to test this using the following code
public class MainActivityTest extends ActivityInstrumentationTestCase2<MainActivity> {
private static final int TIME_OUT = 5000; /* miliseconds */
private MainActivity mMainActivity;
private Instrumentation mInstrumentation;
private SharedPreferences mLoginPrefs;
public MainActivityTest() {
super(MainActivity.class);
}
protected void setUp() throws Exception {
super.setUp();
setActivityInitialTouchMode(false);
mMainActivity = getActivity();
mInstrumentation = getInstrumentation();
mLoginPrefs = mInstrumentation.getTargetContext().getSharedPreferences(LoginActivity.PREFS_NAME, Context.MODE_PRIVATE);
SharedPreferences.Editor editor = mLoginPrefs.edit();
// User is not logged in, so it should be redirect to LoginActivity
editor.putBoolean("logged_in", false);
editor.commit();
}
//...
public void testC_OpenLoginActivityIfUserIsNotLoggedIn() {
ActivityMonitor monitor = mInstrumentation.addMonitor(LoginActivity.class.getName(), null, false);
Activity nextActivity = mInstrumentation.waitForMonitorWithTimeout(monitor, TIME_OUT);
assertNotNull(nextActivity);
nextActivity.finish();
SharedPreferences.Editor editor = mLoginPrefs.edit();
// Login the user so we can continue the tests
editor.putBoolean("logged_in", true);
editor.commit();
}
But this doesn't work, the LoginActivity opens but waitForMonitorWithTimeout never returns so I got stuck on LoginActivity (I need to get back to MainActivity to do the other tests).
A code similar to this SO Question works for Button clicks, but this Activity is not loaded by any click so I am thinking maybe there is no time to the monitor to work.
I just need a way to get the actual Activity so I can make an assert and make it finish to continue my tests.
Just one other thing: I would prefer a method without using Robotium if it's possible.
In order to solve your problem, first take a look at the two most important methods for your test:
Instrumentation#addMonitor(java.lang.String, android.app.Instrumentation.ActivityResult, boolean)
Instrumentation.ActivityMonitor#waitForActivity()
According to Android API reference:
addMonitor
Add a new Instrumentation.ActivityMonitor that will be checked whenever an activity is started. The monitor is added after any existing ones; the monitor will be hit only if none of the existing monitors can themselves handle the Intent.
waitForActivity
Block until an Activity is created that matches this monitor, returning the resulting activity.
Now let's make it a bit more clear.
addMonitor should be called always before the expected activity being started, never too late.
waitForActivity should be called only after the expected activity being started, never too early, since it will block.
Back to your code:
You're calling both of them together, without any magic happening in between. So it's either too late for addMonitor, or too early for waitForActivity.
ActivityMonitor monitor = mInstrumentation.addMonitor(LoginActivity.class.getName(), null, false);
Activity nextActivity = mInstrumentation.waitForMonitorWithTimeout(monitor, TIME_OUT);
If it's too early for calling waitForActivity, it will block and fail until the timeout (because the expected activity is not hit yet), and you would never see the expected activity being started.
If it's too late for calling addMonitor, the monitoring starts after the expected activity is launched, and the expected activity is not launched again since then, so waitForActivity will block because of no hit of the monitor.
So the difference between the two cases is whether the expected activity is started or not. And for your case, I think it's too late for calling addMonitor.
The solution is very easy: just move addMonitor to a early enough position before your LoginActivity starts, maybe move it to the setUp method, like this:
mInstrumentation = getInstrumentation();
ActivityMonitor monitor = mInstrumentation.addMonitor(LoginActivity.class.getName(), null, false);
BTW, for your case, with timeout or without timeout doesn't matter.
Don't forget to remove the monitor after it's not needed anymore e.g:
#Override
protected void tearDown() throws Exception {
mInstrumentation.removeMonitor(monitor);
super.tearDown();
}
public static Activity getCurrentActivity() {
final Activity[] currentActivity = {null};
getInstrumentation().runOnMainSync(new Runnable() {
public void run() {
Collection resumedActivities = ActivityLifecycleMonitorRegistry.getInstance()
.getActivitiesInStage(RESUMED);
if (resumedActivities.iterator().hasNext()) {
currentActivity[0] = (Activity) resumedActivities.iterator().next();
}
}
});
return currentActivity[0];
}
You were on the right track. The method you need to call is:
monitor.waitForActivityWithTimeout(TIME_OUT);
instead of
mInstrumentation.waitForMonitorWithTimeout(monitor, TIME_OUT);
I'm working with a fairly common situation right now - download some data over the web, then update a view to display it. Clearly, I want to do the web download in the background, and then update the view on the main UI thread. Now looking at my code, I'm a little worried about my Activity and its UI elements being killed off before I update them. Here's the essence of what I have in mind:
Thread update = new Thread() {
public void run() {
final Data newData = requestData();
if (newData != null) {
post(new Runnable() {
public void run() {
Toast.makeText(MyClass.this, "I'll do things here that depend on my context and views being valid", Toast.LENGTH_SHORT).show();
}
});
}
}
};
update.start();
It seems possible that while I'm downloading data, the activity may be destroyed. What happens then? Will my thread continue to execute? Will I end up trying to access dead objects?
Usually I do this by AsycTask, but the work seemed simple enough this time to just inline the threads-launching-threads stuff. Will I make things any better by using an AsyncTask instead?
If your Context is an Activity, you can check if it is finishing or has finished with the isFinishing() method:
if ( context instanceof Activity ) {
Activity activity = (Activity)context;
if ( activity.isFinishing() ) {
return;
}
}
Toast.makeText(context, "I'll do things here that depend on my context and views being valid", Toast.LENGTH_SHORT).show();
What you really want to use is an AsyncTaskLoader. These are my new favorite classes in the Android API. I use them all the time and they were made to solve problems just like this. You won't have to worry about when to stop your download or anything like that. All the threading logic is taken care of for you, including telling the thread to stop if the activity has been closed. Just say what it is you want to do in the loadInBackground() method. Note that if you are developing for an API lower than 3.0, you can still access all the loaders via the Android Support Package.
If you use anonymous classes, they will have an internal reference to the outer class, so it's not like it becomes inaccessible all of a sudden because other references have been cleared. AsyncTask actually doesn't change anything, it uses similar mechanics for notifying about results.
You can use loaders, they are designed to be in sync with the activity lifecycle. They are available only since Android 3.0, but you can use support package to work with them on any device with 1.6 or later.
There is even a simpler solution, you can just use a boolean field which indicates whether activity has gone away. You should set this field in onPause() (or whenever you think you won't need the notifications anymore) and check for it when you show toast. You won't even have to use synchronization, since this field is confined to the main thread, so it's absolutely safe. By the way, if you change this field somewhere else than in onDestroy(), don't forget to add a statement which resets your field back in the counterpart method.
public class MyActivity extends Activity {
private boolean activityDestroyed = false;
#Override
protected void onDestroy() {
activityDestroyed = true;
}
private void updateData() {
new Thread() {
#Override
public void run() {
final Data newData = requestData();
if (newData == null) return;
runOnUiThread(new Runnable() {
public void run() {
if (activityDestroyed) return;
Toast.makeText(MyActivity.this, "Blah",
Toast.LENGTH_SHORT).show();
}
});
}
}.start();
}
}
I usually use Weak Reference to avoid leaking context in views
Weak Reference for Context
private var mContext: WeakReference<Context?>? = null
Assign Context
mContext = WeakReference(appContext)
Get Context
mContext .get()
Validate Context
if (mContext?.get() is Activity &&
(mContext?.get() as Activity).isFinishing){
return
}
Kurtis is right. However, if you REALLY want to keep it simple, you can try this:
class MyActivity extends Activity {
static MyActivity context;
#Override
public void onCreate(Bundle icicle) {
super.onCreate(icicle);
MyActivity.context = this;
}
#Override
public void onDestroy() {
super.onDestroy();
MyActivity.context = null;
}
}
And then you just use MyActivity.context in your class (and check for null there). If you want the toast to not even show up when your app is in the background, use onPause/onResume instead.
Again, this is the quick and lazy approach. AsyncTask or AsyncTaskLoader is how you should be doing things.