I am doing a Popup with 3 Spinners and an EditText. After reading many blogs and articles I can't decide which is the best option, PopupWindow or DialogFragment.
The criteria would be:
Compatibility with different Android's versions
Performance
If there is a better way to do it I am open to change the perspective.
Thank you very much.
DialogFragment:
Pros:
Cons:
PopupWindow:
Pros:
Cons:
EDIT: CONCLUSION
DialogFragment allows you to use more complex features. Another important thing is that it is more tablet-friendly as it lets user to have opened more than one fragment at a time. Fragments are a more dynamic solution and they are the standard for newer Android versions.
PopupWindow is simpler and it is very helpful on simple questions to the user.
The support library can give you a DialogFragment which is compatible with old versions of android. Go ahead with the fragment dialog cuz what you're asking is pretty specifical (3 spinners and an edittext. Just right click your project and press on "Android tools" --> "Add support library"
Make sure when you use the dialog to import
import android.support.v4.app.DialogFragment;
Else you'll end up using the dialog without the support :P. You will have more flexibility with the dialog fragment and the power to use the view you see fit (even a layout made by yourself) without much effort.
Dialog Fragment
Pros:
Capable of adding any view
Easy to edit
Can be adapted to tablets or cellphones in landscape or portrait just by modifying the layout
Can dedicate a whole new class just to modify it your way
Cons:
Cosumes more memory the more complex is your view
Harder to code
Popup Window:
Pros:
Simpler
Easier to code
It's more standard so it'll be harder for the user to be confused with it
Cons:
Simpler, which means less control over it
Limited to a few templates
These are just from the top of my mind and from my experience, but you should read the documentation
http://developer.android.com/reference/android/widget/PopupWindow.html
http://developer.android.com/reference/android/app/DialogFragment.html
If you need EditText in your window and want to let your user to be able to longpress in it and paste (normal behaviour of an edit-text) then do not use popupwindow, I found it in hard way so:
A pretty Big Cons on popupwindow is that long press on edit-text wont bring default context menu (copy/paste/select all,...).also some reported in some devices this actually causes an app crash. see this
https://code.google.com/p/android/issues/detail?id=62508
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 want to create my customized own controls apart from standard Android views/widgets including View, ScrollBar, TextView, EditText, ...
And already completed others but not TextView/EditText yet.
The two controls interact with soft-keyboard on focus or not. Plus, you can type/edit the text of the control by the keyboard. More challenging part is about controlling the caret. These problems happen because the control inherits View, not TextView/EditText.
You may ask why I chose such difficult way, not using standard ones and customize only some part of them?
That's because of one fatal problem that standard TextView/EditText cannot support large files(a few MB files) and are lagging with them. Additionally, some of the important member functions are private, not protected or public. So we cannot customize fully them as we want.
That's why I created one customized text viewer/editor that supports large files (even over 100 MB). Viewer feature already has been implemented and works well.
Now the editor feature is remaining and it's the reason why I'm here to request your help.
Please let me know what's the best solution and I'd appreciate if you can provide with some sample codes.
Thanks
P.S. This is what I've done so far.
screenshot
apk
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.
I need some way to edit an item in my multi-line ListView - and it's just two text fields that need editing.
What would be the best way, design-wise, go about this? I feel that a whole new activity would waste too much screen space and look off, yet just a popup with the two fields and some confirm button might look off as well.
It's pretty subjective as to what's the best design for this, especially without knowing more about your specific use, however there are definitely a few possibilities that come to mind.
The new activity option that you noted is actually quite standard. You can see a similar paradigm used in Gmail, Google Talk, Messaging, etc. If your text fields expect to have something like a single word in each though, I can understand how that might feel like a waste of space to create a new activity. I wouldn't necessarily rule it out though; you can probably play around with styling to make it feel less empty (include labels, short descriptions, etc.). Also consider that most users nowadays have soft keyboards. That can take up a significant amount of space and make the view feel less empty.
The popup option seems less standard, but again if you styled it correctly I could see it working OK. What don't you like about this option?
Another option is to do a multi-pane layout of sorts which is far less common for a phone-sized layout but not out of the question. You could have a pane with two text boxes which is for the current item above your list view and have the contents change when you select an item in the list view. This is also a less standard UI.
You could also have an alternate view actually within the list item. In addition to your current (I'm assuming) two TextViews, you could have two EditTexts and maybe an OK and cancel button that are hidden. The visibility of all of these views would be toggled when you select the item.
There are more options too, I'm sure, but hopefully this will give you a little to think about at least.
I would use a separate activity for several reasons:
1) It's what users would expect. I can't recall any apps that use a pop up to edit contents of a listview
2) It'll be much easier to manage state in a separate activity e.g. when a user starts to enter some text and then gets interrupted by a call or email notification etc
3) If you're editing text then the keyboard wil take up most of the screen so you're activity won't look sparse.
you need to update in list view and add more items in list view???????
I'm unclear about when to use PopupWindow vs Dialog. Any insight would be much appreciated. Thanks.
They both use the addView() method along with various windowManager methods. The two are similar in that regard.
Dialogs seem to come with more built-in features for interaction, such as handlers and buttons already included in the base class, while PopupWindows come with more built-in methods for positioning them about the screen.
I think that each of them can do exactly the same as the other, but choosing between the two will be a matter of convenience to the programmer with regards to how you want to use the Object. I'm not a phD in computer science, but I do not think there is a significant difference in processing time between the two based on what I saw in their respective class definitions.
My advice: If you want to have greater control over where your View appears on the display, use a PopupWindow. If you want to add more control and feedback between your View then use a Dialog. If you, like me, want master control over everything, I would suggest a PopupWindow since it has fewer user-evident default methods to override.
I think, that you should use Dialog for simple user interaction (YES,NO).
I usually use Dialog for simple user interaction and WindowPopup for a little bit more complex view.
One example of WindowPopup is AutoCompleteTextView.
Hope it helps.
I think Dialog should use when you need to take action before proceed to continue next. It never cover the screen and always adjust center aligned as modal event.
On other side, PopupWindow has flexibility to adjust information anywhere in the screen as position wise like sticky footer, sticky header, on left, right, center etc. as per location set.
For Showing Information it's good option as there is facility to animate also.
In short, For Showing Information with minimal action go with PopupWindow and for controlled action to proceed next go with Dialog.