My android app displays several Toast messages. I recently installed it on a Galaxy S6, running Android 5.1.1 and noticed that the messages are displayed initially around the center of the screen, then they move to proper position (near bottom, if no Gravity is specified), then back to the initial position before fading away.
Context context = getApplicationContext();
String newMsg = getString(R.string.wild_card_msg);
Toast mToast = Toast.makeText(context, newMsg, Toast.LENGTH_LONG);
mToast.setGravity(Gravity.CENTER, 0, 0);
mToast.show();
Update:
I have upgraded support libraries as well as set compile-sdk and target sdk to the latest API. That did not fix the issue
I have removed all .setGravity() calls. No change.
I have noticed that Toast messages behave properly at the first execution after installation (be it in USB debug mode or via download from PlayStore), but the issue reoccurs at (all) subsequent runs.
I have also discovered that my Toast messages disappear immediately if I touch the screen (anywhere). I thought Toast displays cannot be influenced by user interaction.
Anyone else having this issue, know how to fix it or know a workaround?
Please note that I have accepted Nick's answer, proposing snackBar as a workaround.
Your question asked for a fix or workaround. The simplest workaround is (in my opinion) also the best option, because it moves you to using the more modern components: Switch to a snackbar.
Simple Snackbar:
//on a fragment you can simply use getView(), otherwise give it the root view of your
//layout so that the snackbar can use it to find context
Snackbar.make(getView(), "The toast text", Snackbar.LENGTH_SHORT).show();
It's in the support design library for compatibility.
This is a snackbar:
And some of the support / design libraries that can be included in gradle are
compile 'com.android.support:design:23.1.1'
compile 'com.android.support:support-v4:23.1.1'
compile 'com.android.support:appcompat-v7:23.1.1'
It is because of the customized version of Android that vendors deploy with their products, It is true for Activity animations too,
You can achieve the desired behavior on all devices by extending the Toast class and providing your own animation and style or using an open source library for showing toast messages, for activities setting a custom animation for activities creates a constant animation on all devices.
try this simple Toast
Toast.makeText(getApplicationContext(),"Your message", Toast.LENGTH_SHORT).show();
Related
I'm creating a launcher, and in my activity where I host the widgets, I followed this amazing tutorial http://coderender.blogspot.com.eg/2012/01/hosting-android-widgets-my.html (I believe it's the only one out there) and I got to add some widgets to my activity, but not all of them get added successfully, some widgets (As Digital Clock, Dual Clock , etc. etc.) shows a grey bar in their place on my activity with inner message "Couldn't add widget", some widgets as (Netflix widget) appears successfully on my activity for a second or less then it shows the same grey bar in its place with the same message.
I tried to search google but in vein, I even cleared Netflix app cash but still in vein.
I'm testing on Note 3 with Android 5.0 ... Using
compileSdkVersion 26
buildToolsVersion "26.0.1"
compile 'com.android.support:appcompat-v7:26.0.1'
Is there required permissions that I have to add in my AndroidManifest.xml for my activity to host widgets? Could this be the source behind this problem?
Thank you in advance.
I encountered the same issue. This answer is similar to your question.
#dasfima's answer in that question fixed the issue for me:
change the context of the manager and host to be the application context instead of the activity context.
AppWidgetManager = AppWidgetManager.getInstance(getApplicationContext());
mAppWidgetHost = new AppWidgetHost(getApplicationContext(), APPWIDGET_HOST_ID);
It works like a charm in my application.
Is there any way to assure that my application's window is not obscured by any other application's view using with SYSTEM_ALERT_WINDOW permission?
If not, then is there any better way to assure that my app is not obscured by such window apart from obtaining the same permission and refreshing/showing/whatever my own view (of course shown in alert window) every 100ms or so to keep it visible?
Eventual flickering, in case my application is obscured, is actually a good thing and an indicator to the user that something is wrong.
EDIT: It seems that there is no way to do it except from going through KNOX on Samsung or some other proprietary solution for Trusted UI. Accepted answer is enough for my purpose, but it is not an answer for the question asked.
Even if it's not exactly what you're asking, the closest replacement I know of is:
Either setting android:filterTouchesWhenObscured="true" in your layout (touch events will be filtered and not reach your View if they are going through an overlay, regardless is transparent or opaque). See View#setFilterTouchesWhenObscured(boolean),
Or overriding View#onFilterTouchEventForSecurity(android.view.MotionEvent) and checking for FLAG_WINDOW_IS_OBSCURED. See View#onFilterTouchEventForSecurity(android.view.MotionEvent).
Later can be implemented like so:
override fun onFilterTouchEventForSecurity(event: MotionEvent): Boolean {
if ((event.flags and MotionEvent.FLAG_WINDOW_IS_OBSCURED) == MotionEvent.FLAG_WINDOW_IS_OBSCURED) {
Toast.makeText(context, "Screen overlay detected!", Toast.LENGTH_LONG).show()
return false // touch event is cancelled
}
return super.onFilterTouchEventForSecurity(event)
}
See also the Security section of View class documentation.
Notice that this functionality is available from API 9+. A workaround for older APIs can be found in this SO Question: Analogue of android:filterTouchesWhenObscured for API level below 9.
I have just started developing an android weather app and I was wondering how to change activity background automatically. For example, in daytime it should show day time or in the night it should show night photos.
This is the app of Sony which has a feature (mentioned above)
Check the screenshots.
Okay Credit goes to SteD;so for you check this(beginner's guide)
Follow this
//set an ID for Relative Layout in content_main.xml(Android Studio)
RelativeLayout rlayout=(RelativeLayout)findViewById(R.id.rlayout);
if(something){Drawable drawble=getResource().getDrawable(R.drawable.your_image);rlayout.setBackgroundDrawable(drawable);}
//If it works,destroy the upvote
The only automatic way is the newly released (Day/Night theme for android app)
For finer control you check the condition yourself and call the normal Java methods, like this:
if(something) {
getWindow()
.setBackgroundDrawable(ContextCompat.getDrawable(this, R.drawable.image));
}
of if you don't care about the newly introduced context themed styling, you just call the deprecated method (which will keep working without issues for all the foreseeable future)
if(something) {
getWindow()
.setBackgroundDrawable(
getResources().getDrawable(R.drawable.image));
}
I'm building an Android Wear app and trying to implement BoxInsetLayout for round screens. In my code, I want to detect if the device is round or not, so I'm using BoxInsetLayout's isRound() function, but it always returns false, even on the Moto 360.
Anyone know if there's a way to programmatically tell if the device is round?
The problem may be caused by calling isRound() at the wrong time. The round-ness is determined by the WindowInsets being delivered to the BoxInsetLayout. If you call isRound() very early before the insets have been delivered, you will get the wrong answer.
So if you have a "box" object which is the BoxInsetLayout, you would do this:
box.setOnApplyWindowInsetsListener(new View.OnApplyWindowInsetsListener() {
#Override
public WindowInsets onApplyWindowInsets(View view, WindowInsets windowInsets) {
// Need to also call the original insets since we have overridden the original
// https://developer.android.com/reference/android/view/View.OnApplyWindowInsetsListener.html
box.onApplyWindowInsets(windowInsets);
// You can make calls to detect isRound() here!
// Return the insets so the BoxInsetLayout still works properly
return windowInsets;
}
});
Can you please send us the code related to the BoxInsetLayout that you are using?
According to Wayne answer on G+ it is a bug, for now we know what causes it, how to avoid it but only if user is aware of that, but fix for it is not released (yet).
https://plus.google.com/108847189842978537754/posts/5YiYb14i7ss
Quoting as post might be deleted/changed:
The problem is triggered by the watch switching languages when pairing with a phone after a factory reset. You can avoid the issue by
selecting the same language on the wearable as you are using on the
phone, so that no change occurs afterwards when the devices are
paired.
Instructions to fix the problem:
Factory reset the Moto 360.
When the wearable restarts, it will ask what language you would like to use. Select the same language that you are using on the phone
(do not select the default of English)
On the phone, start the Android Wear companion app, and select from the overflow menu the option "Pair with a new wearable".
Pair the phone with the Moto 360.
EDIT:
Using setOnApplyWindowInsetsListener (suggested by Wayne) I created small class that simplify using it a bit. https://github.com/tajchert/ShapeWear
Just copy ShapeWear.java class, and subscribe to screen shape detection event setOnShapeChangeListener() or call method ShapeWear.isRound() (can throw error is shape is not yet determined) or ShapeWear. getShape() - which can result in ShapeWear.SHAPE_UNSURE in same situation.
I developed my app using Mono for Android. I have the latest version 4.0.3. My AndroidManifest.xml specifies:
<uses-sdk android:targetSdkVersion="11" android:minSdkVersion="8" />
The app runs on tablets, so in Honeycomb I need to hide the status bar at the bottom of the screen. This is how I do that (with a simple extension method):
internal static void LightsOut(this View view)
{
try
{
IntPtr view_setSystemUiVisibility = JNIEnv.GetMethodID(view.Class.Handle, "setSystemUiVisibility", "(I)V");
JNIEnv.CallVoidMethod(view.Handle, view_setSystemUiVisibility, new JValue(1));
}
catch
{ }
}
I call this on every view that I instantiate. On my Motorola Xoom, running 3.0.1, this works great.
On my Samsung Galaxy Tab running 3.1, it works; but the status bar comes back after some short period of time. In the Android Log I see that LightsOn() is getting called...
How can I prevent the status bar from coming back in 3.1? I saw this event:
http://developer.android.com/reference/android/view/View.OnSystemUiVisibilityChangeListener.html
And thought I could use it to hide the status bar, if it comes back. But I don't see how I can subscribe to it (it doesn't show in Intellisense).
Does something specific happen before the status bar comes back, or is it solely time related? A quick search of the ICS source suggests that the status bar status will be reset when the top App Window changes. Are you calling StartActivity() or moving to another app when you see this behavior?
The View.OnSystemUiVisibilityChangeListener interface has been bound as the View.IOnSystemUiVisibilityChangeListener interface and through the View.SystemUiVisibilityChange event. However, both of these mechanisms require that your $(TargetFrameworkVersion) target Android v3.1 or later, which would set your //uses-sdk/#android:minSdkVersion attribute to 12, and is thus something you (presumably) don't want to do.
I see two plausible solutions here:
Figure out why LightsOn() is being invoked and try to work around it (call LightsOut() within every Activity.OnCreate() method?).
Provide two versions of your app, one with a minSdkVersion of 8, and one of (at least) 12, and then use Multiple APK Support to include both in your program. The device will then run the appropriate package, permitting access to the View.SystemUiVisibilityChange event.