Posted by Alex Vanyo, Developer Relations Engineer
With the rise in Android apps getting used on massive display kind components like foldables and tablets, an increasing number of apps are constructing totally adaptive UIs. See Assist completely different display sizes for greatest practices for updating your app for greatest practices for updating your app. The underside line is that Structure and app habits ought to be based mostly on system configuration and out there options, and never the bodily kind of the system.
On the similar time, we get this query quite a bit: “Is there a straightforward method to inform if a tool is a foldable, pill, or one thing else?”
It may appear that utilizing the bodily kind of system offers all the knowledge builders have to create nice experiences. Nevertheless, we are able to make extra adaptive apps with a greater consumer expertise by including extra context. For instance:
- Would you like “flip”-style telephones to depend as foldables?
- Do you need to decide if a tool is a pill, or simply if mobile performance is obtainable?
- What would rollables depend as? What about ChromeOS units, or different desktop units that may run Android apps?
The commonest motive app builders need to know the kind of the system is to allow them to decide what sort of structure to point out. However with the rise of split-screen and multi-window utilization on massive screens, making structure choices based mostly on system kind results in incorrect structure choices in sure eventualities on massive display units.
As we’ve been updating our personal apps to higher help extra units, we now have seen a number of essential use circumstances to focus on additional. We’ll cowl 4 important eventualities:
- Layouts – Show probably the most acceptable UI for various units and folding postures
- {Hardware} options – Implement help for a wide range of {hardware} options
- Displaying the title of the bodily system kind to the consumer – Personalize end-user going through data for the kind of system.
- Metrics monitoring for system kind – Perceive how customers are utilizing your app on various kinds of units
Layouts
Show probably the most acceptable UI for various units, show modes, and folding postures.
Use window dimension courses to information structure choices based mostly in your present windowing state utilizing opinionated breakpoints which might be derived from widespread system sorts. Do not prohibit orientation or resizability; you forestall customers from utilizing your software of their desired method.
Observe folding options with Jetpack WindowManager, which offers the set of folding options that intersect your app’s present window. Word that even when your exercise isn’t receiving any folding options, it might nonetheless be operating on a tool able to folding – on the outer display, on the interior display in a small window, or on an exterior show.
Traditionally, a number of distinct layouts have been created for various display sizes, usually with a “pill” structure and a “cellphone” structure. These two layouts then existed collectively, and each needed to be saved updated because the app modified. Referring to those layouts as “pill” and “cellphone” layouts was helpful when the system producers by and enormous restricted themselves to creating units that match cleanly into these two classes. Customers at present have much more alternative as producers are creating units which might be extra bodily different, and usable in several methods.
A single system could typically have sufficient room to show a “pill”-sized structure, whereas different occasions (for instance, a folded foldable or cut up display) the system could solely have sufficient room to show a “cellphone” structure. There are even circumstances the place a smaller structure is desired equivalent to foldable flip cellphone cowl shows.
This may very well be attributable to a foldable that has a smaller outer display and a bigger interior display, or each time the consumer enters multi-window mode and adjusts freeform windowing environments. Critically, the kind of app structure shouldn’t be determined by the bodily kind of the system; it ought to be determined by the present dimension of the app’s window, which can or is probably not full display on the present system show.
On massive display units operating Android 12L and better, apps that prohibit the orientation or resizability could be positioned into compatibility mode because the system is rotated or folded or the app enters multi-window mode. Compatibility mode letterboxes the app, preserving the app’s specified restrictions, however lacking the chance to show extra, helpful content material to the consumer.
{Hardware} options
Implement help for a wide range of {hardware} options (for instance, if the system has a SIM).
Make dynamic, runtime choices based mostly on whether or not a function is obtainable, as an alternative of assuming {that a} function is or just isn’t out there for a sure sort of system.
In case your app has a function that’s completely required, Google Play respects the required uses-feature declarations in your manifest. Nevertheless, be conscious that any required options cut back the set of units that your app could be put in on, and including new required options prevents updates to beforehand supported units.
There are lots of {hardware} options which might be current on some Android units, however not current on others. As units proceed to evolve, we’ve seen a number of circumstances the place user-facing options aren’t supported, as a result of builders assume {that a} bodily kind of system doesn’t help a specific {hardware} function.
For instance, we’ve seen circumstances the place biometric authentication isn’t provided as a login possibility on tablets that help biometric authentication, even when the identical app helps biometric authentication on telephones. Biometric authentication ought to be an possibility for the consumer if the system helps it, not based mostly on the kind of system.
One other instance is assuming mobile connectivity is proscribed to standard-size telephones. Foldable units may need “pill”-sized screens, however foldables nonetheless have a mobile connection and a cellphone quantity. If a tool has the aptitude, the consumer ought to be capable of select to make use of the system accordingly.
Some {hardware} options are additionally dynamically out there. Peripherals is likely to be connected and indifferent by the consumer, and apps ought to gracefully deal with gaining and dropping entry to those options. {Hardware} options just like the digital camera and microphone can solely be utilized by one app at a time, so multi-tasking between completely different apps can also lead to dropping entry to {hardware} options.
Displaying bodily system kind to the consumer
Personalize user-facing data by kind of system (for instance, “Run in your pill”)
Referring within the UI to the consumer’s system as merely a “system” covers all kind components and is the only to implement. Nevertheless, differentiating between the a number of units a consumer could have offers a extra polished expertise and allows you to show the kind of the system to the consumer utilizing heuristics related to your explicit use case.
For instance, Google Play at the moment makes use of the next heuristics for figuring out the system title to show to the consumer when putting in an app on a specific system. The logic is restricted to this explicit use case, and will change as units and kind components evolve.
In case you are displaying the kind of the system to the consumer, and need to differentiate between the bodily kind of the system for personalizing the expertise, equivalent to to say “obtain in your foldable” or to point out extra particular system imagery, you should utilize the out there bodily options as heuristics for which sort of system the consumer is utilizing. Nevertheless, these are solely heuristics and will change because the accepted phrases for referring to the units themselves change. As mentioned above, a foldable system could or could not help different {hardware} options, or have a big display.
“Foldable” heuristic:
If a tool has a hinge sensor (which could be decided by PackageManager.hasSystemFeature(PackageManager.FEATURE_SENSOR_HINGE_ANGLE)), then the system helps folding in some method. Word: Whereas this covers most foldables shifting ahead, it could not cowl some older foldables that don’t expose a hinge sensor. Moreover, the display the app is being displayed on could or could not fold, the system may need a further non-folding display as nicely, or the display could not at the moment be folded, even when it might fold. Units just like the Samsung Flip have a smallest width of lower than 600dp, The interior display of large-screen foldables have a smallest width of 600dp or extra.
“Cellphone” heuristic:
99.96% of telephones have a built-in display with a width smaller than 600dp when in portrait, however that very same display dimension may very well be the results of a freeform/split-screen window on a pill or desktop system.
“Desktop” heuristic:
Desktop units, like ChromeOS units, operating Android apps, could expose particular options or surroundings data that apps can use. As an example, ChromeOS has the system function “org.chromium.arc” or “org.chromium.arc.device_management” to allow builders to find out whether or not their app is operating on ChromeOS. However apps operating on tablets – and telephones, if the consumer so chooses – can also use desktop-class keyboards and mice for enhanced productiveness.
Metrics monitoring for system kind
Perceive how customers are utilizing your app on various kinds of units.
Use the heuristics and options mentioned above as inputs to your analytics, whereas retaining in thoughts that bodily system kind doesn’t give the entire story for a way customers are utilizing your app on that system.
Even when the consumer is utilizing a tool that may bodily fold, they might be utilizing the app in a number of configurations. Customers may use an app kind of on the interior display in comparison with the outer display, and so they may multi-task with different apps on the interior display. For units that help exterior shows, the app won’t be operating on both of a foldable’s built-in bodily shows.
Different data which may even be related:
- Are there exterior peripherals getting used to work together with the app, like keyboards, mice, trackpads, or styluses?
- Does the system have a built-in touchscreen?
- Is the app being utilized in a free-form windowing surroundings?
Conclusion
Do not make assumptions about what a specific bodily system implies on your app. “Is the system foldable?” is an effective place to begin, but it surely shouldn’t be the one query you ask. Further items of data will give a extra exact and extra related reply to your use case at hand, and every use case has completely different issues that it’s best to make to construct versatile, adaptive apps.