Ask a question


Android supports a number of other resources in addition to string resources and layout resources. The general process of creating and using these various resources is similar. However, it is worthwhile to consider some differences. Android supports all these resources through XML files, bitmap files for images, and raw files (examples of which could include audio and video). Within the set of XML files, you’ll find two types: one gets compiled into binary format, and the other gets copied as is. The examples you have seen so far—the string-resource XML files and the layout-resource XML files—get compiled into binary format before becoming part of the installable package. You can also place raw XML files in the /res/ xml/ subdirectory to have them compiled into binary format. But if you place files, including XML files, in the /res/raw/ directory instead, they don’t get compiled into binary format. You must use explicit stream-based APIs to read these files. As we mentioned in Table 2-1 in the previous chapter, resource files are housed in various subdirectories based on their type. Here are some important subdirectories in the /res folder and the types of resources they host: • anim: Compiled animation files • drawable:…
In Chapter 2, you got an overview of an Android application and a quick look at some of its underlying concepts. Among these, resources, content providers, and intents form the three primary pillars of Android UI programming. Android depends on resources for look-and-feel flexibility, content providers for abstracting data into services, and intents for interoperability and UI reuse. You must fully understand these three concepts in order to build successful Android applications, so we’ll discuss them in depth here. Understanding Resources Resources are critical to the Android architecture. In this section, you’ll learn what resources are and how to create them using resource files. You’ll find out that resources are declarative, and that Android creates resource IDs for convenient use in your Java programs. You’ll also see how the R.java source file mediates the generation and usage of these resource IDs. Then you’ll learn how to define resources in XML files, reuse resources in other resource XML definitions, and reuse resources in Java programs. In addition to these XML-based resources, this chapter also covers two other types of resources: raw resources and assets. String Resources A resource in Android is a file (like a music file) or a value (like…
Wednesday, 28 July 2010 23:32

Examining the Application Lifecycle

The lifecycle of Android applications differs greatly from the lifecycle of web-based J2EE applications. J2EE apps are loosely managed by the container they run in. For example, a J2EE container can remove an application from memory if it sits idle for a predetermined time period. But the container generally won’t move applications in and out of memory based on load and/or available resources. In other words, it’s up to the application owners to ensure that resources are available. The lifecycle of an Android application, on the other hand, is strictly managed by the system, based on the user’s needs, available resources, and so on. A user might want to launch a web browser, for example, but the system ultimately decides whether to start the application.Although the system is the ultimate manager, it adheres to some defined and logical guidelines to determine whether an application can be loaded, paused, or stopped. If the user is currently working with an activity, the system will give high priority to that application. Conversely, if an activity is not visible and the system determines that an application must be shut down to free up resources, it will shut down the lower-priority application. The concept of…
Although the size and complexity of Android applications can vary greatly, their structures will be similar. Figure 2-7 shows the structure of the “Hello World!” app you just built. As you can see from Table 2-1, an Android application is primarily made up of three pieces: the application descriptor, a collection of various resources, and the application’s source code. If you put aside the AndroidManifest.xml file for a moment, you can view an Android app in this simple way: you have some business logic implemented in code, and everything else is a resource. This basic structure resembles the basic structure of a J2EE app, where the resources correlate to JSPs, the business logic correlates to servlets, and the AndroidManifest.xml file correlates to the web.xml file. You can also compare J2EE’s development model to Android’s development model. In J2EE, the philosophy of building views is to build them using markup language. Android has also adopted this approach, although the markup in Android is XML. You benefit from this approach because you don’t have to hard-code your application’s views; you can modify the look and feel of the application by editing the markup. It is also worth noting a few constraints regarding…
Friday, 16 July 2010 16:50

Learning the Fundamental Components

Every application framework has some key components that developers need to understand before they can begin to write applications based on the framework. For example, you would need to understand JavaServer Pages (JSP) and servlets in order to write Java 2 Platform, Enterprise Edition (J2EE) applications. Similarly, you need to understand activities, views, intents, content providers, services, and the AndroidManifest.xml file when you build applications for Android. We will briefly discuss these fundamental concepts here so that you can follow the rest of this chapter, and we’ll discuss them in more detail throughout the book. View The concept of a view in J2EE and Swing carries over to Android. Views are UI elements that form the basic building blocks of a user interface. Views are hierarchical and they know how to draw themselves. Activity An activity is a user interface concept. An activity usually represents a single screen in your application. It generally contains one or more views, but it doesn’t have to. Moreover, other concepts in Android could better represent a viewless activity (as you’ll see in the “Service” section shortly). Intent An intent generically defines an “intention” to do some work. Intents encapsulate several concepts, so the best…
Friday, 16 July 2010 16:46

Getting Your Feet Wet

In the last chapter, we provided an overview of Android’s history and we hinted at concepts we’ll cover in the rest of the book. So by this point, you’re probably eager to get your hands on some code. We’ll start by showing you what you need to start building applications with the Android Software Development Kit (SDK) and help you set up your development environment. Next, we’ll baby-step you through a “Hello World!” application and dissect a slightly larger application after that. Then we’ll explain the Android application lifecycle and end with a brief discussion about debugging your applications. To build applications for Android, you’ll need the Java SE Development Kit (JDK), the Android SDK, and a  evelopment environment. Strictly speaking, you can develop your applications using a primitive text editor, but for the purposes of this book, we’ll use the commonly available Eclipse IDE. The examples in this book target Android SDKs 1.1 and 1.5. (Chapters 12 and 13 focus on material specific to Android 1.5.) The Android SDK requires JDK 5 or higher,and we use JDK 6 with the examples. Moreover, the Android SDK requires Eclipse 3.3 or higher; we use Eclipse 3.4 (Ganymede). Finally, to make your…
Friday, 16 July 2010 16:42

Android Service Components

Security is a fundamental part of the Android Platform. In Android, security spans all  phases of the application lifecycle—from design-time policy considerations to runtime boundary checks. Location-based service is another one of the more exciting pieces of the Android  SDK.This portion of the SDK provides application developers APIs to display and manipulate maps,as well as obtain real-time device-location information. We’ll cover these ideas in  detail in Chapter 7. In Chapter 8, we’ll show you how to build and consume services in Android, specifically HTTP services. The chapter will also cover interprocess communication (communication between applications on the same device). Here is an example of doing an HttpPost in  Android: InputStream is = this.getAssets().open("data.xml"); HttpClient httpClient = new DefaultHttpClient(); HttpPost postRequest = new HttpPost("http://192.178.10.131/WS2/Upload.aspx"); byte[] data = IOUtils.toByteArray(is); InputStreamBody isb = new InputStreamBody( new ByteArrayInputStream(data),"uploadedFile"); StringBody sb1 = new StringBody("someTextGoesHere"); StringBody sb2 = new StringBody("someTextGoesHere too"); MultipartEntity multipartContent = new MultipartEntity(); multipartContent.addPart("uploadedFile", isb); multipartContent.addPart("one", sb1); multipartContent.addPart("two", sb2); postRequest.setEntity(multipartContent); HttpResponse res =httpClient.execute(postRequest); res.getEntity().getContent().close(); Android Media and Telephony Components Android has APIs that cover audio, video, and telephony components. Here is a quick example of how to play an audio file from an Internet URL: private void playAudio(String url)throws Exception { mediaPlayer =…
In this section, we’ll introduce you to the high-level Android Java APIs that you’ll use todevelop end-user applications for an Android handheld. We will briefly talk about the Android phone emulator and foundational components, UI programming, services, media,telephony,animation, and OpenGL. We will also show you some code snippets when they are helpful. The Android Emulator The Android SDK ships with an Eclipse plug-in called Android Development Tools (ADT). You will use this Integrated Development Environment (IDE) tool for developing, debugging, and testing your Java applications. (We’ll cover ADT in depth in Chapter 2.) You can also use the Android SDK without using ADT; you’d use command-line tools instead. Both approaches support an emulator that you can use to run, debug, and test your applications. You will not even need the real device for 90 percent of your application development. The full-featured Android emulator mimics most of the device features, but you’ll encounter some limitations regarding USB connections, camera and video capture, head- phones, battery simulation, and Bluetooth. The Android emulator accomplishes its work through an open source “processor emula-tor” technology called QEMU (http://bellard.org/qemu/) developed by Fabrice Bellard. This is the same technology that allows emulation of one operating system on…
Page 1 of 13

« November 2017 »
Mon Tue Wed Thu Fri Sat Sun
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30