Google recommends that we use DialogFragment
instead of a simple Dialog
by using Fragments API
, but it is absurd to use an isolated DialogFragment
for a simple Yes-No confirmation message box. What is the best practice in this case?
相关问题
- How can I create this custom Bottom Navigation on
- Bottom Navigation View gets Shrink Down
- How to make that the snackbar action button be sho
- Listening to outgoing sms not working android
- How to create Circular view on android wear?
相关文章
- android开发 怎么把图片放入drawable的文件夹下
- android上如何获取/storage/emulated/下的文件列表
- androidStudio有个箭头不认识
- SQLite不能创建表
- Windows - Android SDK manager not listing any plat
- Animate Recycler View grid when number of columns
- Why is the app closing suddenly without showing an
- Android OverlayItem.setMarker(): Change the marker
You can create generic DialogFragment subclasses like YesNoDialog and OkDialog, and pass in title and message if you use dialogs a lot in your app.
Then call it using the following:
And handle the result in
onActivityResult
.Yes, use
DialogFragment
and inonCreateDialog
you can simply use an AlertDialog builder anyway to create a simpleAlertDialog
with Yes/No confirmation buttons. Not very much code at all.With regards handling events in your fragment there would be various ways of doing it but I simply define a message
Handler
in myFragment
, pass it into theDialogFragment
via its constructor and then pass messages back to my fragment's handler as approprirate on the various click events. Again various ways of doing that but the following works for me.In the dialog hold a message and instantiate it in the constructor:
Implement the
onClickListener
in your dialog and then call the handler as appropriate:Edit
And as
Message
is parcelable you can save it out inonSaveInstanceState
and restore itThen in
onCreate
Generic AlertDialogFragment with Builder Pattern
In my project, I already used
AlertDialog.Builder
already a lot before I found out that it's problematic. However, I did not want to change that much code anywhere in my app. Additionally, I actually am a fan of passingOnClickListeners
as anonymous classes where they are needed (that is, when usingsetPositiveButton()
,setNegativeButton()
etc.) instead of having to implement thousands of callback methods to communicate between a dialog fragment and the holder fragment, which can, in my opinion, lead to very confusing and complex code. Especially, if you have multiple different dialogs in one fragment and then need to distinguish in the callback implementations between which dialog currently being shown.Therefore, I combined different approaches to create a generic
AlertDialogFragment
helper class which can be used exactly likeAlertDialog
:SOLUTION
(PLEASE NOTE that I am using Java 8 lambda expressions in my code, so you might have to change parts of the code if you are not using lambda expressions yet.)
USAGE
I am posting this here not only to share my solution, but also because I wanted to ask you people for your opinion: Is this approach legit or problematic to some extent?
Use DialogFragment over AlertDialog:
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 the dialog yourself (e.g. orientation change).
Difference DialogFragment - AlertDialog
Are they so much different? From Android reference regarding DialogFragment:
Other notes
I would recommend using
DialogFragment
.Sure, creating a "Yes/No" dialog with it is pretty complex considering that it should be rather simple task, but creating a similar dialog box with
Dialog
is surprisingly complicated as well.(Activity lifecycle makes it complicated - you must let
Activity
manage the lifecycle of the dialog box - and there is no way to pass custom parameters e.g. the custom message toActivity.showDialog
if using API levels under 8)The nice thing is that you can usually build your own abstraction on top of
DialogFragment
pretty easily.May I suggest a little simplification of @ashishduh's answer:
It removes the need for the user (of the class) to be familiar with the internals of the component and makes usage really simple:
P.S. In my case I needed a simple alert dialog so that's what I created. You can apply the approach to a Yes/No or any other type you need.