深入探索Android：从基础到实战

需积分: 9 115 浏览量更新于2024-08-02 1 收藏 5.04MB PDF 举报

"Unlocking Android" 是一本由 Frank Ableson, Charlie Collins 和 Robi Sen 合著的关于Android开发的书籍，通过Manning Early Access Program（MEAP）出版。本书旨在帮助读者理解Android系统，掌握关键技术和实际设备上的应用开发。在 "Unlocking Android" 中，作者将内容分为三个主要部分：第一部分：什么是Android——整体概述这部分介绍了Android操作系统的基本概念，以及为何选择针对Android平台进行开发。章节1 "Targeting Android" 深入探讨了Android市场和目标用户群体，同时可能涉及Android系统的版本历史和设备多样性。章节2 "Development environment" 则涵盖了Android开发环境的设置，包括Android SDK、集成开发环境(IDE)如Android Studio的安装和配置，以及如何建立第一个Android项目。第二部分：学习Android的关键技术这部分是书籍的核心，详细讲解了Android开发中的关键技术。章节3 "User Interfaces" 讲解如何创建用户友好的界面，包括布局管理器、控件和触摸事件处理。章节4 "Intents and Services" 解释了Intent用于组件间的通信，以及后台服务的实现。章节5 "Storing and Retrieving Data" 讨论了数据存储的方式，如SQLite数据库、SharedPreferences和文件系统。章节6 "Networking" 介绍网络通信，包括HTTP请求、套接字编程和数据解析。章节7 "Telephony" 关注电话功能，如拨打电话、接收来电和短信处理。章节8 "Notification and Alarms" 讲解了如何使用通知提醒用户，并设置定时任务。章节9 "Graphics and Animation" 介绍了Android图形绘制和动画效果的实现。章节10 "Multimedia" 包括多媒体文件的播放、录制和处理。章节11 "Location-Based Services" 讲述如何利用GPS和其他定位技术来提供基于位置的应用功能。第三部分：Android应用程序在真实设备上的实践这部分结合实际案例，展示了如何将所学知识应用于实际应用开发。章节12 "Putting it all together: A Field Service Application" 提供了一个完整的应用开发实例，帮助读者将前面学到的技术整合到一个实用的现场服务应用中。章节13 "Hacking Android" 探索了Android系统的可扩展性和自定义性，可能涉及系统级别的修改和优化。书末的附录详细指导了如何安装Android SDK，这是开始Android开发的基础。这本书是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页未读，继续阅读

dptest

粉丝: 0
资源: 1

深入探索Android：从基础到实战

google android揭秘(Unlocking Android的中文翻译版).part2

google android揭秘(Unlocking Android的中文翻译版).part1

mannnig最新<《unlocking android》源代码

Unlocking Android：开发者指南

进入UEFI界面不是fastboot

使用verliog语言编写：利用状态机编写密码锁，并将其烧入进Basys3开发板中

PLMN unlock

The account is locked

用python定义一个门的基类包含基本的大小属性和开门关门的抽象函数，设计一个普通木门和一个指纹锁的子类，实现特定的开门关门的函数。

最新资源