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.
Related
I'll get straight to the point. Dialog's confuse the hell out of me. Why? Because it seems as though there are 5 different ways on instantiating them, giving them a custom layout, and using them. To add insult to injury the documentation on them is very poor. so I'm going to post the main questions I have here, and hope you guys can clear some of the confusion for me.
Question One:
what is the Real Difference between Dialog, and DialogFragment?
Question Two:
why is it better to use onCreateView, rather than onCreateDialog?
furthermore, Whats the difference?
Question Three:
why not just do *Dialog dialog = new Dialog();* everytime i need one,
rather than subclass DialogFragment constantly?
I apologize if this thread may not seem like a good fit for the community, but please keep in mind these are very real, and un-answered questions. Of all the tutorials I've read, from slidenerd-to-vogella-to-Stack everything explains the How, but not Why, which is just as important, if not more. Thanks Guys!
The difference between them is that a Dialog can only show a custom view but has no means in itself for you to interact with it's views / widgets programmatically at the runtime of the Dialog (ie when it's shown). DialogFragment extends Fragment and has all capabilities and the lifecycle of a Fragment (or very similar to them when used as a dialog).
DialogFragment can also be used as a 'normal' fragment, which means you could use a DialogFragment to show a dialog on a tablet or have it live inside an activity (ie full-screen) on a phone.
If the DialogFragment is also to be used as a Fragment, it has to return a View via onCreateView, so you'll have to implement onCreateView anyway. You can probably avoid code repetition if you only implement onCreateView and not onCreateView and onCreateDialog. But I've never heard someone say that is is 'better to use onCreateView, rather than onCreateDialog'.
You don't have to subclass DialogFragment for most dialogs. To show a simple Dialog eg. asking the user a question of showing a little bit of information, you can instantiate a new Dialog() or use the DialogBuilder. I use DialogFragments only when there's some logic going on within the Dialog that I want to reside in it's own class and makes use of the DialogFragments lifecycle.
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.
Surprisingly, I couldn't find any posts regarding this, so here we go:
Why would I want to use a DialogFragment over a simple Fragment in Android? What advantages does the DialogFragment have that I will miss out on if I just use a regular Fragment?
Might be worth mentioning that I intend to have a fully customized view inside it...
Thanks!
A DialogFragment is no other than a Fragment that looks and acts like a Dialog would. So whether or not you want to use it is entirely depended on what do you want to make out of it.
From my experience using DialogFragment, I tend to utilize it as a "detailed" view of a list item. The one that hovers on the list instead of covering it entirely (like a normal Fragment would) so that the user doesn't lose context.
So that's that; you might want to use it wherever you want to show a view which either depend or need to retain its' parent context.
p.s., Yes, you can even put a fully customized view in a DialogFragment.
Well, basically you have all features od a Dialog in a fragment.
For example the back is handled by the system, you can dismiss the dialog clicking outside the dialog view, you can set the dialog to be not cancellable. And yes, the look and feel is the same of the other dialogs.
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.
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).