I feel like an idiot for having to ask this question, but I have no idea what a slider interrupt is on Android, and a search of Google and Stackoverflow turned up nothing. Amazon sent me a rejection notice for my app because all of the activities except the main one (which they call, "pop up windows") do not respond well to a slider interrupt. I have no seekbars anywhere in the app, so that isn't the "slider" that they are referring to.
Also, one of the views in question isn't a new activity at all, but a listview. It disappears on a "slider interrupt." As far as I know, I have no control over what a listview dialog does in this case. Once I figure out what a slider interrupt is, how do I tell the listview not to close when it happens? I suppose I could track whether the listview is open and recall in onResume or whatever function handles slider interrupts. But without knowing what a slider interrupt is, it makes testing difficult.
I had the same problem with Amazon. I filed a ticket and here is the response:
A slider interrupt occurs on devices with a flip-out keyboard. While the app is running the keyboard is flipped out.
Related
I want to trigger the default swipe animations on Android when a swipe gesture occurs, without changing the currently displayed Activity.
The point of this is that I want to simulate that the Activity has changed when an important event occurs in my Activity.
The questions I've seen on the Internet all relly on changing the Activity, Fragment, View ,etc.
I wonder if this is possible. Thanks in advance
This is not possible as far as I know. Google would generally be against allowing such behavior through purely their libraries as it does not follow Android ui patterns.
I would like to display a message to the user for some asynchronous event. For example for an alarm expiration. I would like to display a popup or dialog that is displayed over any activity is the foreground at the moment (and this can be some other application activity) leaving the current activity in the backgound.
Is there a way to do so in Android?
First off, you will be told that this is a bad thing to do, that it is against the Android way of doing things. Users do not like this. And that the Notification area is much better way to do this.
That said... there are ways to accomplish this...
A Toast will display no matter which activity is on the screen. So you could set up a background thread (or better a Service) that will display your information in a Toast. This might be good enough for you.
You may find it useful looking at some Toast source code here.
Also here is a nice page on how to create a custom Toast layout by replacing the default View with one of your own. (I have not done this, but it looks quite interesting):
Custom Toast Alert on androidexample.com
The alternative is much more difficult, and is to display a System Overlay window. Unfortunately you have to do quite a lot of work to get these set up properly.
Here are a few related questions that I used to get it working:
Creating a system overlay window (always on top)
System overlay android 4.0
How to create a system overlay in Android which allows interaction with the windows below it?
Each of these has links to many others - there are loads of System Overlay questions on here.
But things to remember:
In the old days, you could put a system overlay on top, and send
touches through to the activity below. This is no longer possible,
and so a lot of the answers are now out of date.
You may need to
play around with the flags in the provided examples to get exactly
the effect you are aiming for. Not all the examples use the same
flags, so there are some subtle differences in how each solution
works.
Then again, I also believe that the Notification area is a much better UI pattern to use, so I do recommend you try that first. It is easier to do, and most of us expect that type of behaviour rather than a pop-up.
The problem with a pop-up, is that it might interrupt a movie I'm watching. Or a game I'm playing.
Yes, i had created two dialog for income event for background and foreground
I've been building for Android for six months now, and I'm still confused about how things happen in the UI. When I learned iOS programming, the books and docs were very clear about what happened when: for instance, that view changes and animations didn't take effect until the next iteration through the run loop. This understanding is critical to debugging UI glitches, and without it I'm having trouble tracking stuff down in our Android app (http://emu.is/download/).
For instance:
We had a situation where pressing a button brought up a fragment, and also displayed an animation as feedback for the button click. I started the animation before pulling in the fragment, yet it didn't actually run until after the fragment appeared. Why?
Often, opening a new Activity will take a long time, during which the user doesn't have great feedback that anything is happening. I'd love to pull up a minimal container for the Activity, then load its content, so the user knows what's happening. How do I do that?
Sometimes our chat bubbles (which are drawn programmatically via a custom Drawable) flash a bit, and it looks like they're being rendered halfway through their drawing process. Why? How do I avoid that?
And so forth. Basically I'd like to understand as much as possible about what happens when in the Android UI -- not just the lifecycle stuff that's well-documented, but the relationship between various UI calls and when/how things actually happen onscreen. Thanks.
My initial question dealt with building a translucent view that allowed manipulation of a view below it. Bluefalcon did an excellent job answering this and helped me understand view mechanics a little better:
How can I interact with elements behind a translucent Android app?
I'm still unsure of how to manipulate an underlying view that is not part of my app. The effect I'm trying to achieve is like the Screen Filter App:
https://play.google.com/store/apps/details?id=com.haxor&hl=en
In this app, once started, it seems a "filter" view is placed on top of everything but you can still interact with whatever is running under it. The app store, email, home screen etc.
I currently have getWindow().addFlags(WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE); in my app's onCreate method. This seems to get close. If I swipe on my app nothing updates, but when i back out of the app the home screen updates as if i swiped.
Any help will be greatly appreciated!
I am looking for some help, not being spoon feed source code (which from some of the threads I have read on this forum wouldn't happen anyway). I am really just wanting to know if what I have conjured up in my head is even possible or not, and if it is if I could get pointed in the right direction. So, I am looking to add a "view", doesn't really matter what type the concept would be the same for all of them, to appear when receiving or placing a phone call. You know the one that has the little droid waving at you or a photo, etc. The only thing is that I would only want like the top 30px to be this "view".
For instance, you receive a phone call and at the top of your screen on top of the receiving call window is a TextView with a note about this person (i.e. - he stinks).
The only thing I have been able to come up with so far is that I would have to bring up a layout that was either invisible or gone, but have yet to figure it out as of yet.
Am I barking up the right tree or do I need to find a different tree to sniff. Any and all help would be appreciated.
I honestly don't know the answer to this, but if it were possible then presumably you would have to have your own custom Activity launch in response to an incoming phone call event. This Activity of your own would replace the standard system phone application. So I did a search on here and the most vaguely related previous questions I could find within a short time are these:
Is it possible to write a new "phone" activity, and if yes then how?
Launch an activity at end of a phone call on Android
Answers on those seem to suggest the phone would need to be rooted before you could replace the standard phone app for receiving calls.