I'm playing around with Dialog to create some quick views in my app (like login enter name etc)
and I'm wandering what is better: hide or dismiss.
I know what they both do but I keep wandering if it is better to just hide a Dialog and show it again when I need or to dismiss it and recreate it.
my Dialogs are small and are actually static in my code so as such I don't hold tons of instances.
So can somebody give me the pros and cons of using hide over dismiss.
Using hide() could cause a Leaked Window error.
If you choose to use hide() and you exit your application using finish(), this will cause an error message (seen here) about a window being leaked.
So, either dismiss() your dialogs properly before calling finish() or just use dismiss() instead of hide().
It depends on how many time your need it, and if it is expensive to create it. If it is not too expensive to create it, I would personally prefer to dismiss it, to have a "cleaner environment". But if you're not using hundreds of dialogs, I don't think this really matters.
I know that It is a very old post but I've found none of the answers above good enough, so in the simplest way of explaining:
hide() will just change the visibility status of the dialog but the object will be still there and can be shown again using show() method.
dismiss() hides and also destroys the dialog. To show the dialog again it needs to be recreated first.
Then if you need to show and hide a dialog many times better to hide() it. eventually dismiss() it on onDestroy() to avoid the window leak error. Note that leaving the activity when a dialog not dismissed causes the memory leak.
hope it will be useful for feature references.
I assume by 'static' you mean the content is not dynamic, not that you've got static objects in your code. In that case it's probably best to dismiss the dialog and allow the VM to recollect any memory allocated for it. The resources necessary to create a dialog are trivial but holding onto memory when it's not very frequently used is a good way to starve the system of memory.
Consider your app may be one of half a dozen apps running. If they all kept their "cheap" objects hidden instead of dismissing them pretty soon something's going to be forced to close by the VM to reclaim memory.
At the same time we're talking about a Dialog which is not exactly a large object. I'd offer the standard behavior would be to dismiss it unless you can create a convincing argument why it's cheaper to hide it to save resources on re-creation (for example, if you're very frequently displaying this dialog).
Related
Say I have several dialog fragments that are shown in response to messages and events that can arrive in any order. Normally, the last dialog shown will be on top. Is there a way to show a dialog fragment under an existing one, or change their z-order after they are shown?
It should be pretty rare for my app to show more than one dialog at a time, but it could happen. There is one particular dialog that should always be on top whenever it's visible.
A dialog creates an application sub-window. Android's window manager (WindowManagerService) automatically computes window's z-order depending on its type and stores it in WindowState's mLayer field. Internal Android classes have access to this field and change window's z-order sometimes, but this API is not exposed to Android SDK. So it seems that the only way to affect dialog's z-order is to recreate it.
Everything I wrote above is just a result of a brief investigation of Android's source code so I may be wrong. And maybe there's some hacky way to do what you want using reflection and accessing private fields and methods. But I'm not sure it's a good idea to try and do it. In my opinion it would be better to have just a single dialog or even activity, and manage fragments within it.
I am developing an Android library to ask the users of an app to give a rating on the Play Store.
The UX of the library consists in a few dialogs. Depending on the answer to the first question I might need to dismiss the current dialog, to show another dialog or to take the user to the Play Store.
Everything works nice unless I rotate the screen in the middle of the process.
I tried to solve my issues with the use of fragments. With fragments I am not losing anymore the state of the dialogs with the rotation but I am having troubles instantiating the second DialogFragment. The problem is that, after a rotation, the context of the first DialogFragment is no more active and it has no way to retrieve the new context. That results in exceptions every time I try to instantiate the new DialogFragment.
Is there any way I could solve this issue?
Thinking again at the problem, it seems that my design choice was wrong but I am not very experienced in Android development. Every advice will be more than welcome.
You should be using the listener pattern. Define an interface in each dialog and send clicks back to the activity. Let it create the dialogs.
see here
Also, if you need a context in the fragments, just call getActivity(), don't create an unnecessary context variable that could later give back an activity that's already gone. I hope that helps. I can't give a better answer without some code to see what's going wrong in this specific situation.
This question already has answers here:
Android DialogFragment vs Dialog
(10 answers)
Closed 6 years ago.
When developing an Android app, I've read that it's recommended to use DialogFragment instead of using directly an AlertDialog to show alerts and confirmations.
This is done, for example, on DialogFragment's Documentation: http://developer.android.com/reference/android/app/DialogFragment.html
People also say they prefer this here:
Android DialogFragment vs Dialog
I would like to know the advantages of this approach, since the code becomes more complex.
Thanks
This is easy.
DialogFragment is a fragment.
So what can a fragment provide you while other objects can't?
It's the lifecycle callbacks.
So with DialogFragment, it can be very powerful and makes your code much cleaner.
Have you ever seen window leaks if you didn't close a dialog when its Activity was getting destroyed? So to prevent that, have you ever tried to close the dialog when onPause() was called? So to do that, have you ever had to make a reference of that dialog to a class level object?
With DialogFragment, it's all handled.
And you get all lifecycle callbacks.
Then you can provide more intelligence to the dialog and make it do some smart work on its own rather than Activity telling it what to do.
Use DialogFragment over Dialog:
Since the introduction of API level 13:
the showDialog method from Activity is deprecated.
Invoking a dialog elsewhere in code is not advisable since you will have to manage the dialog yourself (e.g. orientation change). Not using the showDialog will result in occasional exceptions, the dialog is not linked to any Activity.
Note about showDialog:
reference of Dialog: Activities provide a facility to manage the creation, saving and restoring of dialogs. See onCreateDialog(int), onPrepareDialog(int, Dialog), showDialog(int), and dismissDialog(int). If these methods are used, getOwnerActivity() will return the Activity that managed this dialog.
Difference between DialogFragment and AlertDialog
One thing that comes to mind when reading your question. Are they so much different?
A DialogFragment is pretty similar to a Dialog, it's just wrapped inside a fragment. From Android reference regarding DialogFragment:
A DialogFragment is a fragment that displays a dialog window, floating on top of its
activity's window. This fragment contains a Dialog object, which it
displays as appropriate based on the fragment's state. Control of the
dialog (deciding when to show, hide, dismiss it) should be done
through the API here, not with direct calls on the dialog.
Other notes
Fragments are a natural evolution in the Android framework due to the diversity of devices with different screen sizes.
DialogFragments and Fragments are made available in the support library which makes the class usable in all current used versions of Android.
In my application, I have multiple dialogs of various types, and I invoke them like showDialog(dialogType).
I want a specific type of dialog to have a higher priority and to be shown always in the front. I even tried higherPriorityDialog.hide() to hide that dialog and higherPriorityDialog.show() to again show it, so that it should come to front, but no luck.
Is there any way I can do this?
Finally, I had to do something like this, keep a Vector of all the `Dialog' objects somewhere. Whenever a lowPriorityDialog comes, just finish highPriorityDialogs, and display that lowPriorityDialog and again display all the highPriorityDialogs. Hope I am not confusing you.
most likely you have to close all other dialogs before you open another. so call .close() on one and call .show() on another
I am not sure if android supports opening of multiple dialogs at a same time even if they are hidden.
Personally, I like to open a new activity instead of a dialog because I can control the design easier (such as the layout, different window options, size). Plus I feel it's much simpler to handle all of the component's listeners and such. But is there any benefit to running a dialog instead of an activity? Is it faster and less memory exhausting?
First off you can create a custom Dialog to look basically however you want. However, as a direct answer to your question, the only drawbacks that I can think of are a) the original activity is now in an onStop state which means it could be killed, and b) You are using more resources to add a whole activity, instead of a dialog. That being said, there is a time and a place for everything.