Thanks very much for this well explained post. I will try to answer you step by step according to my knowledge, but probably we can continue discussing here about. Then go on!
- when rotating the device (for ex: Debugger_2_480x320.png) the first label (green) overlaps the second one)
Maybe the rotation of a device is one of the more difficult "scale" issues that we can find, because, certainly the screen is not only reduced, but completely "streched". What we can do about? We can try various possible approach, depending on our apps requeriments, for example:
1º We can simply avoid the "landscape" mode. This is perfectly possible and commonly used by the applications in mobile platforms. We have the appropiate app's Cordova option in order to fix the application in portrait mode.
2º Since we can know what mode is used in the app (portrait or landscape, with the global app's variable "App.Orientation") and also the app's Orientation event, we can try, for example, to hide some elements or customize their sizes, etc., depending on the orientation.
3º We can also try to design from scratch testing againts both portrait and landscape, so, probably we place the elements in a way in which they are more or less affordables in both modes. In other words, if we design only for portrait... probably the landscape mode produces some unexpected (in portrait) result. The App Builder's debugger offers the way to change between the orientation modes, so we can easily take a look at them.
- even if a label is put in a container with a select control, it doesn't keep its alignement (for ex: Debugger_2_480x320.png)
I am not quite sure what to say, because, in my opinion probably the container are not required at all. Maybe we can use a Label, or an Html control, without any container, and positioning it using another possible approach, if the "inline one" do not work as expected. First of all, maybe this point is related with the latest one, so, we can perform some adjust to the controls taking in care (from the scratch) the portrait and landscape modes.
Secondly, maybe we can follow another possible approach, for example, place the label up to the Select control, not at their side. Maybe even provide a default value for the Select control, which can be shown at the beginning, but only used to indicate to the user for what the Select control is intented. Anyway in my opinion this point is not exactly the same than the first one, in which we deal with some general considerations.
- on a real device (Android 6.0.1 using Chrome), the first label is under the browser's search/url field (for ex: Real_device_1.png)
Certainly this appear to be a problem specifically related with Chrome for mobile. This problem occur in any other application, so, I will investigate how to solve it. Thanks for the information Samuel.
- the font size in a Select control or an Input field is not kept consistent in some resolutions (for ex: Debugger_5_640x360.png & Debugger_6_1024x768.png)
This is a quite rare issue, according to your screenshots. Maybe I appear too stupid, but, maybe you decrease the font size in that browser in particular? In which browser you get the "reduced" font size? I never view this before...
- the space width between a not fixed size button and a fixed sized button (blue buttons at the end of the screen) curiously varies not depending ont the resolution (ex differences between Debugger_5_640x360.png (which seems correct because the width is the double of the original one it was developed on) and Real_device_2.png (which looks like the original layout but is 1080 px width)
- the width of buttons seems not to be consistent too. For example, "Button4" ends before "Button button with max-width" (for ex: Debugger_4_412x732.png) or ends after (for ex: Debugger_5_640x360.png but not Real_device_2.png)
I am not sure if undersstand, because, I can see the buttons you are using have some of their CSS properties like "max-width" established... So I can't figure exactly what you wanted exactly, sir, sorry so much. Are you try without "max-width"? What you wanted to use the "max-width"? Why the buttons inside a Container?
Some other possible considerations
In my experience, if we want that our applications uses all the screen, in larger screens, we must limit the size of the application, just like I do in the Calculator sample. In this way, the controls scaled very well, until they appear "too big", in which we "stop" the scalation of the application, so, certainly the application do not fill all the available screen, however, they looks better.
Maybe it's not a good idea to use all the available space of the application size, that is, something like I use in the App Builder samples: I let some pixels at the borders. We can consider to use some of the Bootstrap CSS 3 classes related with the "responsive utilities", so we can show or hide controls depending on some screen sizes. Another way to do the same is to deal with the app's Orientation and Resize events and global variables like "App.InnerWidth", "App.InnerHeight" and "App.Orientation".
Design thinking on small screens can be good in most situations. This means, for example, do not place too much controls in the same app's view. If we need too much controls in an app's view and have scaled problems... maybe this can be reduced by separating some of the controls in another app's view: there is no limits in the number of app's view, so, we can prepare any number of them to place any controls we need, instead of placing too much in the same app's view.
I will take a look at the Chrome for mobile issue, since the problem do not appear in other browsers like Firefox for mobile... I think App Builder must incorporate a fix for this, so we no need to worry about, but I will to investigate about in order to find the appropiate solution.