Quirk in Requesting Permissions in Groups

Marshmallow brought runtime permissions to the Android world, and by now most apps have started requesting their permissions at runtime instead of install time (you have, right?).

Permissions are grouped into buckets like "location" or "storage" to simplify the explanation of what a permission does for users. Hopefully this is all old news to you.

However there is an interesting situation that merits a little more explanation. Let's say your app currently requests ACCESS_COARSE_LOCATION. Your requirements have changed a little bit, and you now need ACCESS_FINE_LOCATION. What happens might not be quite what you expect.

The documentation provides this note:

Note: Your app still needs to explicitly request every permission it needs, even if the user has already granted another permission in the same group.

So we know we need to request the new fine location permission. But what does the user see?

If the user has not accepted ACCESS_COARSE_LOCATION

If a user hasn't accepted the coarse location permission (and hasn't said "don't ask again"), your app behaves as you would expect it to on a fresh install. You can request the permission as usual and go on about your day.

If the user has denied ACCESS_COARSE_LOCATION

If your user has denied the coarse location permission and selected the "never ask again" option, you will not be allowed to ask for either permission. This is also generally what I would expect- the user clearly doesn't want you using their location, so you don't get the opportunity to ask again.

If the user has accepted ACCESS_COARSE_LOCATION

Here's where it gets a little more interesting.

  • If your user goes into the app's settings page to look at the permissions, they will see that the location toggle is already "on.
  • If you check for the fine location permission with checkSelfPermission() you'll still get PERMISSION_DENIED.
  • If you request ACCESS_FINE_LOCATION with requestPermissions(), you will automatically get a callback to onRequestPermissionsResult() with the fine location permission granted. This is transparent to your user- they will not see a dialog.

Summary

If your app already requests a permission in a particular permission group, you still need to explicitly request all other permissions in that group that you want to use. However, if your user has already accepted one of the other permissions in that group, they will not see another permission request dialog.

The Many Flavors of Commit()

FragmentTransaction in the support library now provides four different ways to commit a transaction:

  • commit()
  • commitAllowingStateLoss()
  • commitNow()
  • commitNowAllowingStateLoss()

You have probably also encountered one of these alongside a call to executePendingTransactions(). What do each of these do, and which one should you be using? Let’s explore each one in more depth and find out!

Read the full article on Medium ›

Managing the Fragment Back Stack

Or: A lesson in not fighting the framework

The Android framework provides simple APIs for managing your back stack without headache for most simple applications. However at some point you are likely going to run into a situation that doesn’t quite fit the mold of a an application with a simple back stack.

Learn about some of the Fragment APIs you aren't familiar with for some strategies on how to better work with the framework.

Read the full article on Medium ›

Android Barcode Scanning Library Landscape

There are a few different barcode scanning libraries out there right now and I will provide an overview of the three most popular options out there right now- ZXing, ZBar, and Google’s Mobile Vision API. This is a qualitative look at these libraries, so I won’t attempt to provide benchmarks.

What we have found is that there isn’t a single clear winner right now. Each library has at least one major drawback. Selecting a library for your project requires knowing the relative strengths and weakness of these libraries so you can pick the one that best fits your use case.

Read the full article on Medium ›

Fragment Transitions with Shared Elements

One of the cornerstones of Material design is meaningful motion between screens. Lollipop introduced support for these animations in the form of the transitions framework, which allows us to animate transitions between Activities and Fragments. I haven’t seen many articles on how to use transitions with Fragments, so I set out to write one!

Read the full article on Medium ›