App Development

Android N's Multi-Window Mode and isTablet

With Google I/O kicking off today, now is a great time to discuss Android N’s multi-window mode (a feature we learned about from Google’s Android N developer preview earlier). It’s a really cool new feature, but it breaks some assumptions that have held in Android since the beginning. One of these assumptions is that the screen size will never change. Because of this, you may need to re-evaluate how you check if you’re running on a tablet or phone. We would previously check this by putting a boolean attribute in sw600dp. This now may not be reliable because the app may not be occupying the full screen of the device. There are two use cases for isTablet() that need to be considered and handled differently.

For Layout

sw600dp should still work fine for layout. If you only care about how much space your app has available, sw600dp will work great and still report the expected value in multi-window mode. You want your app to use the phone appearance even on a tablet when it is only taking up a fraction of the screen. One important caveat is that you must not cache this value. Unlike previous versions, it may change on configuration changes and you need to be prepared to handle that.

For Analytics

If you want to know what kind of device your user is using, sw600dp will no longer work. Your users don’t suddenly switch from using a tablet to a phone just because they enabled multi-window. Instead, you must obtain this information at runtime, and there are a few potential ways to do so.

You may think the way to do this is activity.getWindowManager().getDefaultDisplay().getSize(). However, as per the documentation: “The size returned by this method does not necessarily represent the actual raw size (native resolution) of the display.” And in fact, getSize() will only return the size available to your window, not the actual device. Instead you need to use activity.getWindowManager().getDefaultDisplay().getRealSize() which will report the actual size of the device.

However, this method has a couple of drawbacks. First, it’s only available since API 17. Before API 17, you can fall back to getSize() since you know your app will take up the entire screen. The other drawback is that getRealSize() requires an activity context which you may not want to require when writing your analytics code.

There is one more way to get the device size that doesn’t have those downsides: context.getResources().getDisplayMetrics(). widthPixels and heightPixels. These properties will be the size of the entire screen regardless of whether your app is in multi-window mode or not. And you can obtain these values with your application context instead of an activity context. With these values, you can check if the minimum width is at least 600dp and determine if you’re on a tablet or not.

 * Returns if the screen size smallest width is at least 600dp. Note: this makes no guarantee
 * about the amount of space the app actually has and should only be used for analytics, not layout.
public static boolean isTablet(Context context) {
    DisplayMetrics metrics = context.getResources().getDisplayMetrics();
    int smallestSize = Math.min(metrics.widthPixels, metrics.heightPixels);
    int tabletSize = (int) TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP, 600, context.getResources().getDisplayMetrics());
    return smallestSize >= tabletSize;

Moving from Monolith to Microservices Architecture

When a client decides to move from a monolith platform to microservice architecture,...

Read the article