I'm calling an AlertDialog that exists in a different class. Directly after, I use a callback method to refresh the view. However, it appears the dialog runs on a separate thread, because the callback method gets called before the user makes a choice in the AlertDialog, instead of after.
How do I make sure the callback method is only called after the user has made a choice?
mClientManager.deleteClientConfirmationDialog ( getActivity (), id );
mCallback.refresh ();
However, it appears the dialog runs on a separate thread
No, it does not.
because the callback method gets called before the user makes a choice in the AlertDialog, instead of after
The dialog is not being shown until well after deleteClientConfirmationDialog() and refresh() have been called. You may be requesting the dialog to be shown somewhere in there, but all that does it put a message on a queue, to be processed by the main application thread, sometime after you return control of that thread to the framework.
How do I make sure the callback method is only called after the user has made a choice?
Put the logic in an appropriate event listener. Lance's suggestion of setOnDismissListener() is a reasonable choice, if you want refresh() to be called regardless of how or why the dialog is going away.
Related
I have a button that calls requestQueue.add method of the Volley library. Inside the onResponse method i call:
popupBox.display(getString(R.string.successfulRegistration), false, true);
Display method, displays a popup window thus must be called inside UI thread.
I put a break point at the beginning of the onResponse method.
Immediately after clicking on the button, switch to another app and send my app to the background.
IDE stops on the break point and I get my answer from the server but my app still is in the background and there is no exception error.
After about a minute, I bring my app to the foreground. After that, the message window pops up.
Is that mean, I don't need to check if I can do something related to UI thread inside the onResponse method because volley handles it?
onResponse and onErrorResponse are called on main thread by default unless you are trying to call them from some other tread. Volley makes the Api call on a non ui thread (non UI blocking). Volley doesn't take care of your life cycle. So, if you make a api call in an activity and close that activity, the callback are received. So, you should check whether the activity is in foreground or not.
I am new in android and I am learning from developer.android.com site. Then I came across to AlertDialog.dismiss() where in site it is written that
This method Dismiss dialog and remove it from the screen. This method can be
invoked safely from any thread. Note that you should not override this
method to do cleanup when the dialog is dismissed, instead implement
that in onStop().
But I did not understand the mean of this line-
Note that you should not override this method to do cleanup when the
dialog is dismissed, instead implement that in onStop()
what is the mean of above line?
`.
AlertDialog.dismiss() uses to dismiss the dialog if it's opened up as describe at developer site
Note that you should not override this method to do cleanup when the dialog is dismissed, instead implement that in onStop().
The above statement simply means that as we used to garbage collect object which is no more referenced in class and avail for garbage collect. They are simpling stating that the approach like avail for garbage collection also applies in here but there are eligible inside onStop() of Activity.
So better to use it as onStop() as it's the last call of Activity Life Cycle which can dismissed your alertdialog. If it incase is there on the screen without dismissal.
My Problem: Is it possible to prevent an activity to call OnResume() when it is being created? As I saw after the OnCreate() and onStart() method runs, the next one is the onResume(), although I only want to have it when I resume the activity from the paused state.
Why do I need this: I launch my activity (FragmentActivity, so lets say OnPostResume() ) starting with a thread which takes about 2-3s to be ready getting data from an external database. After the thread is done, I call a method which needs these data and I want to call it everytime that activity gets visible. The thread runs only when the FragmentActivity is created (onCreate()), and I cannot put the method into the onResume() because onResume() would be running way before the thread would finish its task. So it would receive not-ready data.
Anyone has a better idea?
Not sure of the exact application of this but I'll make a suggestion.
If you use an AsyncTask, you can send it off to get the data you need and in the onPostExcecute() method you can call your method that requires the data or update the view as needed. (It runs on the UI thread)
If you happen to already have the data you need in certain scenarios you could also bypass the AsyncTask and directly update the view.
This AsyncTask can be triggered in the onResume() method.
If I'm missing something, please let me know and I can adjust my suggestion.
I didn't understand the purpose of this, but here's a possible solution:
If you only wish to get the even of onResume on states that didn't have the onCreate before, just use a flag.
In the onCreate, set it to true, in the onResume check the flag (and also set it to false). if it was true, it means the onCreate was called before.
I personally would prefer to check if the result available, rather than always executing the getter-code in onResume. If the user somehow resumes your activity before the background thread is finished, you'd have a call on onResume, but don't want to display a result.
Maybe it would be a good idea to calculate/fetch the values in the thread, and let the thread return immediately (and cause the values to get filled in) if the values are already cached somewhere. That way you'd only have one entry point (the thread) for updating your UI instead of two (the thread and the onResume method).
I have a Async Task that creates a HashMap to create a Adapter to populate ListView. I have a progress dialog that shows during doInBackground method.In onPostExecute() method, I dismiss the progress dialog and call a method that populates my listview with the list of items saved in doInBackground method.
This works fine. But I noticed something strange:
The issue I see is, if I lock the screen when the progress dialog is about to be dismissed (in onPostExecute), the listview does not display, even though it has non-empty items in it. I verified it in logcat messages and when I debugged.
Is there a possibility that a screen lock (I do this my pressing power button once) blocking UI thread? How can I resolve the issue and make sure ListView displays its items?
Code for onResume():
#Override
protected void onResume(){
super.onResume();
if(MyAdapter !=null){
pull_listView.setAdapter(MyAdapter);//pull_listView is listview
MyAdapter.notifyDataSetChanged();//MyAdapter is the adapter
}
}
This situation illustrates the downside of using AsyncTask to do background processing. In some cases, an IntentService may be a better choice, especially if you think the background work is going to take some time. An AsyncTask ties the background work to the current Activity, while an IntentService is completely decoupled.
The Android training class Running in a Background Service shows you how to set up an IntentService, request work, and notify your Activity when the work is done. Passing data from the IntentService to the Activity is a bit more complicated, but there are options.
onStop() will be called when your screen goes out as per the Activity Lifecycle. You could override onStart() or onResume() and put a check in there to see if your data has been populated. If not, populate. You may even want to overide 'onStop()' to save data if the screen goes out.
Edit
In this particular situation, I would think onResume() or onStart() would be fine but onResume() is usually the safest because it is guaranteed to get called before the Activity is shown as illistrated in the link I gave. What kiind of a check you want to use is up to you and depends on how you handle evrything. However, if your AsyncTask is an inner class of your Activity class the you could simply create a boolean member variable, say boolean isDone=false; change this to true in your doInBackground() or onPostExecute() then your onResume() knows the data Is loaded. If its false then you can try to get data again. Hope this makes sense and can help
I have created a custom dialog called MyCustomDialog which extends Dialog. I create and show my custom dialog as follows:
new MyCustomDialog(myContext).show();
I override the Dialog.onCreate(Bundle savedInstanceState) method to do my initialisation. I also check in this method whether a certain condition holds and, if not, I would like to dismiss/cancel my dialog. I have tried calling the cancel() and dismiss() methods in my dialog's onCreate(Bundle savedInstanceState) and onStart() methods but it has no effect.
Anyone know how to cancel or dismiss a dialog (from within the dialog) before it shows?
You should place the logic to determine if the dialog is to be shown outside of the onCreate() method. it does not belong there.
Alternatively, rename your show() method showIfRequired() (or something), and add the conditional show logic there.
I know this doesn't technically answer your question, but what you are trying to do is not the correct design. That's a good thing, as doing in the right way is actually simpler.
Also, as a side note, you should using DialogFragment in favor of Dialog. it's available in the v4 support library.
This is for API levels 10 and below:
First you should override onCreateDialog(int id, Bundle args) in the Activity class, is that what you're doing? Dialogs are always created and displayed as part of the Activity. Second, I don't think you can cancel/dismiss a dialog in onCreateDialog because it hasn't actually been created when onCreateDialog is called. That is, you can't cancel/dismiss something that hasn't been created. What you can try is to override onPrepareDialog() instead and do your check to cancel/dismiss the dialog there. At that point the dialog should actually have been created (just not displayed), so you would be able to prevent it from getting displayed if you call cancel/dismiss there.
onPrepareDialog() is the proper place to do any sort of checks and decision making on the dialog that is about to be displayed. This is for APIs prior to Honeycomb.
This is for APIs 11 and later:
If you are using a later API, you should extend DialogFragment instead. In this case I think you can handle the decision making in onCreateView() method of DialogFragment which is similar to onPrepareDialog().
I hope you've read through this:
http://developer.android.com/guide/topics/ui/dialogs.html
or this, depending on your API:
http://developer.android.com/reference/android/app/DialogFragment.html
Overall, perhaps a cleaner solution is to disable the button or mechanism that causes the dialog to show up in the first place? That is, write you code such that Dialog.show() is called only when it really needs to be called. I'd have to know more details about what exactly you're trying to do. For example, say you call Dialog.show() from the onClickListener of a button. you don't really want the user to press a button, expect a dialog, but have it not show up due to some reason the user doesn't understand. A better solution would be to disable the button all together so that it's obvious to the user that this function isn't available due to something else in the application.