Support Edge to Edge in the Android apps



This article is about adding Edge-to-Edge support in the Android applications. We are going to understand the concept with help of questions and finally understand how to code to achieve the required support.

What is Edge-to-Edge?

Expanding our apps contents to display app content across the entire screen. By default content of the app is between status bar and navigation bar (collectively called as System Bars)    .

Why should we add this functionality?

  • Helps in letting app provide immersive experience to the user. This is an important feature for the apps supporting “image viewer” or “video viewer” or "games" app.
  • Provides more area to the app to show the content.

Steps to achieve edge to edge

1. Layout your app full-screen.

This method tells the window that the content of the app will expand to full screen. Once this is called the app content view will be drawn from the edges. Check the screenshot below.

Notice that the top text view and bottom buttons are behind the system bars.


2. Change the system bar colors and transparency.


Now that content is drawn behind system bars we need to update the bars colors so that the app content is visible. For this we will set the colours of status bar and navigation bar to transparent. Note this is only required for API 29 and above as the system bars have a translucent scrim behind system bars. For API 28 level and below the system bars is by default transparent. Check the below screenshot after making system bars transparent.

Notice that the top text view and bottom buttons are behind system bars and color is set to transparent.



3. Handle any visual overlaps.



The system bars are made transparent. Even if they are transparent they are part of the hierarchy and can consume the touch. So in the scenario where we have an app widget that intersects with system bars it will not allow the widget to handle the user touch. Hence blocking the usage of that widget. Check the screen added in above section where bottom buttons are overlapped by navigation bar.

To prevent this from happening the android system has a concept of insets which provides the required space taken by the system bars. We can use this space value to position the view such that it can handle the user touch.

There are different types of insets to represent the space taken by the different window components. A few of them are:
  • System bars (status bar + navigation bar + caption bar)
  • Display cutout (black cut outs see at the top or bottom of the device)
  • System gesture inset
Notice that top text view is moved below the status bar and bottom buttons are moved above navigation bar.


Resources:

https://developer.android.com/training/gestures/edge-to-edge
Location: India

Comments

Post a Comment

Popular posts from this blog

Fragment Lifecycle

Image
Just like Activities, Fragments also manages its own lifecycle. Though these lifecycle callbacks are a bit different than activity’s callbacks they exist for the similar reason as that of activity’s callback. Fragment manages two different lifecycles. One for the fragment instance and other for the view shown in the fragment. Having different lifecycle for fragment’s view is useful in the situations where the work should be performed only when view exists. Points to note: Fragment lifecycle call-backs are similar to Activity’s lifecycle. More important they are dependent on Activity’ state. Fragment manages 2 different lifecycles - Instance and View. Fragment callbacks are: onAttach, onCreate, onCreateView, onViewCreated, onViewStateRestored, onStart, onResume, onPause, onStop, onDestroyView, onDestroy, onDetach Fragment state is saved before onStop for API level less than 28 while in API level 28 and above its saved after onStop method. i.e In API level 28 or above devices its safe to...
Read more

AndroidManifest

Image
One of the most important components of your project. Stays in the root directory of the project source. This is used to describe essential information about the app to Android Build Tools, Android OS and Google Play. Most important things for which AndroidManifest is used: To declare app’s package name: Used by Android build tools to map code entities and to map it with applicationId defined in build.gradle To declare different app components: Include all activities, services, broadcast receivers, and content providers To declare app permissions: Helps in accessing specific restricted by System or other apps. To declare hardware and software features: Used to decide which device can app be installed into Package name and application ID Example <?xml version="1.0" encoding="utf-8"?>        <manifest            xmlns:android="http://schemas.android.com/apk/res/android"           package="co...
Read more

Activity Lifecycle

Image
To let Android System interact with Application different methods are defined by the system which communicate different states of the activity to the application. Those methods/states are called as Lifecycle Callbacks. Activity can go into different combination of these states. In the code each callback is used to understand the state in which the activity is in and accordingly perform different operations. Let’s discuss different activity callbacks and what each of them represent in real life scenarios. You will find each section explained with the 3 labels. Let us see what each label represents: Called: It will tell you when is this method called. Implement: What should be implemented in this method. State: What is the state of activity from user's perspective.                         onCreate() Called: This is the first callback received in Activity which is called as soon as the system creates the Activity. Implement: Used ...
Read more