November 29, 2016 at 16:11Features of multi-window mode on Android tablets
Hello! In this article I want to tell you what problems can arise with the advent of multi-window mode on tablet versions of applications. Live Typing’s Android development team came across them when they adapted the IL DE BOTE app to their tablet. Be prepared for the same problems you will have.
As you all know, Android 7.0 was released at the end of August 2016, and one of its main features is multi-window support. This is a great feature that takes the convenience of Android to the next level. All users will be in seventh heaven, but what is happiness for the user can turn into a pain for the developer. Unfortunately, this is exactly what happened with multi-windows on tablets. And it’s on the tablets - on the phones, everything is fine with her, I say in advance.
If you are making tablet versions of applications or you are not indifferent to multi-window mode, then welcome to the article!
Suppose you are a developer who unexpectedly decided to make multi-window support in a phone application. You did everything right, you set it up to a width of 320dp, and in general you are great, and, fortunately, the mode works just fine. Even if you’re not very well done, because you didn’t make support for small screens and made up for 360dp or 480dp, everything still remains in order. The worst thing that can happen to you is that the layout will float a little, or in some places the text in the button will not fit on one line. But let's be honest that these are all trifles. A couple of hours, maximum a day and voila, PROFIT! You are well done again and you can add new multi-window features to your application.
But what if you have not only a phone version of the application, but also a tablet?
You will have problems. Perhaps a pretty big problem. Even, perhaps, the problems will be so huge that you will have to radically change the architecture of the application.
For simplicity, let's imagine that we have a layout for phones and a layout for 10-inch tablets. We will consider everything using the layout example, that is, our resources will lie in the following folders:
Let's start with the vertical orientation. Our application can occupy either the entire screen, and layout from swap-sw720dp-port will be used:
Either half the screen, and resources will be taken from layout-land:
Or a third or two-thirds, and resources will be taken from layout-land and layout-sw720dp -land accordingly:
you expect that in landscape mode, land and port will simply swap places, but no. Everything is a bit wrong.
If the entire screen is busy, then layout-sw720dp-land is used:
If half the screen, then layout-port:
If a third or two-thirds, then layout-port and layout-sw720dp-land, respectively:
We figured out the location. Many, probably, already begin to realize possible problems, but let's take it one after another. First, imagine that you made an abstract application that works perfectly on Android 6, but which has problems on Android 7. Please do not quibble in advance about how it is thought out, because it is thought out so specifically to demonstrate possible problems.
So, let the application be news and has three main entities: category, subcategory and news. The phone version can only be in portrait orientation and has three screens, each of which is a separate Activity:
For the tablet, everything is arranged a little differently: there are only two screens, which are also Activity:
The application has MVP architecture and each screen has Presenter and View. A custom ViewGroup like this is used as the View . For the main screen and the news list screen, completely different View and Presenter are used. The news screens on the tablet and on the phone are absolutely identical to each other in logic, but due to the large differences in the visual part, we need more than just different xml. Therefore, the implementation of View is organized as follows: the abstract class NewsView, which contains all the common and inherited from it classes PhoneNewsView and TabletNewsView.
Now let's take a little more imagination and imagine that we launched our application on a 10-inch tablet running Android 7 and turned on multi-window mode.
Presented? Let's see what happened.
It doesn’t look very, but all because earlier in the phone version you did not support landscape orientation. Therefore, he takes resources from shared resources. Although in principle everything is cool, the banner pulled a little, but these are trifles. To celebrate, you poke on the first subcategory that comes across and get to the news list screen, which is also not so bad.
Joy over the edge, and then it dawns on you: “What will happen if I re-deploy the application and go to the layout of the tablet? After all, this screen should not be in the logic of work on the tablet. " Well done, you are a very correct thought. The following will happen: you will see a screen that should not be here. Moreover, you will be shown his phone version, which will ruin the appearance.
What solutions are there? Well, for example, you can redo everything into fragments, put them on top of each other in the phone version, and next to it in the tablet version. Profit! But do not forget that this is easy to do only on our small abstract application, and in a real application you will have to make a lot of effort. Also, your application may have confused navigation that cannot be implemented using fragments due to the fact that they cannot save the state of their child fragments.
Suppose you redid our abstract application into fragments, but then remember the unusual features of the tablet - the ability to show all the news in all subcategories of any category.
What to do? You will have to add this functionality to the phone version, or remove it from the tablet. As you know, in real life there can be a lot of such functionalities, and most likely it will require a lot of you, a lot of coordination, which ultimately will result in shreds of torn hair and full glasses of bitter tears. It's good that in our small abstract application there is not much of it, otherwise we would have to sweat.
Everything seems to be fine with the list of categories. You have debugged and fixed everything, you are definitely well done. You go to the separate news screen and try to switch to multi-window mode, but - oops! - the application crashed. What is the matter? And all because your PhoneNewsView and TabletNewsView have the same id. It turns out that onSaveInstanceState is done for one class, and onRestoreInstanceState is already for another.
How to get around this? You can simply set them with different id, but here the problem immediately arises with maintaining the state when changing the multi-window mode, namely, that it will not be. There is a way out: to do everything so that the code does not have any differences between the tablet and phone versions, except in XML. If there is an urgent need to add some new element to the tablet, then it is better to just check it for null and only then do something with this element.
You brilliantly dealt with this problem, congratulations. Then you suddenly remember that on the same screen, in the phone version, right below the picture of the news you read "If you have a tablet, then try our tablet version." Awful Well, in fact, in comparison with the previous problems, these are just flowers, but still unpleasant.
In general, this is not problem number 4. I just wanted to tell you how to take tablet resources, if the application, in theory, should take phone resources.
So what to do? If you take resources from Application in multi-window mode, it will return them for the tablet; if from Activity, View, Fragment and everything else that is not Application, it will return for their size. That is, if you divide the screen in half, then Application will return the tablet resources, and everything else - telephone. I think this is due to the fact that, in theory, one application can be divided into several windows. Maybe many have come up with a tricky plan - to do setContentView in Activity not by id, but by the "view" that you pre-inflated with Application. BUT! Doing so is not worth it. Otherwise, your application will look like this:
With Application, you have resolved the dilemma with an unnecessary line. Satisfied with yourself and the work done, you leaned back in your chair and thought about why Google introduced so many additional “cases” and how complicated the life of an ordinary Android developer is.
In fact, with the multi-window, Google is fine. Why are there problems with the tablet? Because in the Android SDK the concept of “tablet” does not exist. At all. There are small, medium, large screens ... But there is no “tablet" concept. There should not be any separate logic, there should be no additional functionality.
The problem is not that Google did everything badly, just as such a “special application” for the tablet should not be in principle. Where does all mania make applications separately for the tablet? From iOS, but there really is a concept of a tablet and for him there is an opportunity to do things differently.
Android applications, in my opinion, are more like the Web in this regard: you have a page and a certain data set, and you need to make everything look good on all screens and in all browsers. Doesn’t resemble anything? Many types of screens and a very large fragmentation of devices, many of them with their own characteristics, is that all? It seems so to me.
The peculiarity of the problems I described is that they should not be, but I hope that I helped you deal with them if they arose, or prevented their occurrence. Take a look at Google Play: you can open it on any device, and it will look, maybe not great, but at least good. This is because Google Play was originally created with the ability to display on the screen of any size. While the data set is always the same.
This is a very good practice. You can change the number of columns, indents, size of elements, hide or show some element and a bunch of everything, but the general logic and data set should remain unchanged. That, in my opinion, is the key to a cool application.
The topic is philosophical and, of course, controversial, so welcome to comment. Bye everyone!
As you all know, Android 7.0 was released at the end of August 2016, and one of its main features is multi-window support. This is a great feature that takes the convenience of Android to the next level. All users will be in seventh heaven, but what is happiness for the user can turn into a pain for the developer. Unfortunately, this is exactly what happened with multi-windows on tablets. And it’s on the tablets - on the phones, everything is fine with her, I say in advance.
If you are making tablet versions of applications or you are not indifferent to multi-window mode, then welcome to the article!
The root of all evil
Suppose you are a developer who unexpectedly decided to make multi-window support in a phone application. You did everything right, you set it up to a width of 320dp, and in general you are great, and, fortunately, the mode works just fine. Even if you’re not very well done, because you didn’t make support for small screens and made up for 360dp or 480dp, everything still remains in order. The worst thing that can happen to you is that the layout will float a little, or in some places the text in the button will not fit on one line. But let's be honest that these are all trifles. A couple of hours, maximum a day and voila, PROFIT! You are well done again and you can add new multi-window features to your application.
But what if you have not only a phone version of the application, but also a tablet?
You will have problems. Perhaps a pretty big problem. Even, perhaps, the problems will be so huge that you will have to radically change the architecture of the application.
Multi-window operation on a tablet
Screen orientation
For simplicity, let's imagine that we have a layout for phones and a layout for 10-inch tablets. We will consider everything using the layout example, that is, our resources will lie in the following folders:
- layout-port
- layout-land
- layout-sw720dp-port
- layout-sw720dp-land
Let's start with the vertical orientation. Our application can occupy either the entire screen, and layout from swap-sw720dp-port will be used:
Either half the screen, and resources will be taken from layout-land:
Or a third or two-thirds, and resources will be taken from layout-land and layout-sw720dp -land accordingly:
you expect that in landscape mode, land and port will simply swap places, but no. Everything is a bit wrong.
If the entire screen is busy, then layout-sw720dp-land is used:
If half the screen, then layout-port:
If a third or two-thirds, then layout-port and layout-sw720dp-land, respectively:
Demo application
We figured out the location. Many, probably, already begin to realize possible problems, but let's take it one after another. First, imagine that you made an abstract application that works perfectly on Android 6, but which has problems on Android 7. Please do not quibble in advance about how it is thought out, because it is thought out so specifically to demonstrate possible problems.
So, let the application be news and has three main entities: category, subcategory and news. The phone version can only be in portrait orientation and has three screens, each of which is a separate Activity:
- Main screen. It has the main categories of news, which are presented in the upper tabs. Inside each tab there is a banner with the most important news of the day. Below is a list of subcategories within this news category. When you click on this subcategory, we get to the screen with its contents.
- News list screen. When we click on a news, we find ourselves on a separate screen for this news.
- Separate news screen. Here we show the news in its entirety.
For the tablet, everything is arranged a little differently: there are only two screens, which are also Activity:
- Main screen. On the left is a list of categories with nesting in the form of subcategories. A list of news is displayed on the right. A new feature also appears on the tablet: you can click on a category and see all the news on it.
- Separate news screen. Here, in principle, everything is the old way, just the layout has changed a little.
The application has MVP architecture and each screen has Presenter and View. A custom ViewGroup like this is used as the View . For the main screen and the news list screen, completely different View and Presenter are used. The news screens on the tablet and on the phone are absolutely identical to each other in logic, but due to the large differences in the visual part, we need more than just different xml. Therefore, the implementation of View is organized as follows: the abstract class NewsView, which contains all the common and inherited from it classes PhoneNewsView and TabletNewsView.
Now let's take a little more imagination and imagine that we launched our application on a 10-inch tablet running Android 7 and turned on multi-window mode.
Presented? Let's see what happened.
It doesn’t look very, but all because earlier in the phone version you did not support landscape orientation. Therefore, he takes resources from shared resources. Although in principle everything is cool, the banner pulled a little, but these are trifles. To celebrate, you poke on the first subcategory that comes across and get to the news list screen, which is also not so bad.
Joy over the edge, and then it dawns on you: “What will happen if I re-deploy the application and go to the layout of the tablet? After all, this screen should not be in the logic of work on the tablet. " Well done, you are a very correct thought. The following will happen: you will see a screen that should not be here. Moreover, you will be shown his phone version, which will ruin the appearance.
Problems
Problem number 1: if the screen of the tablet version combines several screens from the telephone, then chaos will begin.
What solutions are there? Well, for example, you can redo everything into fragments, put them on top of each other in the phone version, and next to it in the tablet version. Profit! But do not forget that this is easy to do only on our small abstract application, and in a real application you will have to make a lot of effort. Also, your application may have confused navigation that cannot be implemented using fragments due to the fact that they cannot save the state of their child fragments.
Suppose you redid our abstract application into fragments, but then remember the unusual features of the tablet - the ability to show all the news in all subcategories of any category.
Problem number 2: if the tablet version has functionality that is not in the phone version, and vice versa, then everything will be bad.
What to do? You will have to add this functionality to the phone version, or remove it from the tablet. As you know, in real life there can be a lot of such functionalities, and most likely it will require a lot of you, a lot of coordination, which ultimately will result in shreds of torn hair and full glasses of bitter tears. It's good that in our small abstract application there is not much of it, otherwise we would have to sweat.
Everything seems to be fine with the list of categories. You have debugged and fixed everything, you are definitely well done. You go to the separate news screen and try to switch to multi-window mode, but - oops! - the application crashed. What is the matter? And all because your PhoneNewsView and TabletNewsView have the same id. It turns out that onSaveInstanceState is done for one class, and onRestoreInstanceState is already for another.
Problem number 3: if in the xml tablet version and the phone version different classes have the same id, then you will definitely get tired of fixing it.
How to get around this? You can simply set them with different id, but here the problem immediately arises with maintaining the state when changing the multi-window mode, namely, that it will not be. There is a way out: to do everything so that the code does not have any differences between the tablet and phone versions, except in XML. If there is an urgent need to add some new element to the tablet, then it is better to just check it for null and only then do something with this element.
You brilliantly dealt with this problem, congratulations. Then you suddenly remember that on the same screen, in the phone version, right below the picture of the news you read "If you have a tablet, then try our tablet version." Awful Well, in fact, in comparison with the previous problems, these are just flowers, but still unpleasant.
In general, this is not problem number 4. I just wanted to tell you how to take tablet resources, if the application, in theory, should take phone resources.
So what to do? If you take resources from Application in multi-window mode, it will return them for the tablet; if from Activity, View, Fragment and everything else that is not Application, it will return for their size. That is, if you divide the screen in half, then Application will return the tablet resources, and everything else - telephone. I think this is due to the fact that, in theory, one application can be divided into several windows. Maybe many have come up with a tricky plan - to do setContentView in Activity not by id, but by the "view" that you pre-inflated with Application. BUT! Doing so is not worth it. Otherwise, your application will look like this:
With Application, you have resolved the dilemma with an unnecessary line. Satisfied with yourself and the work done, you leaned back in your chair and thought about why Google introduced so many additional “cases” and how complicated the life of an ordinary Android developer is.
Important detail about Android SDK
In fact, with the multi-window, Google is fine. Why are there problems with the tablet? Because in the Android SDK the concept of “tablet” does not exist. At all. There are small, medium, large screens ... But there is no “tablet" concept. There should not be any separate logic, there should be no additional functionality.
The problem is not that Google did everything badly, just as such a “special application” for the tablet should not be in principle. Where does all mania make applications separately for the tablet? From iOS, but there really is a concept of a tablet and for him there is an opportunity to do things differently.
Android applications, in my opinion, are more like the Web in this regard: you have a page and a certain data set, and you need to make everything look good on all screens and in all browsers. Doesn’t resemble anything? Many types of screens and a very large fragmentation of devices, many of them with their own characteristics, is that all? It seems so to me.
The peculiarity of the problems I described is that they should not be, but I hope that I helped you deal with them if they arose, or prevented their occurrence. Take a look at Google Play: you can open it on any device, and it will look, maybe not great, but at least good. This is because Google Play was originally created with the ability to display on the screen of any size. While the data set is always the same.
This is a very good practice. You can change the number of columns, indents, size of elements, hide or show some element and a bunch of everything, but the general logic and data set should remain unchanged. That, in my opinion, is the key to a cool application.
The topic is philosophical and, of course, controversial, so welcome to comment. Bye everyone!