Android 12: UX And Design Changes

Since the first quarter of 2021, Android developers have enjoyed exploring the new Google APIs and behavior changes for the forthcoming Android API 31. During the Developer Previews phase, the focus was on developer community feedback for the APIs. In the current Beta Release phase, the main focus is Android Beta users’ compatibility experiences. Then, in the final step, apps and libraries are compiled and tested against the official API 31 SDK. In addition, the corresponding libraries are updated, and their developers are informed of potential problems. 

Ultimately, after various release candidates, the final release of Android 12 will be published with the related news. Due to the advanced beta phase, it is worth looking at some of the new functionalities and APIs discussed in this blog post from both a developer and user perspective. As a developer, in addition to the emulator with the following Google Pixel devices, you have the option of obtaining an Android 12 beta build in which you are automatically provided with over-the-air updates of younger preview versions after the successful flash process:

1. Pixel 3 and 3XL
2. Pixel 3a and 3a XL
3. Pixel 4 and 4XL
4. Pixel 4a and 4a (5G)
5. pixels 5

User Experience And Design

Widget API Update

In the Google blog post “What’s new in Android 12 Beta”, Android 12 is advertised with the most significant design changes in Android history, summarized under “Material You.” To improve the user and developer experience, the Widgets API has received a considerable overhaul. Visual improvements from Android 12 include:

1. Customizable rounded corners for both the widget background and any view within the widget
2. Vibrant colors can be used and customized for widgets through the use of themes – this is possible through the following common attributes, for example: colorAccent, colorBackground, textColorPrimary, textColorSecondary

Additional APIs to more reliably configure the size of the widgets on different devices and to define a maximum resizable size of the gadgets:

1. android :targetCellWidth=”3″
2. android :targetCellHeight=”3″
3. android :maxResizeWidth=”200dp”
4. android :maxResizeHeight=”80dp”

In the Widget Preview view, scalable XML layouts with an additional description can now be used instead of static images so that the best possible display is guaranteed on the various end devices: 

1. android :previewLayout=”@layout/widget_preview”
2. android :description=”@string/widget_preview_description”

Responsive layouts can be provided to change the view of widgets when resizing, for example, from a list to a grid layout. Various instructions for backward compatibility with the new API functions in the official guidelines. In addition to the visual improvements, support for stateful behavior has been added for the following components:

1. CheckBox
2. switches
3. radio button

To use the new state-based behavior, the app must store the states and provide events for the state changes, while the widgets themselves remain stateless. The update of this API is, in some functionalities, long overdue and, despite everything, very successful progress in the display and use of widgets. From the developer’s point of view, the new features and possibilities are easy to implement. From the user’s point of view, both the user experience and the perceived product maturity of the app are increased.

Splash Screen API

Another new element is the Splash Screen API. A sprinkle screen is visual criticism shown to the client while the application is instated. For instance, the client doesn’t see an empty net yet an application symbol or a movement while the application is performing different foundation administrations. As well as expanding the client experience for the client, designers get a lean and straightforward-to-utilize API from carrying out a sprinkle screen. Beforehand, it was a custom execution that could be carried out in different ways.

On June 30th, 2021, the primary alpha variant of the Core Splash Screen API was delivered: android x.core:core-splashscreen:1.0.0-alpha 01. In reverse similarity for the new Splash Screen APIs up to API 23. The programming interface must be applied when the compileSdkVersion is pronounced on Android 12 (API 31). The sprinkle screen is generally shown to the client in the accompanying circumstances:

1. Cold beginning: When the application cycle isn’t running, and the application begins
2. Warm beginning: When the application cycle has started, however, the movement has not yet been made or was recently obliterated

The sprinkle screen isn’t shown on a hot beginning, i.e., if the application was brought to the foundation, for instance, and the application is opened again – before the framework annihilates the action. The sprinkle screen is executed utilizing a style subject that should be characterized as Parent Theme.SplashScreen. The accompanying center ascribes accessible:

