I have a fragment (xml and class) that provides a certain functionality, acts as a special value selector with lots of logic.
This fragment is used here and there (in layout files using <fragment/>) and now I want to display it as a dialog and allow the user to select a value from there.
This might be trivial, but I haven't found an answer after hours of searching.
I have been playing with DialogFragment but I cannot find a way to reuse it inside one. The only I managed to do was to inflate the layout only and display it as a dialog, which is not accepted since the selector logic is missing.
Notes: I am using appCompat if that makes any difference
You can change your current fragment to a DialogFragment. DialogFragments can either be embedded or shown as a dialog as explained in the documentation.
A DialogFragment can still optionally be used as a normal fragment, if
desired. This is useful if you have a fragment that in some cases
should be shown as a dialog and others embedded in a larger UI. This
behavior will normally be automatically selected for you based on how
you are using the fragment, but can be customized with
setShowsDialog(boolean).
Related
As this post relates to closed source software, I'm afraid I can't share any code snipplets... sorry about that!
Background
What I am trying to accomplish is to replace native autocomplete suggestions with a webview inside of an autocomplete dropdown. Now that could've been implemented in a few ways:
Implement Webview inside of a popup which anchors to the bottom of a EditText.
Use a vertical linearLayout which contains the searchEntry and the autocomplete webview with clipping disabled.
Implement the searchEntry as a standalone activity/fragment.
Commit the webview fragment inside of a DialogFragment.
Blockers
For reasons specific to internal frameworks and policy, I have resorted to option 4 for the following reasons:
Option 1 - The webview I'm using comes with a WebviewFragment controller that's required to interact with the rest of the application. As a result I must commit the fragment inside of the popupWindow. I've found no way to do this as the popup is detached.
Option 2 - I have to disable clipping in views higher in the hierarchy which is owned by other teams. I would like to avoid a lengthy review process if possible. This may also impact other teams in unforeseen ways.
Option 3 - The view I'm creating is created in another package higher up in the hierarchy, again owned by another team, and consumed by many more. The view implements an interface which has many custom controllers that I cannot easily replace in a standalone activity or fragment.
Option 4
I've opted to go with option 4, but I'm running into a major issue: I can't seem to set the focus to the EditText outside of the DialogFragment after the DialogFragment is spawned. This results in the UI looking odd, and we're not able to properly set the EditText value.
My Question
Is there a better solution for this use case? Is there an option worth revisiting?
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 have a question about the correct logical use of fragments in Android. I know that it was designed to be used to improve tablet experience, but does this imply that fragments should generally ONLY be used for this purpose? Or would it be poor development practice to use fragments as a replacement for a custom compound View?
For example, I am writing an app to keep tally. When the score sheet is produced, it creates a "ScoreCell," a custom compound control, for each player in a ScrollView. What I want to do(but don't see how as a View) is handle internal OnClickListeners that are activated by the containing activity: each ScoreCell has a TextView for the players' name, which I want to long-press to startActivityForResult() to pop open an input dialog to change the name of the ScoreCell. But seeing as the method for OnActivityResult() is unavailable in a View, would it be correct for me to instead make each ScoreCell a fragment?
Here is a picture of the activity to help understand the logic of what I need/am confused about
There are many questions in here, let me go through them.
No fragments are not meant just for tablet experience, in general they allow you to create more modular and adaptable layouts (think classes). They are extremely helpful in tablet layouts/landscape, but also give you reusable components.
At the same time, a fragment is not the right choice here... It is much easier to use a listview, coupled with a custom cell layout. Instead of using another activity to display a dialog simply call new Dialog() and dialog.show(). An activity should only be used as a dialog if it will be used by the user by a long period of time and provides a new "activity" (action)
Items in a list should not each be their own fragment, no. You can pop up a dialog without creating an entire Activity. Take a look at the documentation on AlertDialogs and DialogFragments for your dialogs and you can get the result from that.