[Android开发书籍] Oreilly - Learning Android

Learning Android Learning Android Marko Gargenta Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo Learning Android by Marko Gargenta Copyright © 2011 Marko Gargenta. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or corporate@oreilly.com. Editors: Andy Oram and Brian Jepson Production Editor: Holly Bauer Copyeditor: Genevieve d’Entremont Proofreader: Jennifer Knight Indexer: Jay Marchand Cover Designer: Karen Montgomery Interior Designer: David Futato Illustrator: Robert Romano Printing History: March 2011: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Learning Android, the image of a Little Owl, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information con- tained herein. ISBN: 978-1-449-39050-1 [LSI] 1299702297 Table of Contents Preface .................................................................... xiii 1. Android Overview ....................................................... 1 Android Overview 1 Comprehensive 1 Open Source Platform 2 Designed for Mobile Devices 2 History 3 Google’s Motivation 3 Open Handset Alliance 4 Android Versions 4 Summary 5 2. The Stack .............................................................. 7 Stack Overview 7 Linux 7 Portability 7 Security 8 Features 8 Native Libraries 9 Dalvik 9 Android and Java 10 Application Framework 11 Applications 12 The APK 12 Application Signing 12 Application Distribution 12 Summary 13 3. Quick Start ............................................................ 15 Installing the Android SDK 15 v Setting Up a PATH to Tools 16 Installing Eclipse 16 Eclipse Workspace 17 Setting Up Android Development Tools 17 Hello, World 18 Creating a New Project 18 Manifest File 20 Layout XML Code 21 Strings 21 The R File 22 Java Source Code 22 The Emulator 23 An Emulator Versus a Physical Phone 25 Summary 25 4. Main Building Blocks ................................................... 27 What Are Main Building Blocks? 27 A Real-World Example 27 Activities 28 Activity Life Cycle 28 Intents 31 Services 31 Content Providers 32 Broadcast Receivers 34 Application Context 34 Summary 35 5. Yamba Project Overview ................................................ 37 The Yamba Application 37 Design Philosophy 39 Project Design 39 Part 1: Android User Interface 39 Building an Activity 40 Networking and Multithreading 41 Debugging Android Apps 41 Part 2: Preferences, Filesystem, Options Menu, and Intents 41 The Activity 41 Menu System and Intents 42 Filesystem 42 Part 3: Android Services 42 Services 42 Application Object 42 Part 4: Working with Databases 42 vi | Table of Contents SQLite and Android’s Support for It 42 Refactoring the Code Again 43 Part 5: Lists and Adapters 43 Timeline Activity 43 More Refactoring? 43 Part 6: Broadcast Receivers 43 Boot and Network Receivers 44 Timeline Receiver 44 Permissions 44 Part 7: Content Providers 44 Status Data 44 Android Widgets 44 Part 8: System Services 45 Compass and Location 45 Intent Service, Alarms, and Notifications 45 Summary 45 6. Android User Interface . . ................................................ 47 Two Ways to Create a User Interface 47 Declarative User Interface 47 Programmatic User Interface 48 The Best of Both Worlds 48 Views and Layouts 48 LinearLayout 49 TableLayout 50 FrameLayout 50 RelativeLayout 50 AbsoluteLayout 50 Starting the Yamba Project 51 The StatusActivity Layout 52 Important Widget Properties 54 Strings Resource 55 The StatusActivity Java Class 56 Creating Your Application-Specific Object and Initialization Code 56 Compiling Code and Building Your Projects: Saving Files 59 Adding the jtwitter.jar Library 59 Updating the Manifest File for Internet Permission 61 Logging in Android 62 LogCat 62 Threading in Android 65 Single Thread 65 Multithreaded Execution 66 AsyncTask 67 Table of Contents | vii Other UI Events 70 Adding Color and Graphics 74 Adding Images 74 Adding Color 76 Alternative Resources 79 Optimizing the User Interface 80 Hierarchy Viewer 81 Summary 82 7. Preferences, the Filesystem, the Options Menu, and Intents .................. 83 Preferences 83 Prefs Resource 84 PrefsActivity 87 Update the Manifest File 88 The Options Menu 89 The Menu Resource 89 Android System Resources 90 Update StatusActivity to Load the Menu 91 Update StatusActivity to Handle Menu Events 92 Strings Resource 92 Shared Preferences 93 The Filesystem Explained 95 Exploring the Filesystem 95 Filesystem Partitions 96 System Partition 96 SDCard Partition 96 The User Data Partition 97 Filesystem Security 98 Summary 99 8. Services ............................................................. 101 The Yamba Application Object 102 The YambaApplication Class 102 Update the Manifest File 104 Simplifying StatusActivity 105 UpdaterService 105 Creating the UpdaterService Java Class 106 Update the Manifest File 107 Add Menu Items 108 Update the Options Menu Handling 109 Testing the Service 109 Looping in the Service 110 Testing the Service 113 viii | Table of Contents Pulling Data from Twitter 113 Testing the Service 117 Summary 117 9. The Database ........................................................ 119 About SQLite 119 DbHelper 120 The Database Schema and Its Creation 120 Four Major Operations 121 Cursors 122 First Example 122 Update UpdaterService 124 Testing the Service 127 Database Constraints 129 Refactoring Status Data 130 Summary 135 10. Lists and Adapters .................................................... 137 TimelineActivity 137 Basic TimelineActivity Layout 138 Introducing ScrollView 138 Creating the TimelineActivity Class 139 About Adapters 142 Adding a ListView to TimelineActivity 142 Creating a Row Layout 143 Creating an Adapter in TimelineActivity.java 144 TimelineAdapter 146 ViewBinder: A Better Alternative to TimelineAdapter 149 Updating the Manifest File 150 Initial App Setup 152 Base Activity 153 Toggle Service 154 Summary 159 11. Broadcast Receivers ................................................... 161 About Broadcast Receivers 161 BootReceiver 162 Registering the BootReceiver with the AndroidManifest File 162 Testing the Boot Receiver 163 The TimelineReceiver 163 Broadcasting Intents 165 The Network Receiver 167 Adding Custom Permissions to Send and Receive Broadcasts 169 Table of Contents | ix Declaring Permissions in the Manifest File 170 Updating the Services to Enforce Permissions 171 Updating TimelineReceiver to Enforce Permissions 172 Summary 173 12. Content Providers ..................................................... 175 Creating a Content Provider 175 Defining the URI 176 Inserting Data 177 Updating Data 178 Deleting Data 179 Querying Data 179 Getting the Data Type 180 Updating the Android Manifest File 181 Using Content Providers Through Widgets 181 Implementing the YambaWidget class 182 Creating the XML Layout 185 Creating the AppWidgetProviderInfo File 185 Updating the Manifest File 186 Testing the Widget 186 Summary 186 13. System Services ...................................................... 189 Compass Demo 189 Common Steps in Using System Services 190 Getting Updates from the Compass 190 Compass Main Activity 191 Custom Rose Widget 194 Location Service 195 Where Am I? Demo 196 Updating Yamba to Use the Location Service 200 Updating Our Preferences 200 Updating the Yamba Application 201 Updating the Status Activity 202 Intent Service 206 Alarms 208 Adding an Interval to Preferences 209 Updating BootReceiver 210 Sending Notifications 212 Summary 214 14. The Android Interface Definition Language ............................... 215 Implementing the Remote Service 215 x | Table of Contents Writing the AIDL 216 Implementing the Service 217 Implementing a Parcel 218 Registering with the Manifest File 220 Implementing the Remote Client 221 Binding to the Remote Service 221 Testing That It All Works 224 Summary 225 15. The Native Development Kit (NDK) ....................................... 227 What Is and Isn’t the NDK For? 227 Problems Solved by the NDK 227 The Toolchain 228 Packaging Your Libs 228 Documentation and Standardized Headers 228 An NDK Example: Fibonacci 229 FibLib 229 The JNI Header File 231 C Implementation 232 The Makefile 234 Building the Shared Library 234 The Fibonacci Activity 235 Testing That It All Works 236 Summary 237 Index ..................................................................... 239 Table of Contents | xi Preface This book sprang from years of delivering the Marakana Android Bootcamp training class to thousands of software developers at some of the largest mobile companies located on four continents around the world. Teaching this class, over time I saw what works and what doesn’t. This book is a distilled version of the Android Bootcamp training course that I developed at Marakana and fine-tuned over numerous engagements. My background is in Java from back before it was even called that. From the beginning, I was very interested in embedded development as a way to program various devices that surround us in everyday life. Because Java primarily took off in web application development, most of my experience in the previous decade has been in building large enterprise systems. Then Android arrived, and once again I became very excited about building software for nontraditional computers. My current interests lie in using An- droid on devices that may not even resemble a typical phone. This book teaches anyone who knows Java (or a similar language) how to develop a reasonably complex Android application. I hope you find this book fairly comprehen- sive and that you find the example-based learning reasonably motivating. The goal of Learning Android is to get you to think in Android terms. What’s Inside Chapter 1, Android Overview Is an introduction to Android and its history Chapter 2, The Stack Is an overview of the Android operating system and all its parts from a very high level Chapter 3, Quick Start Helps you set up your environment for Android application development Chapter 4, Main Building Blocks Explains the Android components application developers use to put together an app xiii Chapter 5, Yamba Project Overview Explains the Yamba application that we’ll build together through this book and use as an example to learn Android’s various features Chapter 6, Android User Interface Explains how to build the user interface for your application Chapter 7, Preferences, the Filesystem, the Options Menu, and Intents Covers some of the operating system features that make an application developer’s life easier Chapter 8, Services Covers building an Android service to process background tasks Chapter 9, The Database Explains the Android framework’s support for the built-in SQLite database and how to use it to persist the data in your own application Chapter 10, Lists and Adapters Covers an important feature of Android that allows large data sets to be linked efficiently to relatively small screens Chapter 11, Broadcast Receivers Explains how to use the publish-subscribe mechanism in Android to respond to various system and user-defined messages Chapter 12, Content Providers Shows how to design a content provider to share data between applications, in this case using it to enable our app widget to display data on the home screen Chapter 13, System Services Introduces various system services that an app developer can tap into Chapter 14, The Android Interface Definition Language Covers building an inter-process communication mechanism to allow for remote access to a service from another application Chapter 15, The Native Development Kit (NDK) Introduces how to write native C code as part of your Android application Conventions Used in This Book The following typographical conventions are used in this book: Italic Indicates new terms, URLs, email addresses, filenames, and file extensions. Constant width Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, data types, and XML entities. Constant width bold Shows commands or other text that should be typed literally by the user. xiv | Preface Constant width italic Shows text that should be replaced with user-supplied values or by values deter- mined by context. This icon signifies a tip, suggestion, or general note. This icon indicates a warning or caution. Using Code Examples This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission. We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Learning Android by Marko Gargenta (O’Reilly). Copyright 2011 Marko Gargenta, 978-1-449-39050-1.” If you feel your use of code examples falls outside fair use or the permission given here, feel free to contact us at permissions@oreilly.com. Safari® Books Online Safari Books Online is an on-demand digital library that lets you easily search over 7,500 technology and creative reference books and videos to find the answers you need quickly. With a subscription, you can read any page and watch any video from our library online. Read books on your cell phone and mobile devices. Access new titles before they are available for print, get exclusive access to manuscripts in development, and post feed- back for the authors. Copy and paste code samples, organize your favorites, download chapters, bookmark key sections, create notes, print out pages, and benefit from tons of other time-saving features. Preface | xv O’Reilly Media has uploaded this book to the Safari Books Online service. To have full digital access to this book and others on similar topics from O’Reilly and other pub- lishers, sign up for free at http://my.safaribooksonline.com. How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-998-9938 (in the United States or Canada) 707-829-0515 (international or local) 707 829-0104 (fax) We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at: http://oreilly.com/catalog/9781449390501/ To comment or ask technical questions about this book, send email to: bookquestions@oreilly.com For more information about our books, courses, conferences, and news, see our website at http://oreilly.com. Find us on Facebook: http://facebook.com/oreilly Follow us on Twitter: http://twitter.com/oreillymedia Watch us on YouTube: http://www.youtube.com/oreillymedia Acknowledgments This book is truly a result of outstanding teamwork. First, I’d like to thank my editors at O’Reilly, Andy Oram and Brian Jepson. Andy, your comments were spot-on and constructive. Brian, thank you for persuading me to take on writing this book in the first place. I would like to thank all my technical editors: Dan Bornstein, Hervé Guihot, Frank Maker III, and Bill Schrickel. Thank you for diligently reading my half-baked drafts and providing valuable comments. This book wouldn’t be what it is without field testing it on our numerous clients. You were the true pioneers on the cutting edge of Android, and your projects are all very inspiring. Thank you for your trust. xvi | Preface I’d like to thank my team at Marakana—Aleksandar (Saša) Gargenta, Ken Jones, and Laurent Tonon—for bringing back firsthand feedback from teaching Android Boot- camp courses using the draft of this book. Saša, special thanks to you for sending me back to the drawing board more times than I’d like to admit. This book is probably months past due because of your in-depth technical comments. And finally, a huge thanks to my wife, Lisa, and daughter, Kylie. I know what a sacrifice it was for you while I was crisscrossing the world working on this material. Thank you for supporting me along the way. Preface | xvii CHAPTER 1 Android Overview In this chapter, you will learn how Android came about. We’ll take a look at its history to help us understand its future. As this mobile environment enters a make-or-break year, we look at the key players in this ecosystem, what motivates them, and what strengths and weaknesses they bring to the table. By the end of this chapter, you will better understand the ecosystem from a business point of view, which should help clarify the technology choices and how they relate to long-term advantages for various platforms. Android Overview Android is a comprehensive open source platform designed for mobile devices. It is championed by Google and owned by Open Handset Alliance. The goal of the alliance is to “accelerate innovation in mobile and offer consumers a richer, less expensive, and better mobile experience.” Android is the vehicle to do so. As such, Android is revolutionizing the mobile space. For the first time, it is a truly open platform that separates the hardware from the software that runs on it. This allows for a much larger number of devices to run the same applications and creates a much richer ecosystem for developers and consumers. Let’s break down some of these buzz words and see what’s behind them. Comprehensive Android is a comprehensive platform, which means it is a complete software stack for a mobile device. For developers, Android provides all the tools and frameworks for developing mobile apps quickly and easily. The Android SDK is all you need to start developing for An- droid; you don’t even need a physical phone. 1 For users, Android just works right out of the box. Additionally, users can customize their phone experience substantially. For manufacturers, it is the complete solution for running their devices. Other than some hardware-specific drivers, Android provides everything else to make their devices work. Open Source Platform Android is an open source platform. The entire stack, from low-level Linux modules all the way to native libraries, and from the application framework to complete appli- cations, is totally open. More so, Android is licensed under business-friendly licenses (Apache/MIT) so that others can freely extend it and use it for variety of purposes. Even some third-party open source libraries that were brought into the Android stack were rewritten under new license terms. So, as a developer, you have access to the entire platform source code. This allows you to see how the guts of the Android operating system work. As manufacturer, you can easily port Android OS to your specific hardware. You can also add your own propri- etary secret sauce, and you do not have to push it back to the development community if you don’t want to. There’s no need to license Android. You can start using it and modifying it today, and there are no strings attached. More so, Android has many hooks at various levels of the platform, allowing anyone to extend it in unforeseen ways. There are couple of minor low-level pieces of code that are proprietary to each vendor, such as the software stack for the cellular, WiFi, and Bluetooth radios. Android tries hard to abstract those components with interfaces so that vendor-specific code can be managed easily. Designed for Mobile Devices Android is a purpose-built platform for mobile devices. When designing Android, the team looked at which mobile device constraints likely were not going to change for the foreseeable future. For one, mobile devices are battery powered, and battery perform- ance likely is not going to get much better any time soon. Second, the small size of mobile devices means that they will always be limited in terms of memory and speed. These constraints were taken into consideration from the get-go and were addressed throughout the platform. The result is an overall better user experience. Android was designed to run on all sorts of physical devices. Android doesn’t make any assumptions about a device’s screen size, resolution, chipset, and so on. Its core is designed to be portable. 2 | Chapter 1: Android Overview History The history of Android is interesting and offers some perspective on what the future might hold. These are the key events of the past few years: • In 2005, Google buys Android, Inc. The world thinks a “gPhone” is about to come out. • Everything goes quiet for a while. • In 2007, the Open Handset Alliance is announced. Android is officially open sourced. • In 2008, the Android SDK 1.0 is released. The G1 phone, manufactured by HTC and sold by the wireless carrier T-Mobile USA, follows shortly afterward. • 2009 sees a proliferation of Android-based devices. New versions of the operating system are released: Cupcake (1.5), Donut (1.6), and Eclair (2.0 and 2.1). More than 20 devices run Android. • In 2010, Android is second only to Blackberry as the best-selling smart phone platform. Froyo (Android 2.2) is released and so are more than 60 devices that run it. In 2005, when Google purchased Android, Inc., the world thought Google was about to enter the smart phone market, and there were widespread speculations about a de- vice called the gPhone. Google’s CEO, Eric Schmidt, made it clear right away that Android’s ambitions were much larger than a single phone. Instead, they envisioned a platform that would enable many phones and other devices. Google’s Motivation Google’s motivation for supporting the Android project seems to be having Android everywhere and by doing that, creating a level playing field for mobile devices. Ulti- mately, Google is a media company, and its business model is based on selling adver- tising. If everyone is using Android, then Google can provide additional services on top of it and compete fairly. This is unlike the business models of other software vendors who depend on licensing fees. Although Google does license some proprietary apps, such as Gmail and Maps, and makes some money off the Android market, its primary motivation is still the adver- tising revenue that those apps bring in. History | 3 Open Handset Alliance For this to be bigger than just Google, Android is owned by the Open Handset Alliance, a nonprofit group formed by key mobile operators, manufacturers, carriers, and others. The alliance is committed to openness and innovation for the mobile user experience. In practice, the alliance is still very young and many members are still learning to work with each other. Google happens to be putting the most muscle behind the Android project at the moment. The first version of the Android SDK was released without an actual phone on the market. The point of this is that you don’t really need a phone for Android development. There are some exceptions (hardware sensors, telephony, etc.), but for the most part the Android SDK con- tains everything you’ll need for developing on this platform. Android Versions Like any software, Android is improved over time, which is reflected in its version numbers. However, the relationship between different version numbers can be con- fusing. Table 1-1 helps explain that. Table 1-1. Android versions through Android 2.3 Android version API level Nickname Android 1.0 1 Android 1.1 2 Android 1.5 3 Cupcake Android 1.6 4 Donut Android 2.0 5 Eclair Android 2.01 6 Eclair Android 2.1 7 Eclair Android 2.2 8 Froyo (frozen yogurt) Android 2.3 9 Gingerbread Android 2.3.3 10 Gingerbread Android 3.0 11 Honeycomb The Android version number itself partly tells the story of the software platform’s major and minor releases. What is most important is the API level. Version numbers change all the time, sometimes because the APIs have changed, and other times because of minor bug fixes or performance improvements. 4 | Chapter 1: Android Overview As application developers, you will want to make sure you know which API level your application is targeting in order to run. That API level will determine which devices can and cannot run your application. Typically your objective is to have your application run on as many devices as possible. So, with that in mind, try to shoot for an API level that is as low as possible. Keep in mind the distribution of Android versions on real devices out there. Figure 1-1 shows a snapshot of the Android Device Dashboard from mid-2010. Figure 1-1. Historical Android version distribution through January 2011 You may notice that there are not a lot of users of Android 1.5 and 1.6. You may also notice that not a lot of users have the latest and greatest Android 2.3, but the number of 2.x users is growing. This is because everyone with 1.0 and 1.1 got upgraded over the air (OTA) automatically to 1.5. On the other hand, users who still have devices with Android 1.5 and 1.6 likely will never be able to upgrade to 2.x versions. Their older devices do not have the relevant firmware, and most manufacturers are not plan- ning on releasing firmware upgrades as they are busy working on new models. With that in mind, you will probably choose 1.6 or 2.0 as your minimum development target, unless you truly need the features of the latest version. Summary The Android operating system was designed from the ground up to be a comprehensive open source platform for mobile devices. It is a game-changer in the industry and has enjoyed great success. In the next chapter, we’ll take a look at the entire Android operating system at a high level to gain a technical understanding of how all the pieces fit together. Summary | 5 CHAPTER 2 The Stack This is the 9,000-foot overview of the Android platform. Although you’re concerned primarily with writing Android applications, understanding the layout of the system will help shape your understanding about what you can or cannot do easily with Android. By the end of this chapter, you’ll understand how the whole system works, at least from the high level. Stack Overview The Android operating system is like a cake consisting of various layers. Each layer has its own characteristics and purpose. The layers are not cleanly separated but often seep into each other. When you read through this chapter, keep in mind that I am concerned only with the big picture of the entire system and will get into the nitty-gritty details later on. Fig- ure 2-1 shows the parts of the Android stack. Linux Android is built on top of Linux. Linux is a great operating system and the poster child of open source. There are many good reasons for choosing Linux as the base of the Android stack. Some of the main ones are its portability, security, and features. Portability Linux is a portable platform that is relatively easy to compile on various hardware architectures. What Linux brings to Android is a level of hardware abstractions. By basing Android on Linux, we don’t have to worry too much about underlying hardware features. Most low-level parts of Linux have been written in fairly portable C code, which allows for third parties to port Android to a variety of devices. 7 D o wnload from Wow! eBook Figure 2-1. Android stack Security Linux is a highly secure system, having been tried and tested through some very harsh environments over the decades. Android heavily relies on Linux for security. All An- droid applications run as separate Linux processes with permissions set by the Linux system. As such, Android passes many security concerns to the underlying Linux system. Features Linux comes with a lot of very useful features. Android leverages many of them, such as support for memory management, power management, and networking. 8 | Chapter 2: The Stack Native Libraries The native libraries are C/C++ libraries, often taken from the open source community in order to provide necessary services to the Android application layer. Among others, they include: Webkit A fast web-rendering engine used by Safari, Chrome, and other browsers SQLite A full-featured SQL database Apache Harmony An open source implementation of Java OpenGL 3D graphics libraries OpenSSL The secure locket layer Although many of these libraries are used as-is, one notable exception is Bionic, which is basically a rewritten version of the standard C library. Bionic is used for two reasons: Technology To make it purpose-built for tiny, battery-powered devices License To make it license-friendly for others who might want to adopt it and change it GNU libc, the default C library for Linux, is licensed under a GPL li- cense, which requires any changes that you release publicly to be pushed back to the open source community. As such, it might not be the most business-friendly open source license when a company wants to keep their derivative work proprietary. Bionic, on the other hand, is licensed under an Apache/MIT license, which doesn’t require derivative works to be open sourced. Dalvik Dalvik is a purpose-built virtual machine designed specifically for Android, developed by Dan Bornstein and his team at Google. The Java virtual machine (VM) was designed to be a one-size-fits-all solution, and the Dalvik team felt they could do a better job by focusing strictly on mobile devices. They looked at which constraints specific to a mobile environment are least likely to change in the near future. One of these is battery life, and the other is processing power. Dalvik was built from the ground up to address those constraints. Dalvik | 9 Another side effect of replacing the Java VM with the Dalvik VM is the licensing. Whereas the Java language, Java tools, and Java libraries are free, the Java virtual ma- chine is not. This was more of an issue back in 2005 when the work on Dalvik started. Nowadays, there are open source alternatives to Sun’s Java VM, namely the OpenJDK and Apache Harmony projects. By developing a truly open source and license-friendly virtual machine, Android yet again provides a full-featured platform that others are encouraged to adopt for a variety of devices without having to worry about the license. Android and Java In Java, you write your Java source file, compile it into a Java byte code using the Java compiler, and then run this byte code on the Java VM. In Android, things are different. You still write the Java source file, and you still compile it to Java byte code using the same Java compiler. But at that point, you recompile it once again using the Dalvik compiler to Dalvik byte code. It is this Dalvik byte code that is then executed on the Dalvik VM. Figure 2-2 illustrates this comparison between standard Java (on the left) in Android using Dalvik (on the right). Figure 2-2. Java versus Dalvik 10 | Chapter 2: The Stack It might sound like you have to do a lot more work with Android when it comes to Java. However, all these compilation steps are automated by tools such as Eclipse or Ant, and you never notice the additional steps. You may wonder, why not compile straight from Java into the Dalvik byte code? There are a couple of good reasons for the extra steps. Back in 2005, when work on Dalvik started, the Java language was going through frequent changes, but the Java byte code was more or less set in stone. So, the Android team chose to base Dalvik on Java byte code instead of Java source code. A side effect of this is that in theory you could write Android applications in any other language that compiles down to Java byte code. For example, you could use Python or Ruby. I say “in theory” because in practice the appropriate libraries that are part of the SDK would need to be available. But it is likely that the open source community will come up with a solution to that in the future. Another thing to keep in mind is that Android Java is a nonstandard collection of Java classes. Java typically ships in: Java Standard Edition Used for development on basic desktop-type applications Java Enterprise Edition (aka J2EE or JavaEE) Used for development of enterprise applications Java Micro Edition (aka J2ME or JavaME) Java for mobile applications Android’s Java set of libraries is closest to Java Standard Edition. The major difference is that Java user interface libraries (AWT and Swing) have been taken out and replaced with Android-specific user interface libraries. Android also adds quite a few new fea- tures to standard Java while supporting most of Java’s standard features. So, you have most of your favorite Java libraries at your disposal, plus many new ones. Application Framework The application framework is a rich environment that provides numerous services to help you, the app developer, get your job done. This is the best-documented and most extensively covered part of the platform because it is this layer that empowers devel- opers to get creative and bring fantastic applications to the market. In the application framework layer, you will find numerous Java libraries specifically built for Android. You will also find many services (or managers) that provide the eco- system of capabilities your application can tap into, such as location, sensors, WiFi, telephony, and so on. Application Framework | 11 As you explore Android application development, most of your focus will be on this part of the stack, and you will get to use many of the application framework components. Applications And finally, there are the applications that you and other developers create. These applications are what end users find valuable about Android. They can come prein- stalled on the device or can be downloaded from one of the many Android markets. The APK An application is a single application package (APK) file. An APK file roughly has three main components. An API consists of the following major components: Dalvik executable This is all your Java source code compiled down to a Dalvik executable. This is the code that runs your application. Resources Resources are everything that is not code. Your application may contain a number of images and audio/video clips, as well as numerous XML files describing layouts, language packs, and so on. Collectively, these items are the resources. Native libraries Optionally, your application may include some native code, such as C/C++ li- braries. These libraries could be packaged together with your APK file. Application Signing Android applications must be signed before they can be installed on a device. For de- velopment purposes, we’ll be signing our example applications with a debug key—a key that you already have on your development platform. However, when you distrib- ute your application commercially, you’ll want to sign it with your own key. The Android developer document titled “Signing Your Application” has the details. Application Distribution One way in which Android is quite different from other platforms is the distribution of its apps. On most other platforms, such as iPhone, a single vendor holds a monopoly over the distribution of applications. On Android, there are many different stores, or markets. Each market has its own set of policies with respect to what is allowed, how the revenue is split, and so on. As such, Android is much more of a free market space in which vendors compete for business. 12 | Chapter 2: The Stack In practice, the biggest market currently is Android Market, run by Google. It is unclear whether Google means to just seed the market space while other stores develop or plans to make it a profitable venture. Applications can also be distributed via the Web. When you download an APK file from a website through the browser, the application represented by the APK file is installed automatically on your phone. What about viruses, malware, spyware, and other bad things? With its decentralized application distribution system, it is certainly possible for an unsuspecting user to download a malicious app that consequently does bad things. For example, there have been reports of phishing attacks via fake banking apps. So, Android leaves it to the marketplace to sort it out. Eventually, there will be stores that are more reputable and those that are less so, at least in theory. Google relies on user reports for policing its Android Market, but other stores may choose to do more proactive testing and raise the bar on what gets into the store in the first place. Summary In this chapter, you got a big-picture overview of what comprises the Android operating system and how its various pieces fit together. You now understand what makes An- droid so complete, open, and attractive to developers. In the next chapter, we’ll look at how to set up your development environment so you can get up to speed quickly. We’ll also look at a simple Hello World application and dissect it to help you understand the various pieces of an Android application. Summary | 13 CHAPTER 3 Quick Start In this chapter, you will learn how to set up your environment for Android develop- ment. I’ll go beyond just listing where you can download the software, and will cover some of the best practices in getting set up. I’ll look at development operating system choices as well as the Android tools available. You will see the good, the bad, and the ugly of the various tool and platform choices that you’re about to make (or that some- one else has already made for you). By the end of this chapter, you will have your entire development environment set up. You’ll be able to write a Hello World application, build it, and run it on the emulator (or a physical device, if you want). I’m going to use ~ to refer to your home directory. On Mac OS X, that’s typically something like /Users/marko. On Linux, it would be /home/ marko, and on Windows Vista and 7, C:\Users\marko (in Windows XP, it would be C:\Documents and Settings\marko). Also, I’m going to use Unix-style forward slashes and not Windows backslashes to denote file path separators. So, if you’re on Windows, just change ~ to C:\Users\YourUserName and / to \. Other than that, everything should be pretty much for different operating systems, regardless of whether you use OS X, Linux, or Windows. Installing the Android SDK The Android Software Development Kit (SDK) is all you need to develop applications for Android. The SDK comes with a set of tools as well as a platform to run it and see it all work. You can download the Android SDK for your particular platform from the Android SDK Download page. 15 Once you download it, unzip (or on Linux, untar) it into a folder that is easy to get to. Further examples in the book will assume your SDK is in the folder ~/android-sdk. If it’s in a different location, use that location instead of ~/android-sdk. For example: Windows C:\apps\android-sdk-windows Linux /home/YourUserName/android-sdk-linux_86 Mac OS X /Users/YourUserName/android-sdk-mac_86 For Windows users, I strongly recommend choosing directories without spaces in them. This is because we’ll be doing work on the command line and spaces just complicate things. Because the Windows XP home directory is in C:\Documents and Settings, I would recommend putting android-sdk in a top-level directory that you create, such as C:\apps. However, on Windows Vista or 7, you can simply extract android-sdk into C:\Users\YourUserName. Setting Up a PATH to Tools The Android SDK has a folder that contains all its major tools. Since we’re going to use these tools from the command line, it is very helpful to add your ~/android-sdk/tools/ and your ~/android-skd/platform-tools/ directories to your system PATH variable. This will make it easier to access your tools without having to navigate to their specific location every single time. Details for setting up the PATH variable depend on the platform; see step 2 of the docu- ment “Installing Android SDK”. Installing Eclipse Eclipse is an open source collection of programming tools originally created by IBM for Java. Nowadays, most developers in the Java community favor Eclipse as their Integrated Development Environment (IDE) of choice. Eclipse lives at http://eclipse.org. Eclipse has a lot of time-saving features, which I’ll be pointing out as we continue. Keep in mind that, although powerful, Eclipse tends to be very resource-hungry, and so you might want to restart it once a day if it starts running sluggishly. Although you can do Android development with any favorite text editor or integrated development environment (IDE), most developers seem to be using Eclipse, and thus that’s what I use in this book. 16 | Chapter 3: Quick Start If you choose not to use Eclipse, please refer to “Developing in Other IDEs”. Download Eclipse at http://www.eclipse.org/downloads/. I recommend Eclipse IDE for Java Developers (not the twice-as-large Eclipse for Java EE Developers). You can install it in any directory you’d like. Eclipse Workspace Eclipse organizes all your work by projects. Projects are placed in a workspace, which is a location you choose. So, where you put your workspace is significant. I recommend ~/workspace as a simple place for your code. On Windows, however, I recommend storing your workspace in a directory that doesn’t have spaces in it (they complicate anything you might do at the command line). C:\workspace is a good choice for Win- dows users. Setting Up Android Development Tools You also need to set up Android Tools for Eclipse. The instructions are: 1. Start Eclipse, then select Help→Install New Software (see Figure 3-1). 2. In the Available Software dialog, click Add. 3. In the Add Site dialog that appears, enter a name for the remote site (for example, “Android Plugin”) in the “Name” field. 4. In the “Location” field, enter this URL: https://dl-ssl.google.com/android/ eclipse/. 5. Click OK. 6. Back in the Available Software view, you should now see “Developer Tools” added to the list. Select the checkbox next to Developer Tools, which will automatically select the nested tools Android DDMS and Android Development Tools. Click Next. 7. In the resulting Install Details dialog, the Android DDMS and Android Develop- ment Tools features are listed. Click Next to read and accept the license agreement and install any dependencies, then click Finish. 8. Restart Eclipse. If you have trouble downloading the plug-in, you can try using “http” in the URL instead of “https” (https is preferred for security reasons). Installing the Android SDK | 17 Hello, World To make sure everything is set up properly, we’re going to write a simple Hello World program. As a matter of fact, there’s not much for us to write, but a lot to understand. This is because Eclipse will create the project shell for us from some predefined templates. Creating a New Project In Eclipse, choose File→New→Android Project. Sometimes (especially the first time you run Eclipse) the Android tools may not be appear there right away. They should show up in the future after you’ve used them for the first time. If Android Project is not an option under File→New, choose Other and look for Android Project in there. Figure 3-1. Install new software 18 | Chapter 3: Quick Start D o wnload from Wow! eBook In the new project dialog window, fill out the following: 1. “Project name” is an Eclipse construct. Eclipse organizes everything into projects. A project name should be one word. I like to use the CamelCase naming convention here. Go ahead and type HelloWorld. 2. Next, you need to choose the build target. The build target tells the build tools which version of the Android platform you are building for. In here you should see a list of available platforms and add-ons you have installed as part of your SDK. Go ahead and pick one of the newer ones, such as Android 2.2 (but don’t choose the targets named Google APIs—those are Google’s proprietary extensions to the Android platform). For our purposes, we’ll stick to Android Open Source versions of the Android platform. 3. You need to fill out your project properties next. The application name is the plain English name of your application. Go ahead and enter something like Hello, World!!!. 4. The package name is a Java construct. In Java, all source code is organized into packages. Packages are important because, among other things, they specify the visibility of objects between the various Java classes in your project. In Android, packages are also important for application signing purposes. Your package name should be the reverse of your domain name with optional subdomains. I might use com.example.calculator if I were building a calculator app and my domain name was example.com. I’m going to be using com.marakana for my package name here. 5. You can optionally specify an activity. I haven’t covered activities yet (you’ll learn about them in Chapter 6), but think of them as corresponding to the various screens in your application. An activity is going to be represented by a Java class, and therefore its name should adhere to Java class naming conventions: start with an upper-case letter and use CamelCase to separate words. So, type HelloWorld for your activity name. 6. The minimum SDK version is the minimum version of Android—as represented by API level—that is required for the device to run this application. You want this number to be as low as possible so that your app can run on as many devices as possible. I’m going to put 8 here to represent Android 2.2, which I know I have installed. Finally, click on the Finish button, and Eclipse will create your project. Let’s look at the various files that this process created in Figure 3-2. Hello, World | 19 Figure 3-2. HelloWorld new project window Manifest File The manifest file glues everything together. It is this file that explains what the appli- cation consists of, what all its main building blocks are, what permissions it requires, and so on (see Example 3-1). 20 | Chapter 3: Quick Start Example 3-1. AndroidManifest.xml Layout XML Code The layout file specifies the layout of your screen. In this case, shown in Example 3-2, we have only one screen, and it’s loaded by the HelloWorld.java code seen in Exam- ple 3-5. Example 3-2. res/layout/main.xml Strings This is another XML file that contains all the text that your application uses. For ex- ample, the names of buttons, labels, default text, and similar types of strings go into this file. This is the best practice for separating the concerns of various files, even if they are XML files. In other words, layout XML is responsible for the layout of widgets, but strings XML is responsible for their textual content (see Example 3-3). Example 3-3. res/values/strings.xml Hello World, HelloWorld! Hello, World!!! Hello, World | 21 The R File The R file is the glue between the world of Java and the world of resources (see Exam- ple 3-4). It is an automatically generated file, and as such, you never modify it. It is recreated every time you change anything in the res directory, for example, when you add an image or XML file. You don’t need to look at this file much. We will use the data in it quite a bit, but we’ll use Eclipse to help us refer to values stored in this file. Example 3-4. gen/com/marakana/R.java /* AUTO-GENERATED FILE. DO NOT MODIFY. * * This class was automatically generated by the * aapt tool from the resource data it found. It * should not be modified by hand. */ package com.marakana; public final class R { public static final class attr { } public static final class drawable { public static final int icon=0x7f020000; } public static final class layout { public static final int main=0x7f030000; } public static final class string { public static final int app_name=0x7f040001; public static final int hello=0x7f040000; } } Java Source Code The Java code is what drives everything. This is the code that ultimately gets converted to a Dalvik executable and runs your application (see Example 3-5). Example 3-5. HelloWorld.java package com.marakana; import android.app.Activity; import android.os.Bundle; public class HelloWorld extends Activity { /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); 22 | Chapter 3: Quick Start setContentView(R.layout.main); } } The Emulator Running your application on a physical device versus an emulated device is pretty much the same thing. That is because the emulator is an actual code emulator, meaning it runs the same code base as the actual device, all the way down to the machine layer. A simulator and an emulator sound very similar, but are fundamentally different. To emulate means to imitate the machine executing the binary code. So, an emulator is sort of like a virtual machine. A simulator merely simulates the behavior of the code at a higher level. Android SDK ships with a true emulator, based on QEMU. To use the emulator, we’ll have to create an Android Virtual Device (AVD). The easiest way to do that is to start the android tool via Eclipse. To create a new AVD, start the tool called Android SDK and AVD Manager (see Fig- ure 3-3). You can start this tool from Eclipse by clicking on the icon or via the command line by starting the tool called android, which is located in your SDK/tools directory. Figure 3-3. Android SDK and AVD Manager From within the Android SDK and AVD Manager window, choosing “New…” pops up a Create New AVD dialog window (see Figure 3-4). In this dialog, you specify the The Emulator | 23 parameters for your new AVD. The name can be any name you choose. The target designates which version of Android you want installed on this particular AVD. The list of possible targets is based on platforms and add-ons that you have installed into your SDK. If you don’t have any targets, go back to the Android SDK and AVD Manager window and choose the “Available packages” tab to install at least one platform, for example, Android 2.3 - API level 9. Each AVD can have an SD card. You can just specify a number here for your built-in card, in megabytes. The skin is the look and feel of your device as well as its form factor. The Hardware option lets you fine-tune what this AVD does and doesn’t support. Figure 3-4. New AVD dialog Once you are done with this dialog, you will have an AVD in your list. Go ahead and start it, and an emulator will pop up (see Figure 3-5). 24 | Chapter 3: Quick Start Figure 3-5. Emulator An Emulator Versus a Physical Phone For the most part, running your application on the emulator is identical to running it on a physical phone. There are some notable exceptions, mostly things that are just hard to virtualize, such as sensors. Other hardware-related features such as telephony and location services, can be simulated in the emulator. Summary Setting up the Android development environment basically involves setting up Android SDK and Eclipse. Once you have set up your development environment, a good way to test that everything is working is to use Eclipse to create a simple Hello World project and run it in the emulator. If that runs fine, you are almost certain that your system is set up and ready for further development. Summary | 25 CHAPTER 4 Main Building Blocks In this chapter, you will learn about the big blocks in Android. We’ll give you a high- level overview of what activities are, how intents work, why services are cool, how to use broadcast receivers and content providers to make your app scale, and much more. By the end of this chapter, you will understand the main Android components for building applications. You should conceptually know when you’d use what compo- nent. You will also see how these components relate to a real-world application. What Are Main Building Blocks? The main building blocks are components that you use as an application developer to build Android apps. They are the conceptual items that you put together to create a bigger whole. When you start thinking about your application, it is good to take a top- down approach. You design your application in terms of screens, features, and the interactions between them. You start with conceptual drawing, something that you can represent in terms of “lines and circles.” This approach to application development helps you see the big picture—how the components fit together and how it all makes sense. A Real-World Example Let’s say that we want to build a Twitter app. We know that the user should be able to post status updates. We also know the user should be able to see what her friends are up to. Those are basic features. Beyond that, the user should also be able to set her username and password in order to log into her Twitter account. So, now we know we should have these three screens. Next, we would like this app to work quickly regardless of the network connection or lack thereof. To achieve that, the app has to pull the data from Twitter when it’s online and cache the data locally. That will require a service that runs in the background as well as a database. 27 We also know that we’d like this background service to be started when the device is initially turned on, so by the time the user first uses the app, there’s already up-to-date information on her friends. So, these are some straightforward requirements. Android building blocks make it easy to break them down into conceptual units so that you can work on them independently, and then easily put them together into a complete package. Activities 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, 28 | Chapter 4: Main Building Blocks 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. 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. Activities | 29 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. 30 | Chapter 4: Main Building Blocks D o wnload from Wow! eBook Intents Intents are messages that are sent among the major building blocks. They trigger an activity to start up, tell a service to start or stop, or are simply broadcasts. Intents are asynchronous, meaning the code that sends them doesn’t have to wait for them to be completed. An intent could be explicit or implicit. In an explicit intent, the sender clearly spells out which specific component should be on the receiving end. In an implicit intent, the sender specifies the type of receiver. For example, your activity could send an intent saying it simply wants someone to open up a web page. In that case, any application that is capable of opening a web page could “compete” to complete this action. When you have competing applications, the system will ask you which one you’d like to use to complete a given action. You can also set an app as the default. This mechanism works very similarly to your desktop environment, for example, when you downloaded Firefox or Chrome to replace your default Internet Explorer or Safari web browsers. This type of messaging allows the user to replace any app on the system with a custom one. For example, you might want to download a different SMS application or another browser to replace your existing ones. Figure 4-2 shows how intents may be used to “jump” between various activities, in the same application or in another app altogether. Figure 4-2. Intents Services Services run in the background and don’t have any user interface components. They can perform the same actions as activities, but without any user interface. Services are useful for actions that we want to perform for a while, regardless of what is on the Services | 31 screen. For example, you might want your music player to play music even as you are flipping between other applications. Don’t confuse the Android services that are part of an Android app with native Linux services, servers, or daemons, which are a much lower-level component of the operating system. Services have a much simpler life cycle than activities (see Figure 4-3). You either start a service or stop it. Also, the service life cycle is more or less controlled by the developer, and not so much by the system. Consequently, we as developers have to be mindful to run our services so that they don’t consume shared resources unnecessarily, such as the CPU and battery. Figure 4-3. Service life cycle The fact that a service runs in the background doesn’t mean it runs on a separate thread. If a service is doing some processing that takes a while to complete (such as performing network calls), you would typically run it on a separate thread. Otherwise, your user interface will run notice- ably slower. In other words, services and activities run on the same main application thread, often called the UI thread. Content Providers Content providers are interfaces for sharing data between applications. By default, An- droid runs each application in its own sandbox so that all data that belongs to an application is totally isolated from other applications on the system. Although small amounts of data can be passed between applications via intents, content providers are much better suited for sharing persistent data between possibly large datasets. As such, the content provider API nicely adheres to the CRUD principle. Figure 4-4 illustrates how the content provider’s CRUD interface pierces the application boundaries and allows other apps to connect to it to share data. 32 | Chapter 4: Main Building Blocks The Android system uses this mechanism all the time. For example, Contacts Provider is a content provider that exposes all user contact data to various applications. Settings Provider exposes system settings to various applications, including the built-in Settings application. Media Store is responsible for storing and sharing various media, such as photos and music, across various applications. Figure 4-5 illustrates how the Contacts app uses Contacts Provider, a totally separate application, to retrieve data about users’ contacts. The Contacts app itself doesn’t have any contacts data, and Contacts Provider doesn’t have any user interface. Figure 4-5. Contacts application using Contacts Provider to get the data Figure 4-4. Content provider Content Providers | 33 This separation of data storage and the actual user interface application offers greater flexibility to mash up various parts of the system. For example, a user could install an alternative address book application that uses the same data as the default Contacts app. Or, he could install widgets on the Home screen that allow for easy changes in the System Settings, such as turning on or off the WiFi, Bluetooth, or GPS features. Many phone manufactures take advantage of content providers to add their own applications on top of standard Android to improve overall user experience, such as HTC Sense. Content providers are relatively simple interfaces, with the standard insert(), update(), delete(), and query() methods. These methods look a lot like standard da- tabase methods, so it is relatively easy to implement a content provider as a proxy to the database. Having said that, you are much more likely to use content providers than write your own. Broadcast Receivers Broadcast receivers are Android’s implementation of a system-wide publish/subscribe mechanism, or more precisely, an Observer pattern. The receiver is simply dormant code that gets activated once an event to which it is subscribed happens. The system itself broadcasts events all the time. For example, when an SMS arrives, a call comes in, the battery runs low, or the system gets booted, all those events are broadcasted, and any number of receivers could be triggered by them. In our Twitter app example, we want to start the update service once the system starts up. To do that, we can subscribe to the broadcast that tells us the system has completed booting up. You can also send your own broadcasts from one part of your application to another, or to a totally different application. Broadcast receivers themselves do not have any visual representation, nor are they ac- tively running in memory. But when triggered, they get to execute some code, such as starting an activity, a service, or something else. Application Context So far you have seen activities, services, content providers, and broadcast receivers. Together, they make up an application. Another way of saying this is that they live inside the same application context. Application context refers to the application environment and the process within which all its components are running. It allows applications to share the data and resources between various building blocks. An application context gets created whenever the first component of this application is started up, regardless of whether that component is an activity, service, or something 34 | Chapter 4: Main Building Blocks else. Application context lives as long as your application is alive. As such, it is inde- pendent of the activities life cycle. You can easily obtain a reference to the context by calling Context.getApplicationContext() or Activity.getApplication(). Keep in mind that activities and services are already subclasses of context, and as such they inherit all its methods. Summary In this chapter, you learned about some of the most important Android application components. We put together these components to create various applications, from a simple Hello World to much more complex creations. In the next chapter, we’ll outline a Yamba application as an example of how all these bits and pieces come together to form a working Android app. Summary | 35 CHAPTER 5 Yamba Project Overview The best way to learn is by an example, and that example has to meet certain criteria. After working with thousands of new Android developers and using various example applications to explain some of the unique concepts that this platform has to offer, I concluded that the best example has to be: Comprehensive A good example app should demonstrate most of the aspects of the application framework that are unique to Android. Additionally, there should be a good reason to use a specific feature in order to get the job done. This is important in order to create the right motivation for those new to Android. Familiar The example application should be simple to understand. We want to focus on design and implementation, and not on features and benefits. The Yamba Application The application I picked for this book is a Twitter-like application. We call it Yamba, which stands for Yet Another Micro Blogging App. Yamba lets a user connect to a service such as Twitter, pull down friends’ statuses, and update that user’s own status. Yamba covers most of the main Android building blocks in a natural way. As such, it’s a great sample application to illustrate both how various components work individually and how they fit together. Services such as Twitter are more or less familiar to most people, so the features of the application do not require much explanation. Figures 5-1 through 5-3 show what a finished product could look like. 37 Figure 5-1. List of status messages from other people, called a timeline Figure 5-2. Screen where the user can enter a status message Figure 5-3. User preferences 38 | Chapter 5: Yamba Project Overview D o wnload from Wow! eBook Figure 5-1 shows how Yamba displays a list of status messages from your friends. Figure 5-2 shows the initial Yamba screen, and Figure 5-3 shows the user preferences. Design Philosophy We’re going to adopt a certain design philosophy in tackling this project. This philos- ophy will help guide us in our development and serve as a north star when in doubt about what to do next. Spelling out the design philosophy here should also help elim- inate some confusion in the process we’re following: Small increments The Yamba application will start out small and will constantly grow in functionality and complexity. Initially, the app will not do much, but it will grow organically one step at a time. Along the way, we’ll explain each step so that you’re expanding your skills as you go. Always whole and complete The application must always work. In other words, we’ll add new features in small, self-contained chunks and pull them back into the main project so that you can see how it fits together as a whole. The application must always work at each stopping point. Refactoring code Once in a while, we’ll have to take a step back and refactor the application to remove duplicate code and optimize the design. The goal is to reuse the code and not reinvent the wheel. But we are going to cross those bridges as we get to them, providing the motivation for refactoring along the way. This process will teach you about some general software development best practices as well. Project Design If you remember from Chapter 4, an Android application is a loose collection of activ- ities, services, content providers, and broadcast receivers. These are the components from which we put together an application. Figure 5-4 shows the design of the entire Yamba application, which incorporates most of the main Android building blocks. Part 1: Android User Interface This part, covered in Chapter 6, will focus on developing the first component of the Yamba application: the Status Update screen. Our tasks are building an activity, net- working and multithreading, and debugging. Part 1: Android User Interface | 39 Building an Activity 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. Figure 5-4. Yamba design diagram 40 | Chapter 5: Yamba Project Overview 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. Networking and Multithreading 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. Debugging Android Apps 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. Part 2: Preferences, Filesystem, Options Menu, and Intents This part, covered in Chapter 7, is all about the preferences screen. At the end of this part, your Yamba application will have two screens, one for status updates and the other for setting up the preferences. At this point, Yamba is configurable for various users and starts being a useful app. The elements we’ll create at this stage are the activity, the menu system and intents, and the filesystem. The Activity 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. Part 2: Preferences, Filesystem, Options Menu, and Intents | 41 Menu System and Intents 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. Filesystem 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. Part 3: Android Services In this part, covered in Chapter 8, introduces background services. By the end of this part, your Yamba application will be able to periodically connect to the cloud and pull down your friends’ status updates. Services 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 back- ground services. Application Object 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. Part 4: Working with Databases We now have the data from our updater service but still need a place to store it. In this part, covered in Chapter 9, we’ll introduce you to Android’s support for databases. By the end of that chapter, our data from the cloud will be persisted in the database. SQLite and Android’s Support for It 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 42 | Chapter 5: Yamba Project Overview have to be an SQL buff to understand what is going on, but some basic understanding of SQL always helps. Refactoring the Code Again 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. Part 5: Lists and Adapters It might sound like we’re back in UI mode, but Lists and Adapters are more organiza- tional aids than user interface elements in Android. They form very powerful compo- nents that allow our tiny UI to connect to very large datasets in an efficient and scalable manner. In other words, users will be able to use Yamba in the real world without any performance hits in the long run. Currently the data is all there in the database, but we have no way to view it. In this part, covered in Chapter 10, the Yamba application will get the much-needed Timeline Activity and a way for the user to see what his friends are chatting about online. Timeline Activity 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. Finally, we’ll get it right by introducing Lists and Adapters to the mix and use them to tie the data to our user interface. More Refactoring? 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. Part 6: Broadcast Receivers In this part, covered in Chapter 11, we’ll equip Yamba with receivers so it can react to events around it in an intelligent way. For that purpose, we’ll use broadcast receivers. Part 6: Broadcast Receivers | 43 Boot and Network Receivers 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 broad- cast receiver. Timeline 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. Permissions 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. Part 7: Content Providers In this part, covered in Chapter 12, we’ll revisit content providers and refactor our database code to use them. To demonstrate that it all works, we’ll throw in an Android App Widget. Status Data 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. Android Widgets 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. 44 | Chapter 5: Yamba Project Overview Part 8: System Services The Android OS comes with many useful system services, which include processes you can access easily to ask for things such as your location, sensor readings, WiFi hotspots, and much more. In this part, covered in Chapter 13, you will add some cool new features to Yamba, such as the user’s current location. Compass and Location 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. Intent Service, Alarms, and Notifications 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. Summary This chapter is intended as a road map for the next eight chapters. By the end of all these iterations, you will have built a medium-size Android app from scratch. Even more, you will understand various constructs and how to put them together into a meaningful whole. The hope is that you’ll start developing a way of thinking in Android. Summary | 45 CHAPTER 6 Android User Interface In this chapter, you will learn how to build a user interface in Android. You will create your first Activity, learn how to create an XML layout for it, and see how to connect it to Java. You will learn about Views (aka widgets) and Layouts, and learn how to handle Java events, such as button clicks. Additionally, you’ll add support for a Twitter-like API into your project as an external .jar file so your app can make web service calls to the cloud. By the end of this chapter, you will have written your own Twitter-like Android app. The app will feature a single screen that will prompt the user for her current status update and post that update online. Two Ways to Create a User Interface There are two ways to create a user interface (UI) in Android. One is declarative, and the other one is programmatic. They are quite different but often are used together to get the job done. Declarative User Interface The declarative approach involves using XML to declare what the UI will look like, similar to creating a web page using HTML. You write tags and specify elements to appear on your screen. If you have ever handcoded an HTML page, you did pretty much the same work as creating an Android screen. One advantage of the declarative approach is that you can use what-you-see-is-what- you-get (WYSIWYG) tools. Some of these tools ship with the Eclipse Android Devel- opment Tools (ADT) extension, and others come from third parties. Additionally, XML is fairly human-readable, and even people who are unfamiliar with the Android plat- form and framework can readily determine the intent of the user interface. 47 D o wnload from Wow! eBook The disadvantage of a declarative UI approach is that you can get only so far with XML. XML is great for declaring the look and feel of your user interface, but it doesn’t provide a good way of handling user input. That’s where the programmatic approach comes in. Programmatic User Interface A programmatic user interface involves writing Java code to develop UI. If you have ever done any Java AWT or Java Swing development, Android is pretty much the same in that respect. It is similar to many UI toolkits in other languages as well. Basically, if you want to create a button programmatically, you have to declare the button variable, create an instance of it, add it to a container and set any button prop- erties that may make sense, such as color, text, text size, background, and so on. You probably also want to declare what the button does once it’s clicked, so that’s another piece of code. All in all, you end up writing quite a few lines of Java. Everything you can do declaratively, you can also do programmatically. But Java also allows you to specify what happens when that button is actually clicked. This is the main advantage of a programmatic approach to the user interface. The Best of Both Worlds So which approach to use? The best practice is to use both. You would use a declarative (XML) approach to declare everything about the user interface that is static, such as the layout of the screen, all the widgets, etc. You would then switch to a programmatic (Java) approach to define what goes on when the user interacts with the various widgets in the user interface. In other words, you’d use XML to declare what the “button” looks like and Java to specify what it does. Note that there are two approaches to developing the actual user inter- face, but at the end of the day, all the XML is actually “inflated” into Java memory space as if you actually wrote Java code. So, it’s only Java code that runs. Views and Layouts Android organizes its UI elements into layouts and views. Everything you see, such as a button, label, or text box, is a view. Layouts organize views, such as grouping together a button and label or a group of these elements. If you have prior experience with Java AWT or Swing, layouts are similar to Java con- tainers and views are similar to Java components. Views in Android are sometimes referred to as widgets. 48 | Chapter 6: Android User Interface Don’t confuse widgets in the Android UI with App Widgets. The latter are miniature application views that can be embedded in other appli- cations (such as the Home screen application). Here, we are referring to widgets as the views in our activities. So, a layout can contain other children. Those children can furthermore be layouts themselves, allowing for a complex user interface structure. A layout is responsible for allocating space for each child. Different layouts use different approaches to laying out their child widgets, as shown in Figure 6-1. Figure 6-1. Layouts and Views relationship There are several main layouts that we use more frequently than others, such as LinearLayout, TableLayout, FrameLayout, RelativeLayout, and AbsoluteLayout. LinearLayout LinearLayout is one of the simplest and most common layouts. It simply lays out its children next to each other, either horizontally or vertically. The order of the children matters. As LinearLayout asks its children how much space they need, it allocates the desired space to each child in the order they are added. So, if an “older” child comes along and asks for all the space on the screen, there won’t be much left for the subse- quent widgets in this layout. One important property for LinearLayout is layout_orientation. Its valid options are vertical or horizontal. Views and Layouts | 49 Although Linear Layout is probably the simplest and most commonly used layout, it is not always the best choice. A good rule of thumb is that if you start to nest multiple Linear Layouts, you should probably use a different layout, such as Relative Layout. Too many nested layouts can have major consequences on the time needed to inflate the UI and on overall CPU and battery consumption. TableLayout TableLayout lays out its children in a table and consists of only other TableRow widg- ets. TableRow represents a row in a table and can contain other UI widgets. TableRow widgets are laid out next to each other horizontally, sort of like LinearLayout with a horizontal orientation. For those familiar with HTML, Table Layout is similar to the element, and Table Row is similar to the element. Whereas in HTML we also have
to represent each cell in the table, in Android the columns are determined dynamically based on the number of views we add to a table row. An important property for TableLayout is stretch_columns, indicating which column of the table to stretch. You can also use * to stretch all columns. FrameLayout FrameLayout places its children on top of each other so that the latest child is covering the previous, like a deck of cards. This layout policy is useful for tabs, for example. FrameLayout is also used as a placeholder for other widgets that will be added pro- grammatically at some later point in time. RelativeLayout RelativeLayout lays out its children relative to each other. As such, it is very powerful because it doesn’t require you to nest unnecessary layouts to achieve a certain look. At the same time, using RelativeLayout can minimize the total number of widgets that need to be drawn, thus improving the overall performance of your application. Having said that, RelativeLayout requires each of its child views to have an ID set so that we can position it relative to other children. AbsoluteLayout AbsoluteLayout positions its children at absolute coordinates on the screen. It is the favorite layout for WYSIWYG tools, and although it is very simple, it is not very flexible. Your user interface would look good on one particular screen, but as soon as the screen size, orientation, or density changed, AbsoluteLayout would not be able to adjust. 50 | Chapter 6: Android User Interface Starting the Yamba Project We are about to start our Yamba project. So, fire up Eclipse and click on File→New→Android Project. You will get a dialog window asking you about your new Android project (see Fig- ure 6-2). Let’s explain again all the significant fields: Project name The name under which Eclipse organizes our project. It is a good idea not to use any spaces in your project name. This makes it easier to access from the command line later. Enter “Yamba” here. Contents Leave this as is—set to creating a new project—since that’s what we intend to do. Build Target This field indicates the type of Android system we intend to run this application on. This could be any Android platform, either standard or proprietary. I assume we’re working with Android 2.3 (API level 9) and thus will choose the Android 2.3 option. Application name Simply a plain-text name for your application. It can be any text. For our app, feel free to enter “Yamba”. Package name This field designates a Java package, and as such it needs to adhere to Java package naming conventions. In a nutshell, you want to use the reverse of your domain name for your package. I’m going to use “com.marakana.yamba” here. Create Activity An option to create an activity as part of this project. You can leave it checked. For the activity name, we must adhere to Java class naming conventions. Doing that simply means using upper CamelCase. I’m going to enter “StatusActivity” here. Min SDK Version Represents the minimum version of Android SDK that must be installed on the device for it to run this particular application. Typically, this number will corre- spond to the API level that you picked for your target, in our case, Android 9. However, if the app doesn’t depend on the latest and greatest API or is capable of scaling gracefully to a lower API, you should rethink this number. In our case, the app will be able to work on API level 4 (Android 1.6), so enter 4 here. This is a good choice because we can distribute our app to way more people than if the minimum were Android 2.3. Click on Finish. Your Yamba project should now appear in Eclipse’s Package Explorer. Starting the Yamba Project | 51 The StatusActivity Layout Let’s start by designing the user interface for our screen where we’ll enter the new status and click a button to update it. By default, Eclipse created a file called main.xml under the res/layout folder. For con- sistency purposes, we should rename this file to status.xml to match our StatusActivity. Figure 6-2. New project dialog 52 | Chapter 6: Android User Interface To rename a file in Eclipse, right-click on it, choose Refactor→Rename…, and enter the new name. Eclipse is somewhat smart about renaming files and does more than just change the name. It also offers to look up all references to this file and update those as well. Although this feature works well when renaming a Java file, it is not fully auto- matic with XML files. So, renaming this file requires us to change the line in Java where we refer to it via the R class. To do that, in your StatusActivity’s onCreate(), change setContentView(R.layout.main); to setContentView(R.layout.status);. This screen will have four components: • A title at the top of the screen. This will be a TextView widget. • A big text area to type our 140-character status update. We’ll use an EditText widget for this purpose. • A button to click to update the status. This will be a Button widget. • A layout to contain all these widgets and lay them out one after another in a vertical fashion. For this screen, we’ll use LinearLayout, one of the more common ones. Example 6-1 contains the source code for our StatusActivity layout. Example 6-1. res/layout/status.xml This code was generated by Eclipse Graphical Layout, shown in Figure 6-3. Android Development Tools (ADT) for the Eclipse plug-in provides this to help you work with Android-specific XML files. Since ADT knows that you are working on a UI layout, it opens status.xml in Graphical Layout mode. You can also view the raw XML by choos- The StatusActivity Layout | 53 ing the status.xml tab at the bottom of this window. That will give you the XML source code for this screen, as displayed in this example. Figure 6-3. Graphical Layout mode for status.xml Although we discussed the basic meanings of these XML resources in a previous chap- ter, there are some details in the code that you should know more about, which we’ll examine in the following section. Important Widget Properties The properties you are most likely to use regularly are: layout_height and layout_width Defines how much space this widget is asking from its parent layout to display itself. Although you could enter a value in pixels, inches, or something similar, that is not a good practice. Since your application could run on many different devices with various screen sizes, you want to use relative size for your components, not absolute. So, best practice would be to use either fill_parent or wrap_content for the value. fill_parent means that your widget wants all the available space from its parent. wrap_content means that it requires only as much space as it needs to display its own content. Note that in API Level 8 and higher, fill_parent has been renamed to match_parent. 54 | Chapter 6: Android User Interface layout_weight Layout weight is a number between 0 and 1. It implies the weight of our layout requirements. For example, if our Status EditText had a default layout weight of 0 and required a layout height of fill_parent, then the Update button would be pushed out of the screen because Status and its request for space came before the button. However, when we set the Status widget’s layout weight to 1, we are saying we want all available space height-wise, but are yielding to any other widget that also may need space, such as the Update button. layout_gravity Specifies how this particular widget is positioned within its layout, both horizon- tally and vertically. Values could be top, center, left, and so on. Notice the dif- ference between this property and gravity, explained next. For example, if you have a widget that has its width set to fill_parent, trying to center it wouldn’t do much, because it’s already taking all available space. However, if our Title Text View had its width set to wrap_content, centering it with layout_gravity would generate the desired results. gravity Specifies how the content of this widget is positioned within the widget itself. It is commonly confused with layout_gravity. Which one to use will depend on the size of your widget and the desired look. For example, if our Title TextView had the width fill_parent, then centering it with gravity would work, but centering it with layout_gravity wouldn’t do anything. text Not all widgets have this property, but many do, such as Button, EditText, and TextView. It simply specifies the text for the widget. However, it is not a good practice to just enter the text, because then your layout will work in only one locale/ language. Best practice is to define all text in a strings.xml resource and refer to a particular string using this notation: @string/titleStatusUpdate. id id is simply the unique identifier for this particular widget in a particular layout resource file. Not every widget needs an id, and I recommend removing unneces- sary ids to minimize clutter. But widgets that we’ll need to manipulate later from Java do need ids. id has the format @+id/someName, where someName is whatever you want to call your widget. My naming convention is to use the type followed by the name, for example, @+id/buttonUpdateStatus. Strings Resource Android tries hard to keep data in separate files. So, layouts are defined in their own resources, and all text values (such as button text, title text, etc.) should be defined in their own file called strings.xml. This later allows you to provide multiple versions of strings resources for various languages, such as English, Japanese, or Russian. The StatusActivity Layout | 55 Example 6-2 shows what our strings.xml file looks like at this point. Example 6-2. res/values/strings.xml Yamba 1 Yamba Status Update Please enter your 140-character status Update The file simply contains sets of name/value pairs. I use a certain naming convention for my resource names. Let’s look at titleYamba, for example. First, I prefix the resource with the name of what it is, in this case a title of the activity. Second, I give it a name, Yamba. This naming convention helps keep many different resources sorted in an easy-to-find way. Finally, I use CamelCase for my names, though some may prefer to use underscores to separate words. The StatusActivity Java Class Now that we have our UI designed in XML, we are ready to switch over to Java. Re- member from earlier in this chapter that Android provides two ways for building user interfaces. One is by declaring it in XML, which is what we just did, and we got as far as we could (for now). The other one is to build it programmatically in Java. We also said earlier that the best practice is to get as far as possible in XML and then switch over to Java. Our Java class for this is StatusActivity.java, and the Eclipse New Project dialog has already created the stub for this class. The class is part of the com.marakana.yamba1 Java package, and as such is part of that directory. Creating Your Application-Specific Object and Initialization Code As with all main building blocks in Android, such as activities, services, broadcast receivers, and content providers, you usually start by subclassing a base class provided by the Android framework and overriding certain inherited methods. In this case, we subclass Android’s Activity class and override its onCreate() method. As you recall, activities have a certain life cycle (see “Activity Life Cycle” on page 28), or state machine through which they go. We as developers do not control what state the activity is in, but we do get to say what happens during a transition to a particular state. In this case, the transition we want to override is the onCreate() method that the system’s 56 | Chapter 6: Android User Interface D o wnload from Wow! eBook ActivityManager invokes when the activity is first created (i.e., when it goes from a starting to a running state). This sort of programming, when we subclass a system class and fill in the blanks, is also known as the Template pattern. In addition to doing some standard housekeeping, our onCreate() will carry out two major tasks that the application needs done just once, at the beginning: set up our button so it responds to clicks and connect to the cloud. Notice that onCreate() takes a Bundle as a parameter. This is a small amount of data that can be passed into the activity via the intent that started it. The data provided in a Bundle is typically limited to basic data types; more complex ones need to be specially encoded. For the most part, we’re not going to be using Bundle in our Yamba example, as there’s no real need for it. Keep in mind that whenever you override a method, you first want to make a call to the original method provided by the parent. That’s why we have a super.onCreate() call here. So, once you subclass the framework’s class, override the appropriate method, and call super’s method in it, you are still back where you started: your code does the same thing the original class did. But now we have a placeholder where we can add our own code. The very first thing we typically do in an activity’s onCreate() is to load the UI from the XML file and inflate it into the Java memory space. In other words, we write some Java code that opens up our XML layout file, parses it, and for each element in XML, creates a corresponding Java object in our memory space. For each attribute of a particular XML element, this code will set that attribute on our Java object. This process is called inflating from XML, and the line of code that does all this is setContentView(R.lay out.status);. Remember that the R class is the automatically generated set of pointers that helps connect the world of Java to our world of XML and other resources in the /res folder. Similarly, R.layout.status points to our /res/layout/status.xml file. This setContentView() method does a lot of work, in other words. It reads the XML file, parses it, creates all the appropriate Java objects to correspond to XML elements, sets object properties to correspond to XML attributes, sets up parent/child relation- ships between objects, and overall inflates the entire view. At the end of this one line, our screen is ready for drawing. Your objects are not the only ones that define methods and respond to external stimuli. Android’s user interface objects do that too. Thus, you can tell your Button to execute certain code when its clicked. To do that, you need to define a method named onClick() and put the code there that you want executed. You also have to run the setOnClickListener method on the Button. You pass this as an argument to setOnClick Listener because your object is where you define onClick(). Example 6-3 shows our The StatusActivity Java Class | 57 first version of StatusActivity.java, with some additional explanation following the code. Example 6-3. StatusActivity.java, version 1 package com.marakana.yamba1; import winterwell.jtwitter.Twitter; import android.app.Activity; import android.os.Bundle; import android.util.Log; import android.view.View; import android.view.View.OnClickListener; import android.widget.Button; import android.widget.EditText; public class StatusActivity1 extends Activity implements OnClickListener { // private static final String TAG = "StatusActivity"; EditText editText; Button updateButton; Twitter twitter; /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.status); // Find views editText = (EditText) findViewById(R.id.editText); // updateButton = (Button) findViewById(R.id.buttonUpdate); updateButton.setOnClickListener(this); // twitter = new Twitter("student", "password"); // twitter.setAPIRootUrl("http://yamba.marakana.com/api"); } // Called when button is clicked // public void onClick(View v) { twitter.setStatus(editText.getText().toString()); // Log.d(TAG, "onClicked"); } } To make StatusActivity capable of being a button listener, it needs to implement the OnClickListener interface. Find views inflated from the XML layout and assign them to Java variables. Register the button to notify this (i.e., StatusActivity) when it gets clicked. Connect to the online service that supports the Twitter API. At this point, we hard- code the username and password. 58 | Chapter 6: Android User Interface The method that is called when button is clicked, as part of the OnClickListener interface. Make the web service API call to the cloud to update our status. Compiling Code and Building Your Projects: Saving Files Once you make changes to your Java or XML files, make sure you save them before moving on. Eclipse builds your project automatically every time you choose File→Save or press Ctrl-S. So, it is important to save files and make sure you do not move to another file until the current file is fine. You will know your file is fine when there are no little red x symbols in your code and the project builds successfully. Because Java depends on XML and vice versa, moving to another file while the current one is broken just makes it even more difficult to find errors. Java errors typically are easy to find since the little red x in the code navigates you straight down to the line number where the error occurred (see Figure 6-4). By putting your mouse right on that error, Eclipse will tell you what the error is and will also offer you some possible fixes. This Eclipse feature is very useful and is analogous to the spellchecker in a word processor. Figure 6-4. Tracing Java errors Adding the jtwitter.jar Library We are connecting to the online service that implements the Twitter-compatible API in our application. This connection is done via a series of web service calls. Since An- droid uses standard Java networking capabilities, Android doesn’t offer much more The StatusActivity Java Class | 59 with respect to web services than we already have in Java. So, as such, there’s little value in reinventing the wheel. To make our life with web services and the Twitter API easier, we’re going to use a third-party library, jtwitter.jar, provided by Winterwell Associates. This library con- tains a simple Java class that interacts with the online service and abstracts all the intricacies of making network calls and passing the data back and forth. If no one had been kind enough to provide a high-level library for what we need to do, we could always use standard Java networking libraries to get the job done. It just would have been more work. The jtwitter.jar library provided with this code has been slightly modi- fied from the official Winterwell version to make it work in our Yamba project. Once you download this library, you can put it inside your project in Eclipse. Simply drag the jtwitter.jar file and drop it in the root of your Eclipse project in the Package Manager window. This makes the file part of the project, but our Java code is still unable to locate it. Java searches for all the classes in its classpath. To add jtwitter.jar to the classpath, right-click on your project, select Properties, and you will get a Properties for Yamba dialog window (see Figure 6-5). Select Java Build Path, and choose the Libraries tab. In there, click on Add JARs… and locate your jtwitter.jar file. Figure 6-5. Properties for Yamba dialog window in Eclipse, where we add the jtwitter.jar file 60 | Chapter 6: Android User Interface Updating the Manifest File for Internet Permission Before this application can work, we must ask the user to grant us the right to use the Internet. Android manages security by specifying the permissions needed for certain dangerous operations. The user then must explicitly grant those permissions to each application when he first installs the application. The user must grant all or no per- missions that the application asks for; there’s no middle ground. Also, the user is not prompted about permissions when upgrading an existing app. Because we are running this application in debug mode and installing it via a USB cable, Android doesn’t prompt us for permissions like it would the end user. However, we still must specify that the application requires certain permissions. In this case, we want to ask the user to grant this application the INTERNET permission. We need Internet access to connect to the online service. So, open up the AndroidManifest.xml file by double-clicking on it. Note that Eclipse typically opens this file in a WYSIWYG editor with many tabs on the bottom. As always, you can make most of the changes to this file via this interface, but since Eclipse tools are limited and sometimes buggy, we prefer to go straight into the XML view of this file. So, choose the right-most tab at the bottom that says AnddroidManifest.xml, and add a element within the block (see Example 6-4). Example 6-4. AndroidManifest.xml Defines the element for the INTERNET permission. The StatusActivity Java Class | 61 Logging in Android Android offers a system-wide logging capability. You can log from anywhere in your code by calling Log.d(TAG, message), where TAG and message are some strings. TAG should be a tag that is meaningful to you given your code. Typically, a tag would be the name of your app, your class, or some module. Good practice is to define TAG as a Java constant for your entire class, such as: private static final String TAG = "StatusActivity"; Before your code will compile, you need to import the Log class. Eclipse has a useful feature under Source→Organize Imports, or Ctrl+O for short. Usually, this feature will automatically organize your import statements. However, in the case of Log, often there is a conflict because there are multiple classes named Log. This is where you have to use your common sense and figure it out. In this case, the ambiguity is between the Android Log and Apache Log classes, so choice should be easy. Note that Log takes different severity levels. .d() is for debug level, but you can also specify .e() for error, .w() for warning, or .i() for info. There’s also a .wtf() severity level for errors that should never happen. (It stands for What a Terrible Failure, in case you were wondering.) Eclipse color-codes log messages based on their severity level. Eclipse’s Organize Imports tool can sometimes lead to hard-to-find problems. For example, if your project doesn’t have R.java generated (which might happen because there’s an earlier problem with one of the XML resources), then Organize Imports will import the android.R class. This other R class is part of the Android framework and has the same name as your local R class, making it hard to notice. So, if you have many compilation errors around your references to R resources, check that android.R is not imported. LogCat The Android system log is outputted to LogCat, a standardized system-wide logging mechanism. LogCat is readily available to all Java and C/C++ code. The developer can easily view the logs and filter their output based on severity, such as debug, info, warning, or error, or based on custom-defined tags. As with most things in Android development, there are two ways to view the LogCat: via Eclipse or via the command line. 62 | Chapter 6: Android User Interface LogCat from the Eclipse DDMS perspective To view LogCat in Eclipse, you need to open the LogCat View (see Figure 6-6). You can switch to the DDMS perspective by clicking on the DDMS button in the top-right corner of Eclipse: or by selecting Window→Open Perspective→DDMS in the Eclipse menu. DDMS stands for Dalvik Debug Monitor Server. DDMS is the connection between your application running on the device and your development environment, such as Eclipse. Figure 6-6. LogCat in Eclipse You can define filters for LogCat as well. Click on the little green plus button, and the LogCat Filter dialog will come up (see Figure 6-7). You can define a filter based on a tag, severity level, or process ID. This will create another window within LogCat that shows you only the log entries that match your filter. Logging in Android | 63 Figure 6-7. LogCat Filter DDMS might not show up in the top-right corner if you haven’t used it before. If that’s the case, go to Window→Open Perspective and choose DDMS there. From there on, it should show up in your window tab as well. LogCat from the command line Just like all the tools, anything you can do in Eclipse also can be done from the com- mand line. To view LogCat, open up your terminal window and type: [user:~]> adb logcat This will give you the tail of the current LogCat and will be updated as your device keeps generating log entries. You can also filter log entries on the command line, but the syntax is not the most intuitive. To only see StatusActivity-tagged entries, you specify StatusActivity:*, meaning you want all severity levels for this tag. However, you also have to specify what you don’t want to see. To do that, you add *:S, meaning silence all other tags. The following command line illustrates that: [user:~]> adb logcat StatusActivity:* *:S I find it useful to keep a command-line window open with adb logcat running in it at all times. This makes it easy for me to quickly see what’s going on with my app and is certainly much faster than switching to the DDMS perspective in Eclipse. 64 | Chapter 6: Android User Interface Threading in Android A thread is a sequence of instructions executed in order. Although each CPU can proc- ess only one instruction at a time, most operating systems are capable of handling multiple threads on multiple CPUs, or interleaving them on a single CPU. Different threads need different priorities, so the operating system determines how much time to give each one if they have to share a CPU. The Android operating system is based on Linux and as such is fully capable of running multiple threads at the same time. However, you need to be aware of how applications use threads in order to design your application properly. Single Thread By default, an Android application runs on a single thread. Single-threaded applications run all commands serially, meaning the next command is not completed until the pre- vious one is done. Another way of saying this is that each call is blocking. This single thread is also known as the UI thread because it’s the thread that processes all the user interface commands as well. The UI thread is responsible for drawing all the elements on the screen as well as processing all the user events, such as touches on the screen, clicks of the button, and so on. Figure 6-8 shows the execution of our code on a single UI thread. Figure 6-8. Single-threaded execution The problem with running StatusActivity on the single thread is our network call to update the status. As with all network calls, the time it takes to execute is outside of our control. Our call to twitter.updateStatus() is subject to all the network availability and latency issues. We don’t know whether the user is on a super-fast WiFi connection or is using a much slower protocol to connect to the cloud. In other words, our appli- cation cannot respond until the network call is completed. The Android system will offer to kill any application that is not re- sponding within a certain time period, typically around five seconds for activities. This is known as the Application Not Responding dialog, or ANR for short (see Figure 6-9). Threading in Android | 65 D o wnload from Wow! eBook Figure 6-9. Application Not Responding dialog Multithreaded Execution A much better solution is to have the potentially long operations run on a separate thread. When multiple tasks run on multiple threads at the same time, the operating system slices the available CPU so that no one task dominates the execution. As a result, it appears that multiple tasks are running in parallel at the same time. In our example, we could put the actual network call for updating our status in the cloud in a separate thread. That way our main UI thread will not block while we’re waiting for the network, and the application will appear much more responsive. We tend to talk of the main thread as running in the foreground and the additional threads as running in the background. They’re really all equal in status, alternating their exe- cution on the device’s CPU, but from the point of view of the user, the main thread is in the foreground because it deals with the UI. Figure 6-10 shows the execution of our code’s two threads—the main UI thread, as well as the auxiliary thread we use to perform potentially long-running network calls. Figure 6-10. Multithreaded execution There are multiple ways of accomplishing multithreading. Java has a Thread class that allows for many of these operations. We could certainly use any of the regular Java features to put the network call in the background. However, using the standard Java Thread class is problematic because another thread is not allowed to update the elements in the main UI thread. This makes sense because to update the UI thread, we would need to synchronize with the current state of its objects, and that would be a job on its own. In addition to standard Java threading support, Android provides the utility class AsyncTask specifically designed for this purpose. 66 | Chapter 6: Android User Interface AsyncTask AsyncTask is an Android mechanism created to help handle long operations that need to report to the UI thread. To take advantage of this class, we need to create a new subclass of AsyncTask and implement the doInBackground(), onProgressUpdate(), and onPostExecute() methods. In other words, we are going to fill in the blanks for what to do in the background, what to do when there’s some progress, and what to do when the task completes. We’ll extend our earlier example with an asynchronous posting to the cloud. The first part of Example 6-5 is very similar to the code in Example 6-3, but hands off the posting to the asynchronous thread. A new AsyncTask does the posting in the background. Example 6-5. StatusActivity.java, version 2 package com.marakana.yamba1; import winterwell.jtwitter.Twitter; import winterwell.jtwitter.TwitterException; import android.app.Activity; import android.os.AsyncTask; import android.os.Bundle; import android.util.Log; import android.view.View; import android.view.View.OnClickListener; import android.widget.Button; import android.widget.EditText; import android.widget.Toast; public class StatusActivity2 extends Activity implements OnClickListener { private static final String TAG = "StatusActivity"; EditText editText; Button updateButton; Twitter twitter; /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.status); // Find views editText = (EditText) findViewById(R.id.editText); updateButton = (Button) findViewById(R.id.buttonUpdate); updateButton.setOnClickListener(this); twitter = new Twitter("student", "password"); twitter.setAPIRootUrl("http://yamba.marakana.com/api"); } // Asynchronously posts to twitter class PostToTwitter extends AsyncTask { // // Called to initiate the background activity Threading in Android | 67 @Override protected String doInBackground(String... statuses) { // try { Twitter.Status status = twitter.updateStatus(statuses[0]); return status.text; } catch (TwitterException e) { Log.e(TAG, e.toString()); e.printStackTrace(); return "Failed to post"; } } // Called when there's a status to be updated @Override protected void onProgressUpdate(Integer... values) { // super.onProgressUpdate(values); // Not used in this case } // Called once the background activity has completed @Override protected void onPostExecute(String result) { // Toast.makeText(StatusActivity2.this, result, Toast.LENGTH_LONG).show(); } } // Called when button is clicked public void onClick(View v) { String status = editText.getText().toString(); new PostToTwitter().execute(status); // Log.d(TAG, "onClicked"); } } The PostToTwitter class in this case is an inner class of StatusActivity. It also sub- classes AsyncTask. Notice the use of Java generics to describe the data types that this AsyncTask will use in its methods. I’ll explain these three types next. The first data type is used by doInBackground, the second by onProgressUpdate, and the third by onPostExecute. doInBackground() is the callback that specifies the actual work to be done on the separate thread, as if it’s executing in the background. The argument String... is the first of the three data types that we defined in the list of generics for this inner class. The three dots indicate that this is an array of Strings, and you have to declare it that way, even though you want to pass only a single status. onProgressUpdate() is called whenever there’s progress in the task execution. The progress should be reported from the doInBackground() call. In this case, we do not have any meaningful progress to report. If this example were instead a file download, for instance, this could report the percentage of completion or amount of data 68 | Chapter 6: Android User Interface downloaded thus far. The actual data type—in this case, Integer—refers to the second argument in the generics definition of this class. onPostExecute() is called when our task completes. This is our callback method to update the user interface and tell the user that the task is done. In this particular case, we are using a Toast feature of the Android UI to display a quick message on the screen. Notice that Toast uses the makeText() static method to make the actual message. Also, do not forget to include show(); otherwise, your message will never be displayed, and there won’t be any errors—a hard bug to find. The argument that this method gets is the value that doInBackground() returns, in this case a String. This also corresponds to the third generics datatype in the class definition. Once we have our AsyncTask set up, we can use it. To use it, we simply instantiate it and call execute() on it. The argument that we pass in is what goes into the doInBackground() call. Note that in this case we are passing a single string that is being converted into a string array in the actual method later on, which is an example of Java’s variable number of arguments feature. At this point, when the user clicks on the Update Status button, our activity will create a separate thread using AsyncTask and place the actual network operation on that thread. When done, the AsyncTask will update the main UI thread by popping up a Toast message to tell the user that the operation either succeeded or failed. This ap- proach makes our application much more responsive, and users should never get the “Application Not Responding: Force Close or Wait” message shown in Figure 6-9. At this point, our application looks like Figure 6-11 when running. Figure 6-11. StatusActivity, part 1 Threading in Android | 69 Other UI Events So far, you have seen how to handle the click events by implementing OnClick Listener and providing the onClick() method, which is invoked when the button is clicked. Imagine that we want to provide a little counter telling the user how many characters of input are still available out of the maximum of 140. To do that, we need another type of listener. Android provides many different listeners for various events, such as touch, click, and so on. In this case, we’re going to use TextWatcher to watch for text changes in the edit text field. Steps for this listener are similar to the steps for OnClickListener and many other listeners. From the user’s standpoint, we’ll add another TextView to our layout to indicate how many characters are still available. This text will change color, from green to yellow to red, as the user approaches the 140-character limit. In Java, we’ll implement TextWatcher and attach it to the field where the user is typing the actual text. The TextWatcher methods will be invoked as the user changes the text, and based on the amount of text entered, we’ll update the counter. See Example 6-6. Example 6-6. res/layout/status2.xml 70 | Chapter 6: Android User Interface New TextView that represents how many characters are still available for the user to type. We start at 140 and then go down as the user enters text. The version of StatusActivity shown in Example 6-7 implements the TextWatcher in- terface, and the new methods in this example appear at the end of the class. Initially the text of the counter is in green to indicate we can keep on typing. As we approach the maximum, the text turns yellow and eventually changes to red to indicate we are beyond the maximum message size. Example 6-7. StatusActivity.java, final version package com.marakana.yamba1; import winterwell.jtwitter.Twitter; import winterwell.jtwitter.TwitterException; import android.app.Activity; import android.graphics.Color; import android.os.AsyncTask; import android.os.Bundle; import android.text.Editable; import android.text.TextWatcher; import android.util.Log; import android.view.View; import android.view.View.OnClickListener; import android.widget.Button; import android.widget.EditText; import android.widget.TextView; import android.widget.Toast; public class StatusActivity extends Activity implements OnClickListener, TextWatcher { // private static final String TAG = "StatusActivity"; EditText editText; Button updateButton; Twitter twitter; TextView textCount; // /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.status); // Find views editText = (EditText) findViewById(R.id.editText); updateButton = (Button) findViewById(R.id.buttonUpdate); updateButton.setOnClickListener(this); textCount = (TextView) findViewById(R.id.textCount); // textCount.setText(Integer.toString(140)); // textCount.setTextColor(Color.GREEN); // Other UI Events | 71 editText.addTextChangedListener(this); // twitter = new Twitter("student", "password"); twitter.setAPIRootUrl("http://yamba.marakana.com/api"); } // Called when button is clicked public void onClick(View v) { String status = editText.getText().toString(); new PostToTwitter().execute(status); Log.d(TAG, "onClicked"); } // Asynchronously posts to twitter class PostToTwitter extends AsyncTask { // Called to initiate the background activity @Override protected String doInBackground(String... statuses) { try { Twitter.Status status = twitter.updateStatus(statuses[0]); return status.text; } catch (TwitterException e) { Log.e(TAG, e.toString()); e.printStackTrace(); return "Failed to post"; } } // Called when there's a status to be updated @Override protected void onProgressUpdate(Integer... values) { super.onProgressUpdate(values); // Not used in this case } // Called once the background activity has completed @Override protected void onPostExecute(String result) { Toast.makeText(StatusActivity.this, result, Toast.LENGTH_LONG).show(); } } // TextWatcher methods public void afterTextChanged(Editable statusText) { // int count = 140 - statusText.length(); // textCount.setText(Integer.toString(count)); textCount.setTextColor(Color.GREEN); // if (count < 10) textCount.setTextColor(Color.YELLOW); if (count < 0) textCount.setTextColor(Color.RED); } public void beforeTextChanged(CharSequence s, int start, int count, int after) { // } 72 | Chapter 6: Android User Interface public void onTextChanged(CharSequence s, int start, int before, int count) { // } } We declare that StatusActivity now implements TextWatcher. This means we need to actually provide the implementation for this interface, which we do later on in this class. textCount is our text view, defined in Example 6-6. First, we need to find the textCount in the inflated layout. We set the initial text to 140 because that’s the maximum length of a status message in our app. Note that TextView takes text as value, so we convert a number to text here. The textCount field will change color dynamically based on the number of remaining characters. In this case, we start with green. Notice that the Color class is part of the Android framework and not Java. In other words, we’re using android.graph ics.Color and not java.awt.Color. Color.GREEN is one of the few colors defined as a constant in this class (more on colors in the next section). Here we attach TextWatcher to our editText field. In other words, editText will call the TextWatcher instance, in this case this, which refers to this object itself. afterTextChanged() is one of the methods provided by the TextWatcher interface. This method is called whenever the text changes in the view that this TextWatcher is watching. In our case, whenever the user changes the underlying text in editText, this method is invoked with the current text. Here we do some math to figure out how many characters are left, given the 140- character limit. Next, based on the availability of the text, we update the color of the counter. So, if more than 10 characters are available, we are still in the green. Fewer than 10 means we are approaching the limit, thus the counter turns yellow. If we are past the limit of 140 characters, the counter turns red. This method is called just before the actual text replacement is completed. In this case, we don’t need this method, but as part of implementing the TextWatcher in- terface, we must provide its implementation, event though it’s empty. Similarly, we are not using onTextChanged() in this case, but must provide its blank implementation.Figure 6-12 shows what the TextWatcher looks like in our appli- cation when running. Other UI Events | 73 Figure 6-12. StatusActivity, part 1 Adding Color and Graphics Our application works well, but it’s a bit dull looking. A little bit of color and some graphics could go a long way. Android offers a lot of support to make your application snazzy. We’re going to see some basics here. Adding Images For starters, we want to add a background to our screen. This background is going to be some kind of graphics file. In Android, most images go to a resource folder called drawable. You may notice that you already have three folders with this name: • /res/drawable-hdpi for devices with high-density screens • /res/drawable-mdpi for devices with medium-density screens • /res/drawable-ldpi for devices with low-density screens We are going to create another drawable folder called simply /res/drawable. To do that, right-click on the res folder and choose New→Folder. For the name, enter drawable. You can now put your graphics that are independent of screen density in this folder. We’re going to assume you found some cool background graphics and that you saved the file in this new folder under the name background.png. Although Android supports many different file formats, PNG is preferred to the GIF standard because PNG is loss- less and doesn’t require any patent licenses. 74 | Chapter 6: Android User Interface D o wnload from Wow! eBook Although PNG officially stands for Portable Network Graphics, it is also commonly known as PNG’s Not Gif, to reflect its departure from the controversial GIF standard. Remember that all resources are being “watched” by Eclipse, and the moment we put something in there, Eclipse will use its Android SDK tools to update the R class auto- matically. So at this point, we’ll have a reference to R.drawable.background and could use this resource from Java. But we won’t. We are going to update the status activity layout file res/layout/status.xml next. Our goal is to make this background file the background graphic for the entire screen. To do that, we’ll update the top layout in our file and set its background to point to this new background PNG file, which means we have to open the status.xml layout. Now we have two ways of adding the background to the top layout. Using the WYSIWYG editor in Eclipse One way is to use Eclipse’s WYSIWYG tool, as shown in Figure 6-13. In this tool, we need to first select the main layout, which might be difficult since many other compo- nents are in front of it. The red border indicates which view or layout is selected. Another way of making your selection is to open up your Outline view in Eclipse and select the top element there. This view might not be currently visible in your Eclipse, depending on how you arranged the many available windows. One sure way to get the Outline view is to go to Window→Show View→Outline and open it up that way. Once you open this view, you can select the top layout, in this case our LinearLayout. You will know it’s selected if a red border is around your entire activity. Next, you want to open up the Properties view in Eclipse. Again, this view might already be opened, but if it’s not visible as a window in Eclipse, go to Window→Show View→Other, and under the General section, pick Properties. This will open up a view in which you can change various properties for this particular view. The property we want to modify is background. You can now click on the little … button, which will bring up the Reference Chooser dialog (see Figure 6-14). In this dialog, choose Drawable→Background. This will set the background of your top layout to @drawable/background. As you recall, this is the way that one XML resource refers to another resource. In this case, our status.xml layout is referring to the background.png drawable. Notice that we do not use extensions when referring to other file resources. Android figures out the best file format automatically, in case there are files with the same name but different extensions. Adding Color and Graphics | 75 Updating directly in XML code Another approach is to go straight into the XML code and make changes there. Re- member that everything you can do with Eclipse tools, you can also do in a plain-text editor. To switch to the XML code view, select the status.xml tab at the bottom of the window, next to the Layout tab. This will open up the file with your standard XML editor. In this case, to add the background resource to our entire activity, we simply add android:background="@drawable/background" to our element. From now on, we’re going to be making changes directly in the XML code because it’s much simpler to explain. Also, the WYSIWYG editor can do only so much, and often you run into its limitations. Adding Color We now have the background for the entire screen, but what about the actual text box that users type the text into? The current design is stock. We could improve on it by adding some color and transparency. Figure 6-13. Eclipse Graphical Layout Editor 76 | Chapter 6: Android User Interface Android uses the standard RGB color set, but it also optionally expands it with an Alpha channel. So, you can express color as RGB or ARGB, where A is the amount of transparency, R is the amount of red, G is for green, and B stands for blue. The com- bination of these three colors and optional transparency gives you every conceivable color from white to black, and from opaque to fully transparent! That’s the whole point of ARGB. Of course, the granularity isn’t exactly what Monet would be happy with; each value has only 256 possibilities. Amounts of each channel can be represented either as values between 0 and 255 or by using the hexadecimal system values between 0 and FF. So, the actual values could be AARRGGBB, where each letter can be replaced with a value between 0 and F. There’s also a shorter version of ARGB, where each value is repeated. For example, #3A9F is the same as #33AA99FF and corresponds to #33 for alpha, #AA for red, #99 for green, and #FF for blue. Notice that we use the # symbol in front of hexadecimal values to distinguish them from decimal values. So, we could update the background of our EditText element to be #cfff, which is a somewhat transparent white color. Next, we can update the color of the title text by changing the textColor property for that TextView. A good color would be white, for example. One way to specify white is #fff, but alternatively we could enter @android:color/white. The android: part of that Figure 6-14. Reference Chooser Adding Color and Graphics | 77 statement refers to the Android operating system’s set of resources, in this case a pre- defined color white. Example 6-8 shows these new additions to our status.xml code. Example 6-8. res/layout/status.xml