-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
isApplicationBroughtToBackground doesn't work as advertised #35
Comments
Yes, that's true. I will probably remove this method from the library at some point, it also doesn't work with custom launchers like ADW (for the same reason.) Better not use it at all, it's a pretty old leftover from the former Droid-Fu library. We used it to detach location listeners when the users leaves the app, and since customization in terms of custom home screens wasn't that commonplace back then, it did the job. We don't use it anymore in our app either. |
Actually, forget what I just said. The problem I mentioned with the different home screens was already fixed (that method actually used to check for Android's launcher package explicitly to determine if the user arrived at the home screen). But your point remains of course. |
And another problem with this method is that it requires an extra permission, and it's a permission that's difficult to communicate to the user why you need it. |
HI Matthias, thanks for the reply. I totally understand that you may not want to bother with this method. The trouble is, this method seems to be referenced all over the internet as a way to distinguish a home button press vs a back button press. I was hoping that droid-fu could be updated to save some people some pain, but since this project has superseded droid-fu, I filed the bug here. Do you still intend to remove the method altogether? |
Just so you know, a few months ago a customer let us know that Google refused to feature their app while the GET_TASKS permission was used. We had to find a different approach. So that is more evidence that this is not the correct approach. |
Hi there. I ran across this method on Stackoverflow, and decided to use it. But it turns out it doesn't always work as advertised. Specifically, in the case where I have defined an extra Activity in my Application with a different package than the Application. Because you are comparing packages, isApplicationBroughtToBackground() will return true when I launch this child Activity. My solution checks to see if the new topActivity is defined in the current Application. If not, returns true:
If you want this, I'd be happy to submit a pull request.
The text was updated successfully, but these errors were encountered: