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 may 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, “Screen where the user can enter a status message”, where the user updates the 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 are going to 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 may even cause our application to stop responding. At that point, we are going to introduce multithreading in Android and explain how to develop an app to work well regardless of external circumstances.

A few things are going to go wrong in this section. This is by design. 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, a basic Android building block. 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 menu system in Android and how it works. You will also learn about Intents and how to send intents to open up a specific activity.

Finally, we’ll learn about the file system on a typical Android device. You will get a deeper understanding how the operating system is put together. 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 the need for any user interface. This will be perfect for Yamba, as we’ll have an update process periodically connect to the cloud 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 grow.

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 take advantage of it. In this section, you will learn how to use SQLite and the API for it. No, 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 our code and make it more streamlined. There will be a good motivation for it at that moment, and the effort will further be rewarded in later chapters.

We’re going to develop this third and final activity in multiple stages. First, we’ll use existing knowledge of 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 won’t be nearly as ready for the prime time since 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.

We’ll tie the data to our user interface using Lists and Adapters.

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

For 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 not available, only to start it again once we’re back online. This goal will introduce us to one type of Broadcast Receivers.

There’s another type of receiver. This one will only exist at certain times. Also, it won’t be receiving messages from the Android system, but from various 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.

So far you knew how to ask for system permissions, such as access to the Internet or file system. In this section we’ll learn how to define our own permissions and how to enforce them. After all, Yamba components may not want to respond to anyone else for some Yamba-specific actions.

Our status data is okay 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 may leverage our friends' timeline in a new and creative way. 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 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 Yamba database via Status Data Content Provider and display it on the Home screen.

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

It turns out that some of the cool features Android services provide 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 regular basis, and for that we’ll use the Alarm service. Additionally, we’ll 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 will prove to be a substantially more elegant solution to our Updater service need.