精通Android：开发者指南

需积分: 9 57 浏览量更新于2024-08-01 收藏 5.29MB PDF 举报

"Manning出版的《Unlocking Android: A Developer's Guide》是2009年5月的一本关于Android开发的专业指南。本书旨在帮助开发者全面了解Android平台，掌握其关键技术和实操应用。全书分为三个部分，涵盖了从环境搭建到实际设备应用的全过程。" **Part I: What is Android—The Big Picture** 这部分主要介绍了Android的基本概念和整体架构，包括Android的目标市场和适用范围。在第1章"Targeting Android"中，作者会讲解Android系统的设计理念，以及为什么选择Android作为开发平台。第2章"Development environment"则详细阐述了如何设置和配置Android的开发环境，包括安装SDK、集成开发环境（IDE）的使用等。 **Part II: Learning Android’s Key Technologies** 这部分深入讲解了Android开发中的核心技术和组件。第3章"User Interfaces"讨论了Android的用户界面设计，包括布局管理器、控件使用和自定义视图。第4章"Intents and Services"介绍了Android中的意图（Intent）和后台服务，这是实现应用程序组件间通信的关键。第5章"Storing and Retrieving Data"涵盖了数据存储方式，如SQLite数据库、Shared Preferences和文件系统。第6章"Networking"讲述了网络编程，包括HTTP请求、套接字通信等。第7章"Telephony"涉及电话功能的集成，如拨打电话、接收短信等。第8章"Notification and Alarms"介绍了通知和定时任务的处理。第9章"Graphics and Animation"讲解了图形绘制和动画效果的创建。第10章"Multimedia"涵盖了多媒体文件的处理，如音频、视频和图像。第11章"Location Based Services"介绍了基于位置的服务，包括GPS和网络定位的使用。 **Part III: Android applications for the Real Device** 这一部分将理论知识与实践结合，第12章"Putting it all together: A Field Service Application"通过一个现场服务应用的实例，展示了如何整合前面所学的技术，构建一个完整的Android应用。第13章"Hacking Android"则探讨了更高级的主题，如系统级别的修改和调试技巧，为有经验的开发者提供了更深入的探索空间。 **Appendix: Installing the Android SDK** 附录提供了Android SDK的安装指南，帮助读者顺利开始Android开发之旅。这本书适合初学者和有一定经验的开发者，它既讲解了基础知识，也涵盖了高级主题，为开发者提供了全面理解并成功开发Android应用的路径。书中提供的示例代码和实践经验将有助于读者快速上手，并能应对各种复杂的Android开发挑战。

IntentFilters are often defined in an application’s AndroidManifest.xml with the <intent-filter> tag. The

AndroidManfest.xml file is essentially an application descriptor file, which is discussed later in this chapter.

A common task on a mobile device is the lookup of a specific contact record for the purpose of initiating a call,

sending an SMS, or perhaps looking up a snail-mail address when you are standing in line at the neighborhood

Pack-and-Ship store. A user may desire to view a specific piece of information, say a Contact Record for user 1234.

In this case, the action is ACTION_VIEW and the data is a specific Contact Record identifier. This is accomplished

by creating an Intent with a the action set to ACTION_VIEW and a URI which represents the specific person of

interest.

Here is an example of the URI for use with the android.content.Intent.ACTION_VIEW action:

content://contacts/people/1234

Here is an example of the URI for obtaining a list of all contacts, the more generalized URI of

content://contacts/people

Here is a snippet of code demonstrating the PICKing of a contact record:

Intent myintent = new

