5 tips for preparing your application for multiwindow mode in Android N

And you don't even need an API from Android N!

If you’ve recently watched a video entitled “What's new in Android N,” then you may have already thought about supporting multi-windowing .



Multi-windowing will work in split screen mode, which means that two applications will be on the screen at the same time, side by side. To understand how this magic works, I immediately went through the documentation in search of new APIs.
')
It turns out that they are not so much. Several XML attributes that indicate whether you are going to support multi-windowing at all, and several Activity methods that let you know if your application is currently running in multi-window mode. And where is the magic? Magic has always been here forever .

And by magic is meant Android’s resource system . One of its most powerful parts is the ability to provide alternative resources — resizing, layouts, drawables, menus, and so on, depending on various qualifiers.

Multi-window support is based on system resources in the sense that when an application switches to multi-window mode, configuration parameters change related to the size of the area in which the application is drawn. An obvious example of such parameters would be the screen size, a little less obvious, but the least width (i.e. the minimum between the height and width of the screen) and orientation will also vary.

And that brings us to the first advice.

First tip: Use the right context.

Loading the right resources requires the right context . If you use the Activity context to get resources, create a hierarchy of widgets on the layout file, and so on, then you are fine.

But if you use the context of the application for what is suitable, associated with the graphical interface, then you will find that the loaded resources are in blissful ignorance about the multi-window. In addition to the problems associated with the fact that you are not using the theme of your Activity , sometimes you will also download absolutely the wrong resources! Therefore, it is best to use the Activity context to load the resources required by the UI.

Second tip: Correctly handle configuration changes.

Using the right context, you can accurately load the correct resources, knowing the current screen size (regardless of whether your application is in full screen mode, or sharing the screen with someone else). The process of reloading the correct resources is based on how you reverse configuration changes .

By default, a configuration change happens like this: all your Activity destroyed, and then re-created, restoring all the data that you saved to onSaveInstanceState () , and reloading all resources / layouts. At the same time, you know for sure that everything that is needed will be consistent with the new configuration, and that each type of configuration is processed.

It goes without saying that every configuration change should be quick. Make sure that you do not do a lot of work in onResume () , and think about using downloaders to ensure that your data is saved and restored when you change configuration.

But you can also process the configuration change yourself - in this case, your activations (and fragments) will not be destroyed. They will call the onConfigurationChanged () method, in which you will need to manually update your widgets, reload resources, and so on.

To intercept configuration changes related to multi-windowing, you will need to add the android: configChanges attribute to the manifest with at least the following values:

 <activity android:name=".MyActivity" android:configChanges="screenSize|smallestScreenSize|screenLayout|orientation" /> 

Make sure that you are processing every resource that may change (in fact, you should do this if you decide to handle the configuration change yourself).

This also applies to reloading those resources that you previously considered constants. For example, you have a resource denoting a size (dimension) defined in values ​​and values-sw600dp. Before the appearance of multi-windowing, you would not switch between these two values ​​while the application was running, since the smallest width never changed (it would always be equal to the smaller of the two dimensions of the screen of your device). Now you can and should switch between these resources after resizing the area in which your application is drawn.

The third tip: work with all screen orientations

Remember how at the very beginning we discussed the change in orientation that occurs when the window is resized? Yes, yes: even if the device is in landscape mode, your application may be in portrait orientation .

Everything is very simple: the “portrait” orientation means that the height is greater than the width, and the “landscape” orientation - on the contrary. Thus, your application can really switch from one orientation to another when switching to multi-window mode.

It also means that the transitions between orientations should be as smooth as possible. We quote the section of the material design specification devoted to the screen splitting mode :

Changing the orientation of the device should not lead to unexpected interface changes. For example, an application that plays video in one of two screen halves (in portrait mode) should not go into full-screen video playback if the device switches to landscape mode.

Note : if you still need to implement this behavior when your application is in full screen mode, you can use the inMultiWindowMode () method to find out which mode you are in at the moment.

Multiwindow also affects the ability to rigidly set the screen orientation attribute android: screenOrientation . Using this attribute in applications that do not support Android N (for which Marshmallow or lower is registered as targetSdkVersion ) means that you will not support multi- targetSdkVersion - the user will always be thrown out of multi-window mode. If you decide to support Android N, then the behavior will change: the behavior of the android:screenOrientation will be ignored if you switch to multi-window mode.

Do not forget also that the attempt to fix orientation through setRequestedOrientation () will not have any effect in the multi-window mode whether you support N or not.

Fourth tip: create a responsive interface for all screen sizes

When designing a design taking into account the possibility of a multi-window mode, it is necessary to take into account not only the screen size . Multi-window mode is the first time that the interface you have created for a tablet (you have one, right? Do not forget, 12.5% ​​of 1.4 billion devices are many devices ...) will shrink to miniature sizes.

If you designed a responsive interface that is not tied to a specific screen size, and whose layouts for phones and tablets are relatively similar to each other, then you are already well prepared for multi-windowing. In general, there is a good recommendation on how you can prepare for future changes: imagine that only 220dp is available for you in height / width, and consider the rest of the space as additional, which may not be the case. And redo the interface with this restriction.



But, if your interfaces for the tablet and the phone diverge greatly - do not blast the brain between users by switching between the two - leave the interface for the tablet, and try to reduce it so that it becomes applicable in the case of the phone. There are several templates for building responsive interfaces that you can use to make resizing inconspicuous to users, and for this you do not need an API from Android N.

Fifth tip: Activity launched by other applications should always support multi-window operation.

In the multiwindow world, your task is represented by one window. Therefore, if you want to start an adjacent Activity , you need to start a new task - a new task, a new window.

And the reverse is also true, we quote the same page:

If you launch an Activity in an existing task stack, a new Activity replaces an Activity that is on the screen, inheriting all its multi-window properties.

This means that if you have an Activity that can be launched by other applications, then it will inherit the multi-window properties of the Activity that launched it at startup. Including the minimum size. In the case of startActivityForResult (), your Activity will become part of the same task stack, and even if it is launched through an explicit Intent , there is no guarantee that it will be launched with the FLAG_ACTIVITY_NEW_TASK flag.

Thus, each of your Activities that can be launched from other applications (as well as activations launched from your activites) should support multi-windowing, down to the smallest screen sizes. Test carefully!

I repeat: test!

The best way to prepare for multi-windowing is to test your application. Even if you don’t immediately rewrite your code, or install the Android N SDK, but simply put your application on an emulator, or a device with Android N, you will take a big step forward to make your applications better.

Sign up for the Android Development Patterns Collection if you want to learn more!