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?
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 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 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
Our Android app currently has a large number of dialog and alert boxes. I'd like to switch these to toasts, but there's a problem - some of them require the user to choose whether to view more info or just dismiss the popup. It doesn't look like there's a way to do this with toasts.
Is there any existing Android library that supports tappable toasts (i.e., you tap it and it triggers a function call to a listener in the app, sort of like a notification)? If not, is there a recommended alternative for this "tap-here-to-do-something-otherwise-I'll-just-vanish-in-a-few-seconds" UI pattern, or should I just roll my own fragment class for it?
I have to do something similar to my app so I wrote, DropViewNotification, a boiler plate to make it happen by animating the so-called notification into the screen. It doesn't do automatic dismiss as this should only act as a tool.
It accept any kind of view to make it versatile as I need to put at least two or three obvious view into it (TextView, ProgressBar, ImageView). You can switch it's content on the fly if you want to. Animation can also be customized for both showing and dismissing of the notification and the main content.
In real-life you might want to consider adding controller class to handle the display of the content and auto dismissal, etc. Hope it's of some use to you.
I was in the midsts of tinkering in android with the goal of trying to make this small exploration game. I actually got pretty far so far: a nice sprite system, a title screen with a main menu that is all in game code (no UI buttons or anything) that launch various activities. An activity that loads this cool map view, that when clicked on will load up another view of a more detailed "zoomed in" action part of a map. It all works pretty well but now I am left wondering how well I am going about this.
(What happens to a view when you instantiate and then move the set the context to a new view? I am guessing as long as the activity is alive all the instantiations of various views that an activity uses are still good? And in an activities onPause is when id have to save the data thats changed in these views to persist the state in the event the user quits the game etc.. ?)
I have three menu options at the start of the game. The main one is:
New Game
The new game, I launch my main map
activity that can launch three views:
First two are a loading screen for
the second, a map screen.
Third view is a more detailed action
orientated part that uses this sprite
engine I developed.
It all works pretty good as in the map view you click on a cell it tells the Calling Activity through a listener to start the detailed action view, and passes in the ID of the cell (so it knows what objects to load in the detailed view based on the cell clicked in second view). (This took me awhile to figure out but someone helped here on another question to get this.) Reference that helped me on this part here. I also used the various information here on ViewSwitcher.
I got even a yes no dialog box in the second view that asks if they really wanna goto that cell when they click on it, a yes tells the calling activity to set the new view. What helped me to get this working was this reference here. I also had to fiddle with the calls to getContext and that, I am still not 100% sure what getResources and getContext do for me.
So is it bad practice to call and load a dialog from a view? If it is, then I don't understand how if I have an event in the view that needs to pop up a dialog how I do that? Call back to the activity and let the activity handle it the dialog response and then call a method on the view for the response?
So far all this works great, I did have a bit to learn about threads too. I spawn a different thread for my MenuView (handles the detection of button clicks and responses), my CellMap view which handles the cool big map that users can click on to see the indepth view which is my SystemView view.
So basically the activity call list is like this:
Home.Activity -> ScrollMap.activity which listens to CellMap wher ethe Yes/No dialog apperas (in the view of CellMap) and if the answer is yes to the question, then the onTouchEvent starts up the SystemView view using
private CellMap.MapClickedListener onTouchEvent=
new CellMap.MapClickedListener() {
#Override
public void onMapClick(int id) {
setContentView(new SolarSystem(theContext,id));
}
};
To help anyone else, that listener had to be defined in my CellMap class. Then in the ScrollMap activity when I am about to start the CellMap I just call a method to CellMap sets the map click listener. So far this is the only way I have been able to get data from a dialog (in this case a it was clicked so set the new view) back to the calling activity. Is this proper practice?
Now my biggest question is, I have a playerObject class I want to initialize on new game event (I know how to detect that push) and that then is available to any view in any activity for the life time of the cycle. So far the game activity has just two (3 if you count the loading progress bar) views. I want to get the players name, is that another activity or view? I cannot find a decent tutorial of just how to make a simple input dialogg box that would return a string.
How do i go about passing this stuff around? After I get the players name from wherever that edit box is to be loaded, I want to set the players name in the class and pass that class instance off to another view or activity so they may get at that data. Everything I have searched on this seemed like overkill or not the right way. Whats the best way to pass this "playerClass" around so that I can access it from other views (to say display the players name in every view).
I also have my Home Activity that waits for an onClick on 3 buttons, it then launches their activity that shows the view. I realize a continue game and new game are the same activity and will just change in data loaded off the drive to restore a save game. When the new game button is clicked I would love to get the players name they want to use and of course set the member of the playerClass to this name so it persists.
Where do I call (an edit dialog is it?) the edit dialog from? (more over how do I build one that can take an okay button and input from keyboard etc). Id also like to make it pretty, maybe I could have a simple view that has one edit box in it and a nice image background (though I haven't figured out how to place the edit boxes to fit nicely matching a background i draw for it. I guess id like an edit dialog I can skin to look how i want it to and fit the look of the game).
I am actually kinda happy what I got so far its looking not to bad, just not sure about some specifics like getting user input for a name of the player. Storing that information and passing it then to other activities and views.
Is it better to have one GameMain activity, and a ton of views:
Map view
Character sheet view
inventory view etc etc?
Or Should there be diff activities in there somewhere as well?
You've written a lot here, so I'm go gonna go ahead and answer the questions I think you're asking.
First, how can one share information between activities and views? If you're just sharing it between views in a single activity, store it in the instance of the Activity subclass.
Sharing between activities requires a little bit more. Instead of using an instance of the default Application class, you can create a subclass of Application and use that instead. Put your data in fields of that subclass. To tell your app to use your subclass, modify the app manifest like so:
<application
....
android:name=".YourAppClassNameHere">
....
</application>
As for getting user input, the simple answer is use the built-in EditText view. since you seem to want to give your game a more "custom" style, though, you may need to go about creating your own editable textbox. That and buttons should allow for most sorts of basic user input.
Now, good practice vis-a-vis activities and views. I'm not aware of a standard for this, but when designing I generally try to think of activities as more conceptually separate elements, whereas views are conceptually interwoven. the line between the two is dependent, in part, on the scope of the app; an app with a narrow focus can afford to break more actions down into different activities than can one with a much broader focus.
Your "GameMain" example is a bit on the fence, but I think you've made the right choice: the activity is "playing the game," as opposed to a menu or high-scores table, and the views present different aspects of the game being played.