Intent(Intent.ACTION_PICK,Uri.parse(“content://contacts/people”));

startActivity(myintent);

This Intent is evaluated and passed to the most appropriate handler. In this case, the recipient would likely be

a built-in Activity named com.google.android.phone.Dialer. However, the best recipient of this Intent may be an

Activity contained in the same custom Android Application (ie, the one you build!), a built-in application as in this

case, or it may be a 3

party application on the device. Applications can leverage existing functionality in other

applications by creating and dispatching an Intent requesting existing code to handle the Intent rather than writing

code from scratch. One of the great benefits of employing Intents in this manner is that it leads to the same user

interfaces being used frequently, creating familiarity for the user. This is particularly important for mobile

platforms where the user is often non tech-savvy, nor interested in learning multiple ways to accomplish the same

task such as looking up a contact on their phone.

The Intents we have discussed thus far are known as “implicit” Intents, which rely on the IntentFilter and the

Android environment to dispatch the Intent to the appropriate recipient. There are also “explicit” Intents where we

can specify the exact class we desire to handle the Intent. This is helpful when we know exactly which Activity we

want to handle the Intent and do not want to leave anything up to “chance” in terms of what code is executed. To

create an explicit Intent, use the overloaded Intent constructor which takes a class as an argument as shown

here:

public void onClick(View v)

{

try

{

startActivityForResult(new Intent(v.getContext(),RefreshJobs.class),0);

}

catch (Exception e)

{

…

}

These examples show how an Android application creates an Intent and asks for it to be handled. Similarly, an

Android application can be deployed with an IntentFilter indicating that it responds to Intents already created on

the system, thereby publishing new functionality for the platform. This facet alone should bring joy to Independent

Software Vendors (ISVs) who have made a living by offering better Contact Manager and To-Do List Management

software titles for other mobile platforms.

Please post comments or corrections to the Author Online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=411

Licensed to Thow Way Chiam <ken.ctw@gmail.com>

Intent resolution, or dispatching, takes place at Runtime, as opposed to when the application is compiled, so

specific Intent handling features can be added to a device which may provide an upgraded or more desirable set of

functionality than the original shipping software. This Runtime dispatching is also referred to as “late binding”.

The Power and the Complexity of Intents

It is not hard to imagine that an absolutely unique user experience is possible with Android because of the variety

of Activities with specific IntentFilters installed on any given device. It is architecturally feasible to upgrade

various aspects of an Android installation to provide sophisticated functionality and customization. While this

may be a desirable characteristic for the user, it can be a bit troublesome for someone providing tech support

and having to navigate through a number of components and applications to troubleshoot a problem.

This discussion of Intents has focused on Intents which cause User Interface elements to be displayed for the

user. There are also Intents which are more “event-driven’ rather than “task-oriented” as the earlier Contact

Record example described. For example, the Intent class is also used to notify applications that a text message

has arrived. Intents are a very central element to Android and will be revisited on more than one occasion in this

book.

Now that Intents have been briefly introduced as the catalyst for navigation and event flow on Android, let’s

jump back out to a broader view and discuss Android Application life cycle and the key components that make

Android tick. The Intent will come into better focus as Android is further explored throughout this book.

1.3.2 Activating Android

This section builds on the knowledge of the Intent and IntentFilter classes introduced in the previous section and

explores the four primary components of Android applications as well as their relation to the Android process

model. Code snippets are included to provide a taste of Android application development. More in-depth

examples and discussion are left for later Chapters.

NOTE

A particular Android application may not contain all of these elements, but it will have at least one of these

elements, and could in fact have all of them.

ACTIVITY

An application may or may not have a User Interface. If it has a user interface, it will have one or more Activity.

The easiest way to think of an Android Activity is to relate a visible screen to an Activity, as more often than

not, there is a one-to-one relationship between an Activity and a user interface screen. An Android application will

often contain more than one Activity. Each Activity displays a user interface and responds to system and user

initiated events. The Activity employs one or more Views to present the actual User Interface elements to the

user. The Activity class is extended by user classes, as seen in the code listing 1.1.

Listing 1.1: A very basic Activity in an Android application.

package com.msi.manning.chapter1;

import android.app.Activity;

import android.os.Bundle;

public class activity1 extends Activity

{

@Override

public void onCreate(Bundle icicle)

{

super.onCreate(icicle);

setContentView(R.layout.main);

}

Please post comments or corrections to the Author Online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=411

Licensed to Thow Way Chiam <ken.ctw@gmail.com>

1. The Activity class is part of the android.app java package, found in the Android runtime. The Android

runtime is deployed in the android.jar file.

2. The class activity1 extends the class Activity. For more examples of using an Activity, please see Chapter 3.

3. One of the primary tasks an Activity performs is the display of User Interface elements which are implemented

as Views and described in XML layout files. Chapter 3 goes into more detail on Views and Resources.

Moving from one Activity to another is accomplished with the

startActivity() method or the

startActivityForResult() method when a “synchronous” call/result paradigm is desired. The argument to

these methods is the Intent.

You say Intent, I say Intent.

The Intent class is used in similar sounding, but very different scenarios.

There are Intents used to assist in navigation from one activity to the next such as the example given earlier of

VIEWing a Contact Record. Activities are the targets of these kinds of Intents used with the startActivity or

startActivityForResult methods.

Services can be started by passing an Intent to the startService method.

BroadcastReceivers receive Intents when responding to system-wide events such as the phone ringing or an

incoming text message.

The Activity represents a very visible application component within Android. With assistance from the View

class introduced later in this book, the Activity is the most common type of Android application. The next topic of

interest is the Service, which runs in the background and does not generally present a direct User Interface.

ERVICE

If an application is to have a long life cycle it should be put into a Service. For example a background data

synchronization utility running continuously should be implemented as a Service.

Like the Activity, a Service is a class provided in the Android runtime which should be extended, as seen in

Listing 1.2, which sends a message to the Android log periodically:

Listing 1.2: A simple example of an Android Service.

package com.msi.manning.chapter1;

import android.app.Service;

import android.os.IBinder;

import android.util.Log;

public class service1 extends Service implements Runnable

{

public static final String tag = "service1";

private int myiteration = 0;

@Override

protected void onCreate()

{

super.onCreate();

Thread mythread = new Thread (this);

mythread.start();

}

public void run()

{

while (true)

{

try

{

Log.i(tag,"service1 firing : # " + myiteration++);

Please post comments or corrections to the Author Online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=411

Licensed to Thow Way Chiam <ken.ctw@gmail.com>

Thread.sleep(10000);

}

catch(Exception ee)

{

Log.e(tag,ee.getMessage());

}

ide @Overr

public IBinder onBind(Intent intent)

{

// TODO Auto-generated method stub

return null;

}

1. This example requires that the package android.app.Service be imported. This package contains the Service

class.

2. This example also demonstrates Android’s Logging mechanism, which is useful for debugging purposes. This is

discussed in further detail later in this book.

3. The service1 class extends Service. It also implements Runnable to perform its main task on a separate

Thread. This is a common paradigm, but it is not required to implement Runnable.

4. The onCreate method of the Service class permits the application to perform initialization type tasks.

5. The onBind() method is discussed in further detail in Chapter 4 when the topic of Binder and Interprocess

Communication in general is explored.

Services are started with the startService(Intent) method of the abstract Context class. Note that again, the

Intent is used to initiate a desired result on the platform.

Now that the application has a user interface in an Activity and a means to have a long-running task in a

Service, it is time to explore the BroadcastReceiver, another form of Android application which is dedicated to

processing Intents.

ROADCASTRECEIVER

If an application desires to receive and respond to a global event, such as the phone ringing or an incoming text

message, it must register itself as an BroadcastReceiver. An application registers to receive Intents in a couple of

different manners:

• The application implements a <receiver> element in the AndroidManfest.xml file which describes the

BroadcastReceiver’s class name and enumerates its IntentFilters. Remember, the IntentFilter is a

descriptor of the Intent an application desires to process. If the receiver is registered in the

AndroidManifest.xml file, it does not have to be running in order to be triggered when the event occurs as

the application is started automatically upon the triggering event. All of this house-keeping is managed by

Android.

• An application registers itself at runtime via the Context class’s registerReceiver method.

Like Services, BroadcastReceivers do not have a User Interface. Of even more importance, the code running in

the onReceive method of a BroadcastReceiver should make no assumptions about persistence or long-running

operations. If the BroadcastReceiver requires more than a trivial amount of code execution, it is recommended

that the code initiate a request to a Service to complete the requested functionality.

NOTE

The familiar Intent class is used in the triggering of BroadcastReceivers, however the use of these Intents are

mutually exclusive from the Intents used to start an Activity or a Service as previously discussed.

An BroadcastReceiver implements the abstract method onReceive to process incoming Intents. The arguments

to the method are a Context and an Intent. The method returns void, but there are a handful of methods useful

Please post comments or corrections to the Author Online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=411

Licensed to Thow Way Chiam <ken.ctw@gmail.com>

for passing back “results”, including setResult which passes back to the invoker an integer return code, a String

return value, and a Bundle value, which can contain any number of objects.

Listing 1.3 is an example of an BroadcastReceiver triggering upon an incoming Text Message.

Listing 1.3: A sample IntentReceiver.

package com.msi.manning.unlockingandroid;

import android.content.Context;

import android.content.Intent;

import android.content.IntentReceiver;

import android.util.Log;

public class MySMSMailBox extends BroadcastReceiver

{

public static final String tag = "MySMSMailBox";

@Override

public void onReceive(Context context, Intent intent)

{

Log.i(tag,"onReceive");

if (intent.getAction().equals("android.provider.Telephony.SMS_RECEIVED"))

{

Log.i(tag,"Found our Event!");

}

1. The class MySMSMailBox extends the BroadcastReceiver class. This is the most straight-forward way to

employ an BroadcastReceiver. Note the class name of “MySMSMailBox”, as it will be used in the

AndroidManifest.xml file, shown in code listing 1.4.

2. The tag variable is used in conjunction with the logging mechanism to assist in labeling messages sent to

the console log on the emulator. Chapter 2 discusses the log mechanism.

3. The onReceive method is where all of the work takes place in an BroadcastReceiver. The

BroadcastReceiver is required to implement this method. Note that a given BroadcastReceiver can

4. It is important to make sure to handle the appropriate Intent by checking the action of the incoming

Intent as shown.

5. Once the desired Intent is received, carry out the specific functionality required. A common task in an

SMS receiving application would be to parse the message and display it to the user via a Notification

Manager display.

In order for this BroadcastReceiver to “fire” and receive this Intent, it must be listed in the AndroidManifest.xml file

as seen in listing 1.4. This listing contains the elements required to respond to an incoming text message.

Listing 1.4: AndroidManifest.xml

<?xml version="1.0" encoding="utf-8"?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="com.msi.manning.unlockingandroid">

<uses-permission android:name="android.permission.RECEIVE_SMS" />

<intent-filter>

</intent-filter>

</activity>

Please post comments or corrections to the Author Online forum at

http://www.manning-sandbox.com/forum.jspa?forumID=411

Licensed to Thow Way Chiam <ken.ctw@gmail.com>

剩余371页未读，继续阅读

leon456

粉丝: 1
资源: 90

精通Android：开发者指南

Manning.Unlocking.Android.MEAP.Edition.2008.pdf

Manning.Python与Tkinter编程.pdf

Manning.The.Art.of.Unit.Testing.May.2009.rar

Manning.The.Art.of.Unit.Testing.May.2009

manning.ruby.in.practice.mar.2009.pdf

Manning.RxJava for Android Developers.2019.pdf

Manning.Spring.in.Practice.May.2013

Manning.Struts.2.in.Action.May.2008

Manning.Flex.Mobile.in.Action.May.2012

Manning.Erlang.and.OTP.in.Action.May.2010.MEAP

最新资源