1. windowSplashScreenBackground: The foundation shade of the screen
2. windowSplashScreenAnimatedIcon: Splash Icon, ideally a VectorDrawable, can be either static or animated
3. windowSplashScreenAnimationDuration : Time how lengthy the sprinkle screen ought to be shown (max = 1,000ms)
4. postSplashScreenTheme: Theme to be utilized when the sprinkle screen is at this point not apparent

In a movement, just the introduce sprinkle screen() order before the setContentView request is expected in the onCreate strategy. The sprinkle screen is accessible, and the subject characterized in postSplashScreenTheme is utilized after the fruitful showcase. For instance, assuming the application’s statement consumes a large chunk of the day at startup because of nonconcurrent I/O calls, it is feasible to show the sprinkle screen for a more extended time frame utilizing ViewTreeObserver.OnPreDrawListener. 

Client characterized automatic changes for activities, for instance, after the finish of the sprinkle screen, are presently just apparent from Android 12 and higher. In general, the alpha adaptation of this lean API ran with no issues on Android 12 gadgets. In any case, minor bugs were found in the presentations on devices underneath Android 12, which are not out of the ordinary with an early alpha form. We, in this way, educate against the proper use of the API, which is probably going to change. Numerous engineers will be thankful for a steady form of this API. Clients have proactively seen a couple of sprinkle separates past applications and anticipate that this should become the norm later on.

Blur Effects And More With The RenderEffect API

As of Android 12, it is much easier to integrate blurs, color filters, and other graphic effects in the desired views with the RenderEffect API. A combination of the respective effects as a chain is also possible. The RenderEffect API works efficiently using the existing rendering pipeline to minimize unnecessary additional calculations. A blur effect with individual strength can be created on the desired view, such as an ImageView or ParentLayout with just one line of code : view.setRenderEffect(RenderEffect.createBlurEffect(radiusX, radiusY, SHADER_TILE_MODE))

Even less code is required to set the idea back to its original state using the following command: view.setRenderEffect(null). In previous versions of Android, to achieve the same effect, you would have to request the bitmap information for the content of an ImageView, edit the image accordingly, create a new bitmap and then put it back into the ImageView. The most significant disadvantage of this API is the support from Android 12, so a fallback solution would have to be installed on older versions.

Rounded Corner APIs

The Rounded Corner APIs introduced in Android 12 respond to the ever-increasing proliferation of end devices with rounded corners. The problem developers faced with rounded-corner devices was the potential for UI elements to be separated on the screen. The Rounded Corner APIs can be used to query information about the presence of rounded corners, including the radius and center point of a rounded corner. Based on this information, the layout of the UI elements can be adjusted according to the end device.

Rich Content Insertion

The developer now has a unified API to share content between different applications with the Unified API. Previously there were three other APIs to insert content, for example, via the LongPress menu, via drag-and-drop, or from the keyboard. To use the API, only the listener interface, which has only one method, has to be implemented. A significant advantage here is the backward compatibility with older Android versions through the AndroidX Core library from version 1.5.0. Unifying these APIs will significantly improve code quality and aesthetics.

Overscroll Effect

Starting with Android 12, the observable behavior changes during an overscroll situation. While for versions below Android 12, the end of a list started to glow when there was an overscroll, from Android 12, the individual list elements stretch out depending on the depth of the drag/fling event and bounce back. The more sophisticated and modern animation enhances the user experience. It can be used by a developer with the help of the EdgeEffect within the following classes on all commonly used list, scroll, and swipe elements:

1. ViewPager2
2. ScrollView
3. ViewPager
4. RecyclerView
5. NestedScrollView
6. ListView
7. HorizontalScrollView
8. ScrollView

Conclusion

In addition to many visual innovations, essential and well-thought-out features have been made available in user experience, security, and privacy, making it tempting for end-users, in particular, to switch to the new Android version. The changeover will also bring a lot of joy for developers since most of the features bring with them many simplifications and some innovations. Unfortunately, not all new features are backward compatible, so backward compatibility has to be written manually for some of the new features, or they are not offered for lower android versions.

Also Read: Realme 9, 9 Pro, And 9 Pro +: Everything You Need To Know