We have been using just Toasts in our application so far and as we are planning to adopt some new features from Support Design Library I am wondering what's the recommended usage for Snackbar vs. Toast.
I have been reading on the google material snackbar doc.
Snackbars provide lightweight feedback about an operation in a small
popup at the base of the screen on mobile and at the lower left on
desktop. They are above all over elements on screen, including the
FAB.
and toasts.
Android also provides a capsule-shaped toast, primarily used for
system messaging. Toasts are similar to snackbars but do not contain
actions and cannot be swiped off screen.
I understand what they do but I am a bit confused when to use what. Does it mean that:
If I don't require user interaction I would use a toast?
What is meant by "system messaging"? Does that apply to displaying information when something important happened between my app and the Android system?
What I like is the swipe off screen feature - would that be a reason to start replacing toasts with snackbars? (this is a bit opinion based question though)
If I don't require user interaction I would use a toast?
You can still use Snackbar. It is not mandatory to have an action with Snackbar.
What is meant by "system messaging"? Does that apply to displaying
information when something important happened between my app and the
Android system?
I believe this means that Toasts are to be used if there are some messages pertaining to the system. Either android as a whole or some background service you may be running. E.g. Text-To-Speech is not installed. OR No Email client found.
What I like is the swipe off screen feature - would that be a reason
to start replacing toasts with Snackbar? (this is a bit opinion based
question though)
That is one reason. But there are several other plus points. For an example: Your toast remains on screen even when the activity is finished. Snackbar doesn't. There is less confusion if the toast does not popup (or keep popping up in case of multiple Toast creation in sequence) long after the app is exited. This will not happen with Snackbar.
More than everything: I suggest if you are thinking, you should switch. SnackBars look far better than Toasts.
I would like to add a small comparison between toast and snack bar. In my opinion if your intention is to present a warning or info that need user interaction/acknowledgement, you should use a snack bar. If it is just an info message that doesn't need any user acknowledgement you can use toast.
#
Toast
Snackbar
1
Can't be dismissed by swiping
Can dismiss by swiping
2
Activity not required (Can show in android home or above other apps)
Can show inside an activity of your app
3
Can't handle user input
Can handle user input
4
Good for showing info messages to user
Good for showing warning/info type messages to user that needs attention
Toast:
Toast was added in API Level 1
Basically Activity is not required (Can be shown on Android home or even above other apps)
It can’t perform an action based on User input
It can’t be dismissed by swiping
It can’t handle user input like Swipe, Click etc.
Good for showing info messages to user
SnackBar:
SnackBar was added in API Level 23
It can be showed inside an activity of the Applications
It can perform an action
It can be dismissed by swiping
It can handle user input
Good for showing warning/info type messages to user that needs attention
Usage of SnackBar and Toast:
SnackBar:
SnackBar can be used in the areas where a simple popup message needs to be displayed along with an option to perform action.
For Example: In GMail application, when you delete Mail, quick SnackBar display at the bottom with Message ‘1 Deleted’ with an action button ‘Undo’. On pressing the ‘Undo’ action button, the deleted mail will be restored.
Toast:
Toast can be used in the areas where System messages need to be displayed.
For Example:
When your App tries to download JSON from remote server but it fails due to Server Timeout or No resource found, you just need to display the error message saying that ‘Error Occurred’. But understand the Toast message cannot be dismissed by swiping. If you still want to have the capability of dismissing it in your App, go for SnackBar.
According to the official documentation at Pop-up messages overview:
Note: The Snackbar class supersedes Toast. While Toast is currently still supported, Snackbar is now the preferred way to display brief, transient messages to the user.
and (Material Design) Snackbars's documentation:
Related concepts: Android also provides a Toast class with a similar API that can be used for displaying system-level notifications. Generally, snackbars are the preferred mechanism for displaying feedback messages to users, as they can be displayed in the context of the UI where the action occurred. Reserve Toast for cases where this cannot be done.
Difference between Toast and Snackbar Android
Toast messages can be customized and printed anywhere on the screen, but a Snackbar can be only shown in the bottom of the screen.
A Toast message doesn’t have action button, but Snackbar may have action button optionally.
Toast message cannot be off until the time limit finish, but Snackbar can be swiped off before the time limit.
You can set how long the message will be shown using this three different values.
Snackbar.LENGTH_LONG
Snackbar.LENGTH_SHORT
Snackbar.LENGTH_INDEFINITE
Usage
Toast
Toast.makeText(getApplicationContext(),"Hello",Toast.LENGTH_SHORT).show();
Snackbar
Snackbar snackbar = Snackbar.make(view,"This is Simple Snackbar",Snackbar.LENGTH_SHORT);
snackbar.show();
Google's Material Design Specification says that it's ok to have a Snackbar without an action. They have provided examples of what a Snackbar should look like if it only displays a single String. I would assume that "System Messaging" means device events like network connection being lost - whereas archiving an email is a Gmail specific action, for example.
For consistency's sake, it makes sense to pick either a Toast or a Snackbar, and apply that throughout your app.
The short answer is that those are 2 ways to communicate things to the user that happen in the background, and you can peak one of them, they both fine. Just make sure you're using the same one and not switching between them back and forth.
The long answer:
No, that's mean that if you need some action you must use Snackbar. You can still use Snackbar only for messages (like "Uploading finished").
By "system" it doesn't mean just Android system. For example- if there was a json parsing problem while getting info from your server you can still use toast to let the user there was a problem while communicate with the server.
If you really need to swipe this off, that absultly be a reason to pick Snackbar
Our design team is looking at using either toasts or snackbars as well. We come to a conclusion that the app should be using snackbars given the flexibility of it.
Toasts should only be used when we need a persistent, short string, info message that still make sense across different screens.
Android also provides a capsule-shaped toast, primarily used for system messaging.
I think with "system messaging" they also refer to the fact that a toast will be shown for a specific time and can not be dismissed even if the user navigates across activities and even if the app is moved to background.
I consider it an advantage of snackbar to limit its scope to an activity and to be able to dismiss it.
Related
I used to call the show() method on a created toast every 1s during a few seconds, to obtain a toast that stays on screen for more than LENGTH_LONG.
(Similar to Android SDK keep Toast from fading away)
Note: the toast text is periodically changed while it's being displayed.
Unfortunately, it does not work anymore with Android 8.0: the toast now disappears after approximately 4s. It looks like only the 1st call to show() is working, and all subsequent calls have no effect.
I understand that it is not the intended behaviour of a Toast to stay on-screen, but before moving to another solution, I just wanted to check if this is an expected behaviour of Android 8.0 ? Maybe related to the Toast overlay attack vulnerability ?
Since Android 7.1.1 each non-system package can only queue one Toast at a time. See the commit:
https://android.googlesource.com/platform/frameworks/base/+/4ee785b698211b5ccce104e226b073ffbb12df55
Furthermore, even if you bypass the Toast mechanism and add TYPE_TOAST window directly, you will end up with a "bad token exception" if you add a TYPE_TOAST window more than once at a time. This is to enforce the policy that toast windows can only be displayed for a limited time (3.5s to be precise).
https://android.googlesource.com/platform/frameworks/base/+/dc24f93%5E%21/
(Note the changes to WindowManagerService.java. A return of WindowManagerGlobal.ADD_DUPLICATE_ADD causes exception to be thrown at an upper level)
So yes, the behavior is intended.
Android has taken steps to prevent malicious toast overlay that can trick users into granting unnecessary permissions or running other unwanted code. So it makes sense that a persistent icon is prevented from being shown.
However, I have also come across a SO question regarding an undesired text "blending effect" in Android Oreo Toast discussed here.
Therefore it seems that at some point Oreo has allowed for subsequent immediate Toast calls and it may not be the default behavior just yet.
My app returns a collection of status messages which I'm currently displaying in Toast dialogs. However, the number of status messages is steadily increasing which makes Toast a less viable option.
What I want to do is create a dialog that displays messages in a ListView. However, any dialog I create is shown on top of an activity and so when I change activities the dialog is lost. How can I create a dialog that maintains its visibility across activities, like Toast does?
It seems you are looking for some kind of notification service that already exists in Android. You can solve this on different levels:
In App
for Example create a BaseActivity that always has some sort of list that contains the messages you want the user to see, and extend for the activities you want. And keep some kind of a Queue for unread messages. How you visualize this is completely up to you.
Use the systems notification and consider Updating notifications.
https://developer.android.com/guide/topics/ui/notifiers/notifications.html
What is the best way of displaying error messages to the user?
Assume the following scenario (just for example, this question relates to common problem, when error may occur in service, in the thread etc.):
We load some data for some screen
Error occurs (Internet is not available, server exception, other exceptions ...)
How to show the error? Possible solutions:
Show toasts - the simplest way but it is not the best (for many errors we'll see many toasts, even if the application works in the background)
Show error somewhere in the screen (e.g. gmail shows 'No connection' at the bottom of the list and proposes to retry)
What is your experience? How do you show user errors? Is there some guides explaining what is the best way?
I have used the alertDialog.. refer the Images. futher google it
For user Attention.
for form Validation edit texts use editText.setError("Your error message") method
for internet connection failed
for internent connection failed with retry.
Update 1
For showing some auto terminate info/message we use Toast
for example notifying a user that your Email was sent Successfully. We can Use Toast like below
Toast.makeText(context, "Email was sent Successfully.", duration).show()
Note: User can't interact with Default toast, See also Custom Toast Layout
Another option is to use the new Snackbar
Hope this will be helpful
It depends on the app, and what the app will be able to do once it has met this
error.
The two methods that Google suggests in the Material Design Guide to deal with these types of messages are:
Dialogs (in this case the Alert Dialog):
and Snackbars:
To use your example: Some data is requested from a remote server, but because of some error or exception, the fetch fails and no data is returned.
At this point, the type of error message would depend on how the app will function from that point on, without that data. If the app will perform as it is, meaning the fetch was something akin to a background update, the appropriate thing to show would be a Snackbar. Why?
From the Guide:
Snackbars provide lightweight feedback about an operation by showing a brief message at the bottom of the screen. Snackbars can contain an action.
Lightweight is really the reason here. If the app will function without that background data fetch, you should not block the UI with a message. Just let the user know things didn't work out the way they should so that he can do something about it if he cares.
Here is an example taken from the guide:
For code: the Developer Docs on Snackbars
Never use a Toast. A Toast is too small, too brief and can go by unnoticed. Use a Snackbar.
But, in the scenario where your app will not function, or will show nothing but a blank screen without that data, the correct thing to do would be to show an Alert Dialog.
No one wants to see nothing but a blank screen, and if you can't populate it with data, you need to give the user a screen from which they can perform alternate functions, even if that is to quit the app.
From the Guide on Alerts:
Alerts inform the user about a situation or action that requires their
confirmation or acknowledgement before proceeding. They differ
slightly in appearance based upon the severity and impact of the
message conveyed.
Alerts are interruptive, urgent, and prevent users from proceeding
until they make a decision.
AND
Disambiguation from Snackbars: In contrast to Alerts, Snackbars
present optional but important information or actions and usually
appear after an action. For example, use an alert to confirm
discarding a draft. Use a snackbar to present an undo action, because
the action is optional and the user can continue with their primary
task without taking action.
So if the app won't function without that data, go with an Alert Dialog.
Anything but a Toast.
Check out Croutons:
http://android.cyrilmottier.com/?p=773
I would say that it depends on wether your application currently has a visible active activity or not. If it does you could use any of the techniques already suggested without confusing the user about context etc.
If the error/message originates from background code e.g a service, and your application isn't active, a notification is a good alternative. Also, take a look at the guidelines/patterns described on the developer site.
When using a custom dialog in an Android App how is it then possible to let the user know, that he/she has entered a wrong argument, e.g. a wrong password or username?
Possible an AlertDialog or just a Toast_Message?
Thank you
You can add a textview to your customdialog, if the user/password combination fails, you only need to display this textview with the message wanted.
It will be better than AlertDialog, 2 consecutives dialog aren't good for the user. And the toast message are not always understandable for all users.
You can use whatever you want in principle. Flash the screen and all LEDs generate all possible sounds to make the phone R2D2s clone on speed.
On a more serious note. A Toast notification can be used but is not necessarily a good option since it could happen that the users just does not pay attentions and misses the whole notification resulting in a confused user as he is expecting the application to log him in.
Now there is the AlertDialog notification which is probably the most suitable notification type to inform a user about something critical he did or didn't. It requires users attention which is exactly what you want in such cases.
There would be the StatusBarNotification which is meant to display an ongoing process. Best example would be a download or something.
Another option would be an appearing TextView which needs to be distinctive enough to be easily noticed by the user and of course the layout has to be planned to support such dynamic changes.
My recommendation is the AlertDialog and if not applicable for some reason then the dynamic TextView.
Curious what "Toast" means?
Saw this and am curious...
Similar Posts
How to add toast style popup to my application?
Program to show a "toast" notification popup from the Windows command line?
Why does my text keep highlighting?
Thread-safe Form.Show
https://stackoverflow.com/questions/686886/c-remoting-with-forms
Using Jabber to send network messages
Android: determining the current context to display an alert
.NET AnimateWindow
Android toast blur
Can an Android Toast be longer than Toast.LENGTH_LONG?
Why does my text keep highlighting?
A small informational message that pops up like toast.
http://en.wikipedia.org/wiki/Toast_(computing)
It's a type of Window that "pops up" like toast:
http://msdn.microsoft.com/en-us/library/ms632289%28VS.85%29.aspx
An example of a Messenger toast is the message that appears on a user's desktop when one of the user's contacts signs in. Another example of Messenger toasts is the messages displayed when a user receives an alert from the .NET Alerts service. The following are examples of typical toasts:
"Toast" refers to a UI feature where an event causes a small text box to appear at the bottom of the screen. The behavior seems like a piece of bread emerging from a toaster.
It is a popup alert that generally appears on the right hand side of the screen, and is usually for notifications with great importance. There is generally a cool effect with it, such as fading or stretching.
In my question, the toast pops up and fades in.
Toast is just another name for a pop-up notification, a small message that appears temporarily to communicate some information. Pop-ups referred to as “toast” are usually displayed at the bottom of the screen, and in some cases actually pop up like toast:
Photo above from Android Developers: Toasts
Its a kind of notification that is poped up.