Managing Multiple UI Layouts in a Single Activity
Join the DZone community and get the full member experience.
Join For Freeintroduction
due to the wide proliferation of smartphones, making application functionality (at least some functionality, if not all) available on a mobile is a must-do activity for enterprises. most applications published for a mobile phone, have to face up to the challenge of presenting content on a limited space. not only is the large size that was taken for granted on the desktop not available, application designers also have to contend with the fact that users will view the content from devices with varying sizes and resolutions. as there is limited space available on the mobile screen, it is practical to design applications using multiple screens, with each screen showing limited (and relevant) information in easy-to-consume chunks and arranged in a logical flow.android activity
on the android platform, the activity class is one of the central concepts for application development. an activity is usually associated with a user interface (ui) layout that is displayed when the activity is visible. with an activity playing a central role in an android application, it would be interesting to look at the activity life-cycle, before continuing with the main topic of the article. given below, for reference is the activity life-cycle, as published on the android developers website.
one ui per activity
the standard practice for developing applications with multiple screens is to create one screen per activity. whenever the user moves to a different screen of the application, the application transitions from the existing activity to the new activity and the transition is managed by the android platform. as part of the transition, the 'onpause' method of the calling activity ('parent') is invoked, before the 'oncreate' method of the called activity is invoked, bringing it into focus.sharing data
it is important to note that activities are independent of each other and are represented as different classes in the application. if needed, paused activities are destroyed by the android platform and re-created as needed. as activities are different classes and are created and destroyed as per the application flow (and platform need), an important consideration is sharing data between them. it is possible to pass information between activities by storing it as 'extra' information attached to the intent object, when an activity is launched. it is also possible to store the information in a class derived from the 'application' object, from where it can be accessed by all activities in the application. while only basic data types can be passed as 'extra' data, complex, user-defined data types can be stored inside the application object.example
we would like to illustrate the concept, using a simple example. the example presents the ui of the 'time quiz' application published by the author on the google play store. when started, the application displays the 'main' screen, which allows the user to play. on starting the game, the 'game' screen is displayed, which shows a clock face and four options, of which one of the correct answer. if the user selects the correction time, the 'happy' screen is displayed. if the users answer is incorrect, the 'sad' screen is displayed. all the four screens are managed inside a single activity, while the appearance of the screens is controlled by the 'visibility' flag. the four application screens are given below
![]() |
![]() |
![]() |
![]() |
managing visibility
each of the screens is defined using a layout container. the layout xml is presented below. in the interest of brevity/space, some of the ui elements have not been included.<?xml version="1.0" encoding="utf-8"?>
<linearlayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent" android:scrollbars="horizontal|vertical">
<linearlayout android:id="@+id/layoutmain" android:layout_width="fill_parent" android:layout_height="fill_parent" android:layout_gravity="center" android:orientation="vertical" >
<button android:id="@+id/btnplay" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_gravity="center" android:scaletype="center"/>
<linearlayout android:layout_width="fill_parent" android:layout_height="wrap_content" android:layout_gravity="center" android:orientation="horizontal">
<textview android:id="@+id/textscore" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_weight="1" android:textsize="20sp"/>
<checkbox android:id="@+id/checkboxenablesound" android:layout_width="wrap_content" android:layout_height="wrap_content" android:enabled="true" android:text="@string/str_sound"/>
</linearlayout>
<button android:id="@+id/btnexit" android:layout_width="fill_parent" android:layout_height="wrap_content" android:text="@string/str_exit"/>
</linearlayout>
<linearlayout android:id="@+id/layoutclock" android:layout_width="fill_parent" android:layout_height="fill_parent" android:orientation="vertical" android:layout_gravity="center" android:visibility="gone">
<timequiz.clockview android:id="@+id/viewclock" android:layout_width="220dp" android:layout_height="220dp" android:layout_gravity="center"/>
<textview android:id="@+id/textremainingtime" android:layout_width="fill_parent" android:layout_height="wrap_content" android:gravity="center" android:textsize="20sp"/>
<linearlayout android:layout_width="fill_parent" android:layout_height="wrap_content" android:orientation="horizontal" android:gravity="center">
<button android:id="@+id/btnoption1" android:layout_width="wrap_content" android:layout_height="wrap_content"/>
<button android:id="@+id/btnoption2" android:layout_width="wrap_content" android:layout_height="wrap_content"/>
</linearlayout>
<button android:id="@+id/btnbackmainclock" android:layout_width="fill_parent" android:layout_height="wrap_content" android:text="@string/str_back_main"/>
</linearlayout>
<linearlayout android:id="@+id/layouthappy" android:layout_width="fill_parent" android:layout_height="fill_parent" android:orientation="vertical" android:layout_gravity="center" android:visibility="gone">
<button android:id="@+id/btnbackmainhappy" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_gravity="center"/>
</linearlayout>
<linearlayout android:id="@+id/layoutsad" android:layout_width="fill_parent" android:layout_height="fill_parent" android:orientation="vertical" android:layout_gravity="center" android:visibility="gone">
<button android:id="@+id/btnbackmainsad" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_gravity="center"/>
</linearlayout>
</linearlayout>
initially, the 'visibility' flag for all containers, except the 'main' screen is set to 'gone', making the screens invisible. when the user starts the game by pressing the clock face on the main screen, the 'main' screen visibility is set to 'gone', hiding it and the 'game' screen is made visible by setting its visibility flag to 'visible'. the visibility of a layout can be controlled using the setvisibility() method and using the values view.visible or view.gone, as appropriate. if the user chooses the correct option, the 'happy' screen is made visible and the 'game' screen is hidden. if the user chooses the incorrect option, the 'sad' screen is made visible and the 'game' screen is hidden. on the 'happy' and 'sad' screens, when the user presses the image, control is transferred back to 'main' screen, by making it visible and hiding the 'happy' / 'sad' screen, as appropriate.
managing the 'back' event
when using one activity per application screen, the developer does not need to worry too much about the 'back' button. on the android platform, the 'back' button (physical or on screen) is used to navigate back to the parent activity, if the application has multiple activities. else, control is returned back to the main screen. when developing an application with a single activity, one needs to handle this event explicitly. for proper application behaviour, the 'onbackpressed' activity method needs to be overloaded. on receiving the 'back' event, we need to change the visibility of the screens as per application flow.screen workflow flexibility
when an application is modeled using multiple activities, the flow of control will be decided by the way the activities are called. in the example, when using multiple activities, flow of control will be 'main' screen to 'game' screen to 'happy' or 'sad' screen. when closing activities, the flow will be reversed. thus, when the 'happy' or 'sad' activity is closed, control will come to 'game' screen. when the 'game' screen is closed, control will go to 'main' screen. thus, it is not possible to go to the 'main' screen directly from the 'happy' or 'sad' screen. by using a single activity to manage multiple layouts, it is possible to go directly to the 'main' screen from the 'happy' or 'sad' screen, as the flow of control is decided by the application and not managed by the android platform.conclusion
in this article, we have shared a mechanism to create android applications that support multiple screens that are supported by a single activity. using this mechanism, activity transitions can be avoided and management of application data becomes easier. but, the complexity of code (due to the need to managed screen visibility) increases.Opinions expressed by DZone contributors are their own.
Trending
-
What I Learned From Crawling 100+ Websites
-
Building a Java Payment App With Marqeta
-
[DZone Survey] Share Your Expertise for Our Database Research, 2023 Edition
-
IntelliJ IDEA Switches to JetBrains YouTrack
Comments