Skip to content
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

Open
skykelsey opened this issue Aug 3, 2012 · 5 comments
Open

isApplicationBroughtToBackground doesn't work as advertised #35

skykelsey opened this issue Aug 3, 2012 · 5 comments

Comments

@skykelsey
Copy link

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:

public static boolean isApplicationBroughtToBackground(final Activity activity) {
  ActivityManager activityManager = (ActivityManager) activity.getSystemService(Context.ACTIVITY_SERVICE);
  List<ActivityManager.RunningTaskInfo> tasks = activityManager.getRunningTasks(1);
  if (!tasks.isEmpty()) {
    ComponentName topActivity = tasks.get(0).topActivity;
    try {
      PackageInfo pi = activity.getPackageManager().getPackageInfo(activity.getPackageName(), PackageManager.GET_ACTIVITIES);
      for (ActivityInfo activityInfo : pi.activities) {
        if(topActivity.getClassName().equals(activityInfo.name)) {
          return false;
        }
      }
    } catch( PackageManager.NameNotFoundException e) {
      return false; // Never happens.
    }
  }
  return true;
}

If you want this, I'd be happy to submit a pull request.

@mttkay
Copy link
Owner

mttkay commented Aug 3, 2012

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.

@mttkay
Copy link
Owner

mttkay commented Aug 3, 2012

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.

@mttkay
Copy link
Owner

mttkay commented Aug 3, 2012

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.

@skykelsey
Copy link
Author

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?

@skykelsey
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants