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.
Related
In Android I can display short messages to the user either using Toasts or Snackbars.
Is there a particular standard as to which ones I should be using? All Toasts? All Snackbars? Toasts during DialogFragments and Snackbars otherwise? Is there a way to force a Snackbar to display on "top" of the rest of the screen (in the event that I don't want to pass a specific view to it)?
If you want to confirm to the user that something just happened, that something went ok etc. a Toast is the way to go I would say.
But if the user did something like for example removed an item from a list, you would want to give the user an option to Undo. It could probably be done with an alert dialog but that's also annoying for the user. To be forced to change focus and act to an alert dialog asking if it's really what the user wants to do, for example "Do you really want to delete that? No Yes".
With a SnackBar you can inform the user that the item was deleted but also provide an Undo-action. Which should put back the item into the list on click.
Look at this short video, she explains the usage of those better :)
https://www.youtube.com/watch?v=puhfMX8jb9c&list=PLWz5rJ2EKKc-lJo_RGGXL2Psr8vVCTWjM&index=5
Snackbar it's material feature, Toast - holo style.
If your application has material design, more better use Snackbar as material item(like physical peace of paper) instead semitransparent/shadowed Toast.
In comparison to real world:
How often do you see "text in air"? Newer)) But may be when you under some drugs it possible) Ghost is unreal) Due to material world, texts on papers, boards, another physical places is normal behavior.
In case of upper snack, discover this
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 want to show a small Custom Dialog on top of the current user activity, but have clicks to the area outside of my Dialog delivered to the background (which would be the launcher, or another activity). I tried to create a transparent base-activity and have the Dialog shown on top of it, but clicks are registered on the transparent activity and not on whatever is behind it...
I know that a Popup has a setOutsideTouchable-Method, but setting this to true just dismisses the popup, rather than delivering clicks to the background, to my knowledge...
Thanks for your help,
Nick
Based on this clarification comment you posted on another answer...
"I want the Dialog to be shown system-wide, no matter which App the user is using at the moment..."
I don't believe what you want to do is possible and I'm happy about that. :) If you were allowed to popup a little dialog box over anyone else's app and still have the user be able to interact with the current activity... then you could easily trick the user into thinking that the little popup belonged to the current app and not yours which is acting from the background.
Imagine all of the evil you could do with something like that. Prompting for the user to reenter their email password when they are in the Email.app.. and then just storing it for malicious purposes, etc.
It isn't possible.. and SHOULDN'T be possible. If you need to notify the user of something, then you should use the built-in notification system. That's why it is there! :)
You can use a PopupWindow "Dialog like" and show it for the user in top of your activity. The outside events will be delivered to the main Activity.
I can't see the deeper meaning of exploiting the using the given usability patterns of android by doing what you ask for?
It is recommended and meaningful to stick to common patterns so users don't have to adapt in basic apps. That is, unless you are working on a game:)
"I want the Dialog to be shown
system-wide, no matter which App the
user is using at the moment..."
That is what the notification system is for. It allows you to tell something to the user without interrupting him in whatever he was doing.
System wide dialog popup are evil and gladly not implemented in Android.
Use the notification system : http://developer.android.com/reference/android/app/Notification.html
Also if you are ok with only a dialog above YOUR app, then the simplest way to let the UI be still responsive while your dialog is up, is simply to recreate a dialog in a relativelayout view and display this instead of the common modal dialog.
You could switch places so that the popup is actually "behind" the initial screen, but then set the initial screen as transparent.
Edit: This would only be applicable within an application of course.
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.
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.