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
Related
So I have a requirement around accessibility wherein a button needs to be read out when it comes in focus and then another text to be read out after user clicks on it.
For example,
An "OK" button when focussed should read "OK" but when a user taps on it, it should read out some other text eg. "Navigating to the other page".
Is there a way in Android to implement this?
I have not been able to find anything around it.
You can use View#announceForAccessibility(CharSequence) to make a general announcement - so in your OnClickListener get a reference to some View (e.g. your Button, it doesn't matter what it is) and call that on it.
Like it says in the docs, this is a convenience function that creates a very general "something is getting announced for no specific reason" event - you might want to give more context, like creating a TYPE_VIEW_CLICKED event. This might be more helpful to the user (depending on how the accessibility service handles it) and could provide a better experience, since stuff that's read out is prioritised depending on what it is. I don't have time to get into it here, but it's something you can investigate if you want
Also I'm not sure if this is what you mean, but just in case - if the user focuses your button, it should say "[OK] button, double tap to [some description]". The bits in brackets you can customise, the rest is standard description for a Button in the UI. You shouldn't change this to just say "OK".
That predictable and consistent system is there for a reason, to help partially sighted and blind people understand exactly what's going on with the app they're using. It might sound clunky at times, but it's meant to be functional, not slick. So we shouldn't try to get around it and make it "sound better" by removing important info and context that some people really need. I don't know if that's what you meant, but it's always worth mentioning!
I have an app where an action by the user sometimes causes the app to get data from the server before it can be displayed, like getting detail info for an item (the info is too large to preload it for all items) or refreshing all data.
While this is in process i don't want the user to do anything else. What is the guideline to display a "please wait" message? Ideally it should be possible for the user to cancel the request if he wants to.
I can do it with an alert dialog, but the operation usually takes just half a second to a second, and imo it looks really strange for an alert dialog to pop up just for a moment, maybe not even long enough to be able to read the message.
Another option i see is the snack bar, but it doesn't prevent the user from doing anything else or navigate away.
Is there a guideline or best practice what to do in this scenario?
I'm using Xamarin.Android, but i don't think that matters.
You can show a loading circle in place where the content being loaded will be displayed like this. When it finishes, replace the loading circle with the content.
Actually "i don't want the user to do anything else" is not acceptable in most Android design patterns. Android app should allow the user to take control of the app.
About canceling the request, you can add a cancel button near the loading circle, or add a cross inside the circle which will stop the process when being pressed. The latter is preferred.
For more patterns see this.
About progress dialog
As far as I know, progress dialog which block the user interaction is discouraged in the new Android. But I am sorry that I cannot find the reference yet, maybe somewhere in Material Design guidelines document. However, because you are the developer, it's all up to you :D.
Check out the documentation on AsyncTask.
I would do the long running task in an AsyncTask, show a ProgressDialog in it's onPreExecute method and hide it after it finised, in onPostExecute.
To prevent the user from closing the dialog you can use the Dialog.setCancelable() method.
You can define a custom layout for your Dialog and set it via the setContentView() method.
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 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 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.