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.
Related
I want to try to make an Android alarm app that is impossible to stop. In other words, it keeps going for a predetermined amount of time, even if the user presses the power button, tries to reduce the volume, or anything else.
It does not seem feasible to me, but since I have very little Android experience, I'd like to know if something like that is theoretically able to be done. Thanks.
This question has been addressed on SO here: Override Power button just like Home button
.
There are several answers in the link that will give you options and get you 90% of the way there, but no answer will cover all devices/scenarios. The accepted answer in the link puts it best:
The Android system, as far as is documented, defines (a physical button press) as a
broadcast action. Following the publish-subscribe pattern of message
propagation, this message will notify all concerned parties of this
action. Because this message is sent by the system, because the
message stack is managed by the system, and because the message is
also received by the system, your code simply (cannot be) injected in the
right place to block the reception of this message.
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.
Trying to replicate what Google Voice on Android does. Specifically you dial a number in the dialer, in this case 123-456-7890. Google Voice intercepts the call in a BroadcastReceiver, and reroutes it to a "shadow number (in this case 1-916-538-1453). However it manages to keep "1234567890" as the destination number and displays custom text in the blue box that comes down and then disappears. Does anyone know how you would do this?
After doing more research on this topic and asking people that have worked on this in the past, I have determined that this is basically impossible. As Chris mentioned in the comment, it comes down to having your app be signed with the Google key in order for it to work. The best workaround is to display a toast (possibly custom toast) showing the custom text and the original number and then rewrite the call log to display the correct number.
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.
I have an android app which needs to keep sending SMS. My problem is that whenever we send a message we get a pop up showing (your SMS charges and your curent talktime balance in phone). When i send many SMS these pop ups keep getting accumulated one over the other which is undesirable for me. I need a way out to either remove or somehow consume these pop ups.
Any ideas ??
a pop up? Do you mean a toast? or notifications accumulating below the status bar?
You'll have to pardon my seemingly simple question. In the US, I've had multiple Android phones on at least two carriers, and I don't get any such message in any form, but may be that's because I've always had unlimited texting so additional texts do not cost me anything.
I bet you're talking about notifications accumulating in the status bar. So if your carrier is doing that, take a look at the code in the "API Demos" > App > Notification > Status Bar
There in the callback attached to the "Clear Notification" button, you'll find the code you're looking for.
And if I could suggest something, I know that many notifications accumulating on top of each other can be super annoying, but if you can try to consolidate all those notifications into one notification at least with the running count (unless your user explicitly opts out from being notified). This way, you still communicate to the user the most important part of the information - how many texts in total his phone has been sending so far, without completely overwhelming him with many-many notifications about basically the same event happening over and over again.
For those who don't know, "API Demos" is a free application you can download from the Market. And there may be several to choose from, so just pick the one with five stars next to it, but "API Demos" is also the same sample code that comes with different SDKs when you download it with the SDK Manager, and you can access that code when you create a new Android Project with the New Android Project... wizard from within Eclipse and then select the radio button "Create Existing Project from Sample" (or something like that, I don't have Eclipse in front of me, so the wording may be slightly incorrect). And of course, if you don't use Eclipse, you can always find that sample code through the Sample code directory itself.
As a potentially more elegant alternative, or may be just in case your carrier is indeed crude enough to pop up an actual modal dialog every time a text is sent, it may be that your carrier is using a broadcast receiver to trigger those notifications or those dialogs, so if that's the case, and hopefully the carrier isn't using "100" as a priority for its receiver, it may be possible for you to register a receiver with "100", and then kill the broadcast before it propagates to the other receivers. But of course, that's assuming that your carrier designed it that way for you.