I want to know if when the user presses "Yes" on an alert dialog and this one is dismissed, that event executes the onResume method of the activity in which the user is in.
Because I have a "Clean" button that asks the user if he's really sure of cleaning all the fields of the form (the activity) in order to redraw the activity with the empty fields.. The form is created dynamically, so I don't know a priori the elements in the GUI to set them empty...
Sorry for my bad english!!
Thanks and Greetings!
Not sure if this is the approach that should be taken, but you should be able to do what I think you are requesting. If for some reason this is what you would want to achieve.
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setMessage("Do you want to clean?")
.setPositiveButton("Yes", new DialogInterface.OnClickListener()
{
public void onClick(DialogInterface dialog, int id)
{
dialog.dismiss();
((ActivityName) appContext).onResume();
}
})
.setNegativeButton("No", new DialogInterface.OnClickListener()
{
public void onClick(DialogInterface dialog, int id)
{
dialog.dismiss();
}
});
builder.create().show();
}
You will really want to be calling your clean function instead of anything like a lifecycle call on a success while doing nothing on a failure.
Another potential way to approach this would be to bring the current activity back to the front using flags.
Intent intent = new Intent(this, CurrentlyRunningActivity.class);
intent.setFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT);
startActivity(intent);
Which would also provide a way to call upon your main activity without directly referencing the onResume() call, as pointed out is not the appropriate approach; however, I did want to directly respond to the question as it was asked.
To see if a method is called you can put a breakpoint at the method, onResume(), to see what happens. If you aren't familiar with the Acitvity Lifecycle then doing this will help you familiarize yourself with it and reading the provided documentation.
Now, I don't think you should redraw your whole layout just to clear some Views. It would be more efficient, in my opinion, to just reset all fields by using setText() or another method for whatever you need when the user clicks "ok " or whatever. You can use invalidate() if you need to redraw certain Views
I also recommend watching
Google I/O-Turbo Charge Your UI
Activity LifeCycle <-- very important to understand
AFAIK This is not possible since in order to have displayed the dialog box the activity would have already passed the onResume state. Check out the following page for more on the life cycle on an Android app (it really helped me understand better):
App lifecycle
If you're not sure when the onResume is called, add a log into the onResume method.
Related
I'm doing a videogame. I wanted the application to have 3 screens. The presentation screen, the play screen, and the end screen.
I know that an activity can be started with an intent, but my problem is that in doing so, the last activity would be stacked, allowing the user to come back to the previous activity (or screen).
Is there a way to avoid this ?
use the finish() method inside the activity you want to close.
Although others have covered that you can simply call the finish() method to close down an activity if you do not want your user to be able to return to it, there is another issue I wish to cover quickly.
The Android Design Principles, or more specifically the Navigation Principles tell us that we should not be messing around with the default behaviour of the back button too much. A direct quote from the guide;
Consistent navigation is an essential component of the overall user
experience. Few things frustrate users more than basic navigation that
behaves in inconsistent and unexpected ways.
So, instead of preventing your users from being able to return to the entry screen, consider instead a prompt that notifies your user that they will be leaving the game. That way the back button continues to work as they would expect, and your users will not be suddenly dropped from gameplay. You can override the back button like so;
#Override
public void onBackPressed() {
AlertDialog.Builder alert = new AlertDialog.Builder(this);
alert.setTitle("Leaving the Game");
alert.setMessage("Do you want to leave the game? You might lose your progress.");
alert.setPositiveButton("Yes", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int whichButton) {
YourActivity.this.finish();
}
});
alert.setNegativeButton("Cancel", null );
alert.show();
}
Also, as a note, if you choose to simply close the previous Activity using finish(), the back button will then drop the user out of the app entirely because there is no Activity to go back to.
I have an AlertDialog which appears initiated by a BroadcastReceiver - so the AlertDialog may appear ontop of ANY of my activities without knowing which activityis actually under it.
private void showAlert(Context context, String s) {
final AlertDialog alertDialog = new AlertDialog.Builder(context)
.create();
alertDialog.setTitle(context.getString(R.string.SMS_Alert_title));
alertDialog.setMessage(s);
alertDialog.setButton(context.getString(R.string.alert_OK),
new AlertDialog.OnClickListener() {
public void onClick(DialogInterface dialog, int which) {
return; //can't call the underlying activity's ui update method bec I don't know which activity is actually underlying
}
});
alertDialog.setIcon(R.drawable.icon);
alertDialog.show();
}
When I now press the "OK" button on the AlertDialog to dismiss it, the pressed status of all my buttons in the underlying activity become unpressed. I need them to remain pressed simply because my buttons show a different png during pressed status - which I also use to show that they are and remain "ON" when pressed. (I can't use toggle buttons in this case)
Ideally I just need to update my UI of the underlying activity but onResume is NOT called when the AlertDialog gets dismissed.
Also I cannot call any UI update method when pressing the ALertDialog OK button, since I do not know which activity is actually under the AlertDialog (as the ALertDialog may appear ontop of any activity)
(I hope I could explain the problem well enough)
ps While I could change the background of the unpressed buttons to the pressed png instead of just saying btn.setPressed(true) I would like to avoid it.
Many thanks
I'm not quite sure what you're trying to achieve. But have a go at following.
Have an interface named... say 'PressableActivity'? which has one method. 'pressAllButtons'
Implement this on all your activities you want the explained functionality, and implement the method to press all buttons when called.
Have a variable of type 'PressableActivity' on your context (or even a static class and a static variable will do.)
Assign this variable to the activity being displayed when it gets a call to onResume.
When you create the dialog, set an onDismissListener to it, which calls the 'pressAllButtons' method on the object pointed by static variable on your context.
Hope this helps.
One way or another you're going to need to "know" which activity is being displayed after the AlertDialog is dismissed. You can set an onDismissListener on your AlertDialog inside of your Activity and then respond accordingly. Why you would want your buttons to remain in a pressed state after they are not pressed is beyond me, but if that's what you really want then just set the state to pressed since that's essentially what you want: a forced pressed state even though the user hasn't pressed it again.
#Override
protected void onStop() {
super.onStop();
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setMessage("Test message")
.setCancelable(true)
.setPositiveButton("OK", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
dialog.cancel();
}
});
AlertDialog alert = builder.create();
alert.show();
}
This obviously isn't working, as soon as dialog is shown - activity is stopped (dialog disappears). How to solve this issuse?
I want to save some setting into my database as soon as activity is left (via back button, clicking on some button which leads to some other activity, click on notification and so on..) and then show the result in AlertDialog?
Or even better - when Android recognizes that activity will be closed, it saves my settings, show AlertDialog and then onClick Activity is finally closed.
It's a very bad practice to try to do something that takes time and user attention in onStop and onPause. Usually these methods are used to save some data. You can try to show a Toast, but the best way - is to show nothing, as it's not an usual practice. Is there really something important you need to show? This is the question you must resolve in first place.
You should call super.onStop() after you are done with your processing.
I guess you need to send settings when the user exits the application or application envokes onPause(). Why don't you try to grasp all ways of exiting application lets say Back button pressed, so add listener for all these events. And do the sending.
It was my understanding, obviously wrong, that onPause() is called whenever the back button is pressed? Now in my code I've put this onPause() event:
#Override
protected void onPause(){
super.onPause();
if(!_END_GAME){
Builder _alert = new AlertDialog.Builder(this)
.setMessage("onPause, with game NOT over!");
_alert.setNeutralButton("OK.",
new DialogInterface.OnClickListener() {
public void onClick(DialogInterface arg0, int arg1) {
arg0.dismiss(); // Kills the interface
System.runFinalizersOnExit(true);
finish();
}
});
_alert.setTitle("Your Score!");
_alert.show();
}
}
Now the problem is, the dialog does not launch what-so-ever, and then the code errors out. I put the dialog there to try to visualize where the onPause() was called and help me debug some other variables and such. Yet like I said it never even gets shown. Any ideas why this would be? Is there a function that is launched prior to onPause() when the back button is pressed? Thank you in advance for any info.
onPause will always be called when your activity is no longer in the foreground, that's guaranteed. Maybe your _END_GAME is not false? Add a debug log output to your onPause method, you'll see that it always gets called.
I should note though that displaying a dialog during onPause is extremely bad form - the user is trying to get rid of your app (could even be because of an incoming phone call). You DO NOT want a dialog then. That goes against the Android design.
In fact, the Android OS will simply short-circuit your app if you try to do lengthy shenanigans in onDestroy or onPause. Basically, if those get called, you're supposed to disappear quietly.
If you really want to intercept the back button, you can check for the button like Ted suggested, but keep in mind that your app can go to the background in many other ways - home button, selected notification, incoming phone call, etc.
You should check for the back button by overriding onKeyDown, not testing in onPause. onPause gets called whenever your activity is no longer in the background leaves the foreground; it is not necessarily finishing. (You can check isFinishing() for that.) See here for more info on handling the back key.
onPause is getting called, and your dialog is showing, just for a tiny split-second before Android finishes your app. Put log statements in there if you want to watch what is going on.
If you want to show a dialog when the back button is pressed then the easiest way (works on Android 2.1+) is to override the onBackPressed method in your activity
#Override
public void onBackPressed() {
if (gameRunning) {
// show dialog
} else {
// exit
super.onBackPressed();
}
}
I've already discovered that you can't override the Home button on an Android phone. It exits the application, it ALWAYS exits the application, and it DOESN'T bother with any sort of namby-pamby confirmation. I suppose I understand Google's reasoning -- but I do think it's a bit short-sighted...
Anyway, (before I learned about the Home button), I set up my app so the user can exit the application through the Options Menu -- using onCreateOptionsMenu() and an XML file, I set up a simple pop-up menu that's displayed when the Menu button is pressed. One of its choices is Exit, and it works fine.
However, it occurred to me that it might be good practice to add a confirmation dialog to the exit process (even if it could also be considered superfluous). So, I created an AlertDialog with the title "Do you want to Exit?" and Yes and No buttons...
The click listeners for the buttons are simple and just set exitConfirm (a boolean) true or false. The code that handles the Exit menu choice then cleans up after my application and executes finish() or not depending on the state of exitConfirm...
Unfortunately, it completely doesn't work... All of the code in onOptionsItemSelected() for the exit case executes and THEN the Dialog is displayed!! I suppose I should've seen that coming. And I suppose if I keep pounding on it, I'll come up with a way accomplish this, but I thought I would ask the community for suggestions - so, does anybody have a suggestion for a way to smoothly exit an Android application in a manner that includes the step of getting confirmation from the user??
Thanks,
R.
First of all - this is a terrible practice. Asking for confirmation may be a nice option on a desktop application, but you're writing a mobile application. It's different. Actually, I need to write that in bold:
You are not writing a desktop application.
I recommend: No splash screen. No exit option. Definitely no exit confirmation. Here is an excellent question about it.
For your question: Use setPositiveButton and setNegativeButton to handle buttons.
Short answer:
You should read: When to Include an Exit Button in Android Apps.
Long answer:
You can try something like this:
protected Dialog onCreateDialog(int id) {
Dialog dialog = null;
switch (id) {
case MENU_QUIT:
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setMessage(getString(R.string.main_screen_quit_text))
.setCancelable(false)
.setPositiveButton(
getString(R.string.main_screen_quit_yes),
new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog,
int id) {
moveTaskToBack(true);
}
})
.setNegativeButton(getString(R.string.main_screen_quit_no),
new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog,
int id) {
dialog.cancel();
}
});
AlertDialog alert = builder.create();
return alert;
default:
dialog = null;
}
return dialog;
}
Apparently, it's generally considered not to be cool to have an exit button (or menu item, or whatever) in your Android app. Apparently, this is because your application doesn't really exit. It's only minimized out of the way, and presumably, the OS will take care of it eventually.
However, if what you're doing requires some level of clean-up when you're done doing it, this is what I think I know about that:
Pay careful attention to the various Android "Life Cycle Methods", especially what kicks them off. Life cycle methods include onCreate(), onStart(), onResume(), onPause(), and onStop(). There's also onDestroy() -- the complement to onCreate() -- but I don't currently use it.
These methods are called in response to various events (like pressing the Home button), but what was important in my case was that minimizing the application calls onPause() and maximizing it calls onResume(). Hence, I needed to call my set up and tear down methods from those locations, and NOT, for instance, from onCreate() and onDestroy().
There is a function called finish() that I used to use all over my code. Now it's only in the method that's called to handle loss of communication with my external device. I believe the results of calling finish() are exactly the results of pressing the Home button -- so, it's just a way to "press" the Home button in software.
The long-winded conclusion to all this is the Home button absolutely WILL hide your application from the user's view. You cannot trap this key press -- no matter how badly you want to add some sort of, "Are you sure??" functionality. However, the app's been minimized, not closed, and this can either be good or bad. If you've written your start up and shut down code properly (and added it to the proper life cycle methods), you won't blow things up, and your user will be able to easily return to your app once they've learned to long press the Home button to see a list of minimized apps.
With any luck, I suppose, they'll blame their frustration on Google, and not on you...