# Back to basics: Screens

DevFeed: [Back to basics: Screens](<https://devfeed.tech/articles/back-to-basics-screens-26001.md>)

Original publisher: [Read original article](<https://medium.com/@nhaarman/back-to-basics-screens-5f15992ba796?source=rss-fceb7a60a849------2>)

Author: Niek Haarman

Published: 2018-09-30T19:10:45Z

Content type: tutorial

Language: en

Sources: [Stories by Niek Haarman on Medium](<https://devfeed.tech/sources/stories-by-niek-haarman-on-medium.md>)

Topics: [Mobile](<https://devfeed.tech/topics/mobile.md>), [Android](<https://devfeed.tech/topics/android.md>), [ui](<https://devfeed.tech/topics/ui.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [business-logic](<https://devfeed.tech/tags/business-logic.md>), [interface](<https://devfeed.tech/tags/interface.md>), [lifecycle](<https://devfeed.tech/tags/lifecycle.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [user-interface](<https://devfeed.tech/tags/user-interface.md>)

## AI overview

The article examines screens in mobile applications as presentation-layer destinations composed of components for specific use cases. It argues that business logic should remain outside screens, and discusses lifecycle handling, user-interface responsibilities, and preserving state when Android processes are killed.

## Source excerpt

In a previous article, I talked about things that are wrong with the Activity class, the main conclusion being that it does too much. This time I want to look at an alternative way of looking at the concept of screens, stepping away from the design flaws of the Activity class. What is a screen? In a typical mobile application, the user can navigate from one destination to another. Each of these destinations can be regarded as a 'screen': a set of components that fulfill a very specific use case. For example, the main screen of a Twitter client may show a list of tweets to the user. The notion of 'screen' here is very much tied to the presentation layer of the application: when talking about screens, you're inevitably talking about UI and navigating through them. This means that business logic, such as processing use cases, calculating values and fetching network results has nothing to do in there. The lifecycle A lot of people have difficulties grasping the concept of the Activity lifecycle, but this part is one thing the Activity (somewhat) did right. When a screen becomes active in the application, it may want to start calling use cases in the business layer to retrieve some data. When it becomes visible to the user, it may want to register listeners to the UI to react to events. When it is replaced by another screen, it may need to stop listening for updates, and when it is destroyed (by popping it from a back stack for example), it may need to do some cleanup. Lifecycle callbacks are an excellent way to go and handle these scenarios. The user interface Usually, screens have something to show to the user. A screen may gather the data to show and pass this to the user interface, which uses this data and turns it in something visual for the user to interact with. This is one case where the Activity violates the single responsibility principle: next to handling lifecycle events, it is also responsible for inflating the user interface. Saving state Android's multitas