We are going to start by introducing the Android user interface (UI) model. In its UI, Android is quite different from some other paradigms that you might be familiar with. The unique feature is its dual approach to UI via both Java and XML.

In this chapter, you will learn how to develop the user interface for Figure 5-2, where the user updates her status. Through this process, you will use XML and Java to put together a working UI. You will learn about Layouts and Views, units in Android, how to work with images, and how to make the UI look pretty.

Our approach will focus on best practices in UI development so that your application looks good and works well on any Android device, regardless of screen size and resolution.

Once we have a working screen, we will want to post the user input to the cloud service. For that purpose, we are going to use a third-party library to help us with the Twitter API web service calls.

While making the network calls, you’ll notice that the UI starts behaving sluggishly, due to the unpredictable nature of the network. The network latency might even cause our application to stop responding. At that point, we will introduce multithreading in Android and explain how to develop an app that works well regardless of external circumstances.

A few things are going to go wrong in this section of the book. This is by design, because debugging is a normal part of application development. We’ll show you how to use the Android SDK tools to quickly find and fix problems. Debugging will become second nature to you.

First, we’ll create the screen, which is an activity, one of Android’s basic building blocks. You will see the steps involved and understand what it takes to create new screens.

Next, we’ll need a way to get to that screen. For that purpose, we’ll introduce a menu system in Android and show how it works. You will also learn about intents and how to send these to open up a specific activity.

Finally, we’ll learn about the filesystem on a typical Android device. You will gain a deeper understanding of how the operating system is put together, and you will also learn more about Android security.

Android services are very useful building blocks. They allow a process to run in the background without requiring any user interface. This is perfect for Yamba, as we’ll have an update process connect to the cloud periodically and pull the data. In this section, you will also learn about multithreading considerations as they apply to background services.

At this point, we’ll notice repetition in the code and recognize that our system is no longer as elegant as it could be. So we are going to introduce the Application object as a way to refactor Yamba and make it easier to scale.

Android ships with a built-in database called SQLite. In addition to this cool little database, the Android framework offers a rich API that makes SQLite easier for us to use. In this section, you will learn how to use SQLite and the API for it. You do not have to be an SQL buff to understand what is going on, but some basic understanding of SQL always helps.

At this point, we’ll have yet another opportunity to refactor and streamline our code. There will be a strong motivation for refactoring at that moment, and the effort will be further rewarded in later chapters.

We’re going to develop this third and final activity in multiple stages. First, we’ll use our existing knowledge of the Android UI and put something together. It will work, sort of. Next, we’ll improve on that design. The app will look better, but it still won’t be ready for the prime time because our design won’t be able to handle real-world usage. Finally, we’ll get it right by introducing Lists and Adapters to the mix to use them to tie the data to our user interface.

We’ll have yet another opportunity to refactor our code by introducing a base activity for all our common activity needs. This will give the user a more consistent feel for the app across multiple screens and will make it easier for us to manage the code going forward.

In our example, we want to start our updates when the device is powered up. We also want to stop pulling the data from the cloud when the network is unavailable, and start it again only when we’re back online. This goal will introduce us to one type of broadcast receiver.

This type of receiver will exist only at certain times. Also, it won’t receive messages from the Android system, but from other parts of our own Yamba application. This will demonstrate how we can use receivers to put together loosely coupled components in an elegant and flexible way.

At this point in the development process you know how to ask for system permissions, such as access to the Internet or filesystem. In this section we’ll learn how to define our own permissions and how to enforce them. After all, Yamba components might not want to respond to any other application for some Yamba-specific actions.

Our status data is OK the way it is if nobody else cares about it. But what if we want to expose some of this data to the rest of the system? After all, other applications might leverage our friends’ timelines in new and creative ways. To do that, we’ll create a content provider and expose our status data.

But who will remember to pull up our app? To demonstrate the usefulness of our new status data, we’ll put together an app widget. App widgets are those little components that the user can put on the home screen to see weather updates and such. We’ll create a widget that will pull the latest status update from the Yamba database via the status data content provider and display it on the home screen.

This example will illustrate how system services work in general, and you will walk away understanding some common patterns for using these services. We’ll illustrate building a compass app using sensors, and later, we’ll put this knowledge to use by letting Yamba display the user’s location when posting status updates.

It turns out that some of the cool features provided by Android services can make our Updater service much simpler. So we’ll refactor our code yet again. This time, we’ll introduce Intent Services that respond to intents. But we’re going to need something to fire off these intents on a regular basis, and for that we’ll use the Alarm service. We’ll also add a feature to notify the user of new updates by putting a notification in the notification bar. For that, we’ll use the Notification service. All this refactoring will create a substantially more elegant solution to our Updater service needs.