Develop Reference

How is Samsung Alarm app able to display a notification-like overlay on top of any screen the last forever?

Basically what's happening here is an overlay being displayed on any screen (meaning it is not a dialog, nor a notification, nor a ui service)
The closest I can think of is a custom toast message, where toasts usually lasts on any screen at any app, but toasts can't last more than 3.5 seconds as shown here
I need to do something like this, since I need the user to be alerted about an incoming order that he needs to be responding to.
Anything close is welcomed

read about SYSTEM_ALERT_WINDOW permission. it will allow you to drawn on screen on top on your/other apps
BUT afaik above perm will let you draw on top other apps, but not covering system GUI. on your GIF sticky widget with timer is drawn also on top of notifications, thats not possible in Android system even with SYSTEM_ALERT_WINDOW. so yet again Samsung (in fact any manufacturer) modified Android and adjusted to own purposes, made some new possibilities and gave proper permissions for own apps... and you won't use them as you don't know/have API and don't have privileges, which you can't even ask for

screen overlay detected when my app loads

I am getting complaints from my customers that when they load my app, they see a "Screen Overlay Detected" alert message from the system. Note that this only occurs on Android M or higher.
The alert looks something similar to below.
http://i.stack.imgur.com/BEGzf.png
From my understanding, this is caused because some "other" app on the device is requesting the "overlay" permission. I've confirmed with my customers that if they remove the app that has the "overlay" permission, then it fixes the problem but is there anything I can do on my side?
Meaning, is there some way for me to inform the system to not allow this alert dialog to be displayed? It's distracting to my customers to see this every time they load my app and it's more frustrating to "me" that there is nothing I can do to fix this.

It seems that you are using a Screen Filtering app(the brownish overlay on the screen). Turn off and it won't bug you.1

Android - Snackbar vs Toast - usage and difference

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.

Sony SmartWatch 2: need to change supportsLowPowerMode() at runtime

I have an app for the SW2 that has a user option for whether the app should use low-power mode (LPM). Which works fine. The problem is that the SW API only calls my app's supportsLowPowerMode() registration method once, when it first starts up. Meaning that if the user later changes the setting in my app, it won't take effect until the whole shebang restarts.
I've tried a few tricks (like killing my app's process) to force a reload, but nothing's worked so far. My last resort is telling the user that s/he needs to reboot the phone before this takes effect, but that's pretty hokey. Is there a better way?

The solution is not to try to change your response to supportsLowPowerMode() at runtime, but to start and stop your extension instead.
Basically, if your extension can ever support LPM, then it should be returning a value of true in supportsLowPowerMode(). If the extension's LPM usage can change, you handle that by simply doing different things in the onActiveLowPowerModeChange() handler. Specifically, if the user has chosen NOT to use LPM, you want a handler that looks like this:
#Override
public void onActiveLowPowerModeChange(boolean lowPowerModeOn) {
super.onActiveLowPowerModeChange(lowPowerModeOn);
if (lowPowerModeOn) {
// User doesn't want to use LPM, so stop the app on the SW
stopRequest();
}
}
This has the effect of shutting down your extension when the device's backlight turns off, and it'll drop back to its default LPM watchface.
EDIT: I'm reopening this as I've found an unacceptable side effect to the above technique. If your app returns false to supportsLowPowerMode(), the SW2 will keep it running (but paused) in the background when the watch goes to sleep. This means that, when the user "wakes up" the SW2, your app will immediately reappear on screen. Calling stopRequest() (as in my code sample above) disrupts this behavior, requiring the user to reopen your app after awakening the SW2. I've not found any way around this; what's needed is a pauseRequest() instead, but the API doesn't have one.

As far as I know there is no way to change this at runtime. Let me double check with my team though just in case there is a way I don't know about.

Best practice for displaying error messages

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.