You are previewing Learning Android.

Learning Android

Cover of Learning Android by Marko Gargenta Published by O'Reilly Media, Inc.
  1. Learning Android
    1. SPECIAL OFFER: Upgrade this ebook with O’Reilly
    2. A Note Regarding Supplemental Files
    3. Preface
      1. What’s Inside
      2. Conventions Used in This Book
      3. Using Code Examples
      4. Safari® Books Online
      5. How to Contact Us
      6. Acknowledgments
    4. 1. Android Overview
      1. Android Overview
      2. History
      3. Android Versions
      4. Summary
    5. 2. The Stack
      1. Stack Overview
      2. Linux
      3. Native Libraries
      4. Dalvik
      5. Application Framework
      6. Applications
      7. Summary
    6. 3. Quick Start
      1. Installing the Android SDK
      2. Hello, World
      3. The Emulator
      4. Summary
    7. 4. Main Building Blocks
      1. What Are Main Building Blocks?
      2. A Real-World Example
      3. Activities
      4. Intents
      5. Services
      6. Content Providers
      7. Broadcast Receivers
      8. Application Context
      9. Summary
    8. 5. Yamba Project Overview
      1. The Yamba Application
      2. Design Philosophy
      3. Project Design
      4. Part 1: Android User Interface
      5. Part 2: Preferences, Filesystem, Options Menu, and Intents
      6. Part 3: Android Services
      7. Part 4: Working with Databases
      8. Part 5: Lists and Adapters
      9. Part 6: Broadcast Receivers
      10. Part 7: Content Providers
      11. Part 8: System Services
      12. Summary
    9. 6. Android User Interface
      1. Two Ways to Create a User Interface
      2. Views and Layouts
      3. Starting the Yamba Project
      4. The StatusActivity Layout
      5. The StatusActivity Java Class
      6. Logging in Android
      7. Threading in Android
      8. Other UI Events
      9. Adding Color and Graphics
      10. Alternative Resources
      11. Optimizing the User Interface
      12. Summary
    10. 7. Preferences, the Filesystem, the Options Menu, and Intents
      1. Preferences
      2. The Options Menu
      3. Shared Preferences
      4. The Filesystem Explained
      5. Summary
    11. 8. Services
      1. The Yamba Application Object
      2. UpdaterService
      3. Looping in the Service
      4. Pulling Data from Twitter
      5. Summary
    12. 9. The Database
      1. About SQLite
      2. DbHelper
      3. First Example
      4. Update UpdaterService
      5. Refactoring Status Data
      6. Summary
    13. 10. Lists and Adapters
      1. TimelineActivity
      2. Basic TimelineActivity Layout
      3. About Adapters
      4. TimelineAdapter
      5. ViewBinder: A Better Alternative to TimelineAdapter
      6. Updating the Manifest File
      7. Base Activity
      8. Summary
    14. 11. Broadcast Receivers
      1. About Broadcast Receivers
      2. BootReceiver
      3. The TimelineReceiver
      4. Broadcasting Intents
      5. The Network Receiver
      6. Adding Custom Permissions to Send and Receive Broadcasts
      7. Summary
    15. 12. Content Providers
      1. Creating a Content Provider
      2. Using Content Providers Through Widgets
      3. Summary
    16. 13. System Services
      1. Compass Demo
      2. Location Service
      3. Updating Yamba to Use the Location Service
      4. Intent Service
      5. Sending Notifications
      6. Summary
    17. 14. The Android Interface Definition Language
      1. Implementing the Remote Service
      2. Implementing the Remote Client
      3. Summary
    18. 15. The Native Development Kit (NDK)
      1. What Is and Isn’t the NDK For?
      2. Problems Solved by the NDK
      3. An NDK Example: Fibonacci
      4. Summary
    19. Index
    20. About the Author
    21. Colophon
    22. SPECIAL OFFER: Upgrade this ebook with O’Reilly
O'Reilly logo


An activity is usually a single screen that the user sees on the device at one time. An application typically has multiple activities, and the user flips back and forth among them. As such, activities are the most visible part of your application.

I usually use a website as an analogy for activities. Just like a website consists of multiple pages, so does an Android application consist of multiple activities. Just like a website has a “home page,” an Android app has a “main” activity, usually the one that is shown first when you launch the application. And just like a website has to provide some sort of navigation among various pages, an Android app should do the same.

On the Web, you can jump from a page on one website to a page on another. Similarly, in Android, you could be looking at an activity of one application, but shortly after you could start another activity in a completely separate application. For example, if you are in your Contacts app and you choose to text a friend, you’d be launching the activity to compose a text message in the Messaging application.

Activity Life Cycle

Launching an activity can be quite expensive. It may involve creating a new Linux process, allocating memory for all the UI objects, inflating all the objects from XML layouts, and setting up the whole screen. Since we’re doing a lot of work to launch an activity, it would be a waste to just toss it out once the user leaves that screen. To avoid this waste, the activity life cycle is managed via Activity Manager.

Activity Manager is responsible for creating, destroying, and managing activities. For example, when the user starts an application for the first time, the Activity Manager will create its activity and put it onto the screen. Later, when the user switches screens, the Activity Manager will move that previous activity to a holding place. This way, if the user wants to go back to an older activity, it can be started more quickly. Older activities that the user hasn’t used in a while will be destroyed in order to free more space for the currently active one. This mechanism is designed to help improve the speed of the user interface and thus improve the overall user experience.

Programming for Android is conceptually different than programming for some other environments. In Android, you find yourself responding more to certain changes in the state of your application rather than driving that change yourself. It is a managed, container-based environment similar to programming for Java applets or servlets. So, when it comes to an activity life cycle, you don’t get to say what state the activity is in, but you have plenty of opportunity to say what happens during the transitions from state to state. Figure 4-1 shows the states that an activity can go through.

Activity life cycle

Figure 4-1. Activity life cycle

Starting state

When an activity doesn’t exist in memory, it is in a starting state. While it’s starting up, the activity will go through a whole set of callback methods that you as a developer have an opportunity to fill out. Eventually, the activity will be in a running state.

Keep in mind that this transition from starting state to running state is one of the most expensive operations in terms of computing time, and this also directly affects the battery life of the device. This is the exact reason why we don’t automatically destroy activities that are no longer shown. The user might want to come back to them, so we keep them around for a while.

Running state

The activity in a running state is the one that is currently on the screen and interacting with the user. We also say this activity is in focus, meaning that all user interactions—such as typing, touching the screen, and clicking buttons—are handled by this one activity. As such, there is only one running activity at any given time.

The running activity is the one that has priority in terms of getting the memory and resources it needs to run as quickly as possible. This is because Android wants to make sure the running activity is zippy and responsive to the user.

Paused state

When an activity is not in focus (i.e., not interacting with the user) but still visible on the screen, we say it’s in a paused state. This is not a typical scenario, because the device’s screen is usually small, and an activity is either taking up the whole screen or none at all. We often see this case with dialog boxes that come up in front of an activity, causing it to become Paused. All activities go through a paused state en route to being stopped.

Paused activities still have high priority in terms of getting memory and other resources. This is because they are visible and cannot be removed from the screen without making it look very strange to the user.

Stopped state

When an activity is not visible, but still in memory, we say it’s in a stopped state. Stopped activity could be brought back to the front to become a Running activity again. Or, it could be destroyed and removed from memory.

The system keeps activities around in a stopped state because it is likely that the user will still want to get back to those activities some time soon, and restarting a stopped activity is far cheaper than starting an activity from scratch. That is because we already have all the objects loaded in memory and simply have to bring it all up to the foreground.

Stopped activities can be removed from memory at any point.

Destroyed state

A destroyed activity is no longer in memory. The Activity Manager decided that this activity is no longer needed and has removed it. Before the activity is destroyed, it can perform certain actions, such as save any unsaved information. However, there’s no guarantee that your activity will be stopped prior to being destroyed. It is possible for a paused activity to be destroyed as well. For that reason, it is better to do important work, such as saving unsaved data, en route to a paused state rather than a destroyed state.


The fact that an activity is in a running state doesn’t mean it’s doing much. It could be just sitting there and waiting for user input. Similarly, an activity in a stopped state is not necessarily doing nothing. The state names mostly refer to how active the activity is with respect to user input, in other words, whether an activity is visible, in focus, or not visible at all.

The best content for your career. Discover unlimited learning on demand for around $1/day.