Android Application Fundamentals

desktop operating system environments to the mobile operating system environment, 1.2 Brief History of Embedded Device Programming For a long time, cell phone developers comprised a small sect of a slightly larger group of developers known as embedded device developers. Seen as a less “glamorous” sibling to desktop—and later web—development, embedded device development typically got the proverbial short end of the stick as far as hardware and operating system features, because embedded device manufacturers were notoriously stingy on feature support. Embedded device manufacturers typically needed to guard their hardware secrets closely, so they gave embedded device developers few libraries to call when trying to interact with a specific device. Embedded devices differ from desktops in that an embedded device is typically a “computer on a chip.” For example, consider your standard television remote control; it is not really seen as an overwhelming achievement of technological complexity. When any button is pressed, a chip interprets the signal in a way that has been programmed into the device. This allows the device to know what to expect from the input device (key pad), and how to respond to those commands (for example, turn on the television). This is a simple form of embedded device programming. However, believe it or not, simple devices such as these are definitely related to the roots of early cell phone devices and development. Most embedded devices ran (and in some cases still run) proprietary operating systems. The reason for choosing to create a proprietary operating system rather than use any consumer system was really a product of necessity. Simple devices did not need very robust and optimized operating systems. As a product of device evolution, many of the more complex embedded devices, such as early PDAs, household security systems, and GPSs, moved to somewhat standardized operating system platforms about five years ago. Small-footprint operating systems such as Linux, or even an embedded version of Microsoft Windows, have become more prevalent on many embedded devices. Around this time in device

evolution, cell phones branched from other embedded devices onto their own path. This branching is evident when you examine their architecture. Nearly since their inception, cell phones have been fringe devices insofar as they run on proprietary software—software that is owned and controlled by the manufacturer, and is almost always considered to be a “closed” system. The practice of manufacturers using proprietary operating systems began more out of necessity than any other reason. That is, cell phone manufacturers typically used hardware that was completely developed in-house, or at least hardware that was specifically developed for the purposes of running cell phone equipment. As a result, there were no openly available, off-the-shelf software packages or solutions that would reliably interact with their hardware. Since the manufacturers also wanted to guard very closely their hardware trade secrets, some of which could be revealed by allowing access to the software level of the device, the common practice was, and in most cases still is, to use completely proprietary and closed software to run their devices. The downside to this is that anyone who wanted to develop applications for cell phones needed to have intimate knowledge of the proprietary environment within which it was to run. The solution was to purchase expensive development tools directly from the manufacturer. This isolated many of the “homebrew” developers. NOTE：A growing culture of homebrew developers has embraced cell phone application development. The term “homebrew” refers to the fact that these developers typically do not work for a cell phone development company and generally produce small, one-off products on their own time. Another, more compelling “necessity” that kept cell phone development out of the hands of the everyday developer was the hardware manufacturersrsquo; solution to the “memory versus need” dilemma. Until recently, cell phones did little more than execute and receive phone calls, track your contacts, and possibly send and receive short text messages; not really the “Swiss army knives” of technology they are today. Even as late as 2002, cell phones with cameras were not commonly found in the hands of consumers.

By 1997, small applications such as calculators and games (Tetris, for example) crept their way onto cell phones, but the overwhelming function was still that of a phone dialer itself. Cell phones had not yet become the multiuse, multifunction personal tools they are today. No one yet saw the need for Internet browsing, MP3 playing, or any of the multitudes of functions we are accustomed to using today. It is possible that the cell phone manufacturers of 1997 did not fully perceive the need consumers would have for an all-in-one device. However, even if the need was present, a lack of device memory and storage capacity was an even bigger obstacle to overcome. More people may have wanted their devices to be all-in-one tools, but manufacturers still had to climb the memory hurdle. To put the problem simply, it takes memory to store and run applications on any device, cell phones included. Cell phones, as a device, until recently did not have the amount of memory available to them that would facilitate the inclusion of “extra” programs. Within the last two years, the price of memory has reached very low levels. Device manufacturers now have the ability to include more memory at lower prices. Many cell phones now have more standard memory than the average PC had in the mid-1990s. So, now that we have the need, and the memory, we can all jump in and develop cool applications for cell phones around the world, right? Not exactly. Device manufacturers still closely guard the oper

剩余内容已隐藏，支付完成后下载完整资料

安卓应用基础

主要技巧和思想

● 历史的嵌入式器件编程

● 开放手机联盟的解释

● 第一眼看到Android的主屏幕

可以这么说，暂时，传统的桌面应用程序开发者已经被惯坏了。这个不是说 桌面应用程序开发比其他形式的开发很简单。总之，作为传统的桌面应用程序开发者，我们必须有能力创造出各种应用程序凡是我们能想象到的。包括我自己，因为我也是从做桌面程序开始的。 一方面已经使得桌面程序更容易理解就是我们已经有能力去跟桌面操作系统相互作用，因此，任何底部的硬件很自由的相互作用。这种类型独立自主的程序编制，然而，对于很小的开发者团体来说是不敢冒险的去搞手机发展这样浑浊的技术的。

注解：我提到两种不同的开发商在此讨论:传统的桌面应用程序开发，他们能在任何语言环境下工作，而且最终的产品和程序是用来运行“桌面”操作系统的；还有Android程序开发者，那些开发Android平台开发工具的JAVA程序开发人员。这不是说跟其他人比起来谁好谁坏。其实，区别目的仅仅在于想说明并比较Android桌面操作系统环境的开发风格，工具。 1.2 嵌入式器件编程的简要历史 有很长一段时间，手机的开发者由大的著名嵌入式的开发团队中的少数人组成，作为嵌入式设备的开发者。相对于桌面开发或者后续的网络开发，被视作更 少“魅力”，而且嵌入式设备的开发通常因为硬件和操作系统而处于劣势。因为嵌入式设备的制造商们太小气，他们要保护他们硬件方面的秘密，所以他们给开发者们非常有限的库去运行当他们尝试去让一些特定的设备去相互作用。 嵌入设备与桌面系统显著不同的一部分是嵌入设备是个有特色的“芯片上的电脑”。例如：考虑你的标准电话遥控。这个并不是一个非常强大并且复杂性的技术。当任何的按钮被按下去，一个芯片解释一个信号以一种方式已经被编程进了这个设备。这个允许设备知道什么是从输入设备（键盘）来的需要。并且如何的响应这些命令（比如，打开电视机）。这个是一个简单的嵌入式设备的编程。总之，不管你相不相信，像这样的简单设备绝对的和早期的手机设备开发的根源有着紧密的联系。 大多数的嵌入式设备运行（有些仍然还在运行）在私有的操作系统。原因是选择创建一个私有的操作系统而不是用任何消费系统是产品的需要。简单的设备不需要非常健全和优化的操作系统。 作为一个产品的演化，更多复杂的嵌入式设备，如早期的PDA，家庭安全系统和GPS等。5年前某种程度上都转移标准的操作系统平台上。小的操作系统如Linux,甚至一个微软版本的嵌入式平台，已经在嵌入设备上变得普遍了。设备改革的这段时间里，手机从其他嵌入式设备中分支出去。走上了自己的轨道，这个分支是显而易见的当你去调查他们的体系结构。 在他们最初开始的时候，手机作为一个外围设备并且运行私有软件，而这些软件被制造商们所拥有和控制，而且几乎可以被认为是一个“关闭”的系统。习惯使用私有操作系统主要是制造商自己开发硬件，或者至少定义了开发的目的只是用来运行手机。最终的结果就是使开放成为不可能。现有的软件包或者解决方案会可靠的和他们的硬件交互。而且，制造商想要保护他们硬件的商业秘密。以防允许进入而发现设备软件的水准。所以风尚就是，而且大多数仍然是使用完全私有并且关闭的软件来运行他们的设备。任何人想为手机开发程序必须需要详尽的私有环境来运行软件的知识。而解决方案就是直接从制造商那里购买昂贵的开发工具。这就孤立了很多的“自制软件”的开发者。 注解：一个关于自制软件开发的文化包含了手机程序的开发。“自制软件”是指开发者通常不是工作在手机开发公司内，通常利用自己的时间在他们的设备上生产小的，一次性的产品。 另外，使手机开发无法出手的是硬件制造商对于“内存和需要”左右为难的解决方案。直到最近，手机才能执行比打出和接听电话，查找联系人，发送和接收短消息。不是今天“瑞士军刀”的技术。及时在2002年，在消费者的手上，带照相机的手机还是不多见。在1997年，小的应用程序如计算器和游戏爬进了手机内，但是强大的功能仍然是手机的拨号盘本身。手机还不想今天一样是一个多用途，多功能工具。没有人预见互联网浏览的需求，MP3播放，或者更多的是我们今天定制的功能。在1997年，手机制造商们没有预见消费者需要的是一个一体化的设备。但是，即使这个需求展现出来，设备内存和存储容量还是一个需要克服的大的障碍。更多的人可能想要他们的设备是一个多功能一体化的工具，但是制造商们不许跨越他们的障碍。

让问题变得简单，就要在任何的设备让内存来存储并运行程序，包括手机。手机作为一个设备，直到最近还没有足够多内存来执行“额外”的程序。在最近的两年里，内存的价格已经达到了非常低的水平。设备制造商们有足够的能力压低价格来包含更多的内存。很多的现在的手机标准内存已经超过了90年代中期电脑内存。于是，现在我们有需求，而且有内存。我们可以直接跳到为手机开发酷的应用程序了，对吗？不完全是这样。设备的制造商们仍然紧密的保护他们的操作系统。有一些在手机上开放JAVA为基础的小运行环境。更多的是不允许。即使允许运行JAVA应用程序但还是不允许进入核心的系统。而这些是桌面开发者习惯于拥有的。

Android应用程序是用Java编程语言编写的，Android的SDK工具编译成代码和数据和资源文件放到一个Android的包，一个归档文件档案资源的.apk后缀，所有的在一个单一的代码.apk文件被认为是一个应用程序，是Android的文件，供电设备来安装应用程序。

一旦安装在设备上，每个Android应用程序的生命在它自己的安全沙箱：

• 而Android操作系统是一个多用户Linux系统中，每个应用程序是一个不同的用户。
• 默认情况下，每个应用程序的系统分配一个唯一的Linux用户ID（该ID仅用于由系统是未知的应用程序），系统设置所有的应用程序中的文件权限，以便只有用户ID分配给该应用程序可以访问它们。
• 每个进程都有它自己的虚拟机（VM），因此应用程序的代码在从其他应用程序隔离运行。
• 默认情况下，每个应用程序运行在它自己的Linux进程。Android的启动过程时，应用程序的任何组件需要被执行，然后关闭该进程时，它不再需要或恢复时，系统必须为其他应用程序的内存。

这样一来，Android系统实现了最小特权原则，也就是说，每个应用程序，默认情况下，只能访问的组件，它需要做的工作，没有更多，这将创建一个非常安全的环境，使应用程序无法访问的，这就是它没有给予许可的部分。

但是，有一个应用程序的方法与其他应用程序和应用程序访问系统服务的数据：

• 这有可能为两个应用程序安排共享相同的Linux用户ID，在这种情况下，它们能够相互访问的文件。为了节约使用相同的用户ID系统资源，应用程序还可以安排运行在相同的Linux进程和共享同一个VM（应用也必须使用相同的证书签名）。
• 应用程序可以请求访问权限，如用户的联系人，短信，可安装存储（SD卡），摄像头，蓝牙等设备的数据，所有应用程序的权限必须由用户在安装时授予。

这涵盖了基本就如何Android应用程序在系统中存在这个文件的其余部分向您介绍：

• 框架的核心组件定义应用程序。
• 清单文件中声明组件和应用程序所需的设备功能。
• 资源是从应用程序代码分开，并允许您的应用程序正常优化的设备配置各种其行为。

应用程序组件

Android的一个核心的特性就是一个应用程序可以使用其它应用程序的元素（如果那个应用程序允许的话）。例如，如果你的应用程序需要显示一个图片卷动列表，而另一个应用程序已经开发了一个合用的而又允许别的应用程序使用的话，你可以直接调用那个卷动列表来完成工作，而不用自己再开发一个。你的应用程序并没有吸纳或链接其它应用程序的代码。它只是在有需求的时候启动了其它应用程序的那个功能部分。

为达到这个目的，系统必须能够在一个应用程序的任何一部分被需要时启动一个此应用程序的进程，并将那个部分的Java对象实例化。因此，不像其它大多数系统上的应用程序，Android应用程序并没有为应用程序提供一个单独的入口点（比如说，没有main()函数），而是为系统提供了可以实例化和运行所需的必备组件。一共有四种组件类型：

(1)Activity

activity是为用户操作而展示的可视化用户界面。例如，一个activity可以展示一个菜单项列表供用户选择，戒者显示一些包含说明文字的照片。一个短消息应用程序可以包括一个用于显示要发送消息到的联系人列表的activity，一个给选定的联系人写短信的activity以及翻阅以前的短信或改变设置的其他activity。尽管它们一起组成了一个内聚的用户界面，但其中每个activity都不其它的保持独立。每一个都实现为以Activity类为基类的子类。

一个应用程序可以只有一个activity，戒者，如刚才提到的短信应用程序那样，包含很多个。每个activity的作用，以及有多少个activity，当然是取决于应用程序及其设计的。一般情况下，总有一个应用程序被标记为用户在应用程序启动的时候第一个看到的。从一个activity转向另一个靠的是用当前的activity启动下一个。

每个activity都被给予一个默认的窗口以进行绘制。一般情况下，这个窗口是满屏的，但它也可以是一个小的位于其它窗口之上的浮动的窗口。一个activity也可以使用附加的窗口——例如，一个在activity运行过程中弹出的供用户响应的对话框，这是一个当用户选择了屏幕上特定项目后显示的必要信息的窗口。

窗口显示的可视内容是由一系列层次化view构成的，这些view均继承自 View 基类。每个view均控制着窗口中一块特定的矩形区域。父级view包含并组织其子view的布局。叶节点view（位于层次结构最底端）在它们控制的矩形区域中进行绘制，并对用户直达其区域的操作做出响应。因此，view是activity与用户进行交互的界面。例如，view可以显示一个小图片，并在用户指点它的时候产生动作。Android有一些预置的view供开发者使用——包括按钮、文本域、滚动条、菜单项、复选框等等。

view的层次结构是由Activity.setContentView() 方法放入activity的窗口之中的。content view是位于层次结构根位置的View对象。（参见独立的用户界面文档以获取关于view及层次结构的更多信息。）

(2) Service

service没有可视化的用户界面，而是在一段时间内在后台运行。例如，一个service可以在用户做其它事情的时候在后台播放背景音乐、从网络上获取数据或者计算一些东西并提供给需要这个运算结果的activity使用。每个service都继承自Service基类。

一个媒体播放器播放播放列表中的曲目是一个不错的例子。播放器应用程序可能有一个或多个activity来给用户选择歌曲并进行播放。然而，音乐播放这个任务本身丌应该由任何activity来处理，因为用户的期望即使在他们离开播放器的应用程序而已经在开始做别的事情时，音乐仍然在继续播放。为达到这个目的，媒体播放器activity可以启动一个运行于后台的service服务。系统将在这个activity不再显示于屏幕后，仍维持音乐播放的service的运行。

连接至（绑定到）一个正在运行的service（如果service没有运行，则启动之）是可能的。连接之后，你可以通过那个service暴露出来的接口不service进行通讯。对于音乐service来说，这个接口可以允许用户暂停、回退、停止以及重新开始播放。

如同activity和其它的组件一样，service服务运行于应用程序进程的主线程内。所以它不会对其它组件或者用户界面有任何的妨碍作用，它们一般会派生一个新线程来执行一些时间消耗型任务（比如音乐回放和网络下载）。参见稍后的进程和线程介绍。

(3) BroadcastReceiver

broadcast receiver是一个与注于接收广播通知信息，并做出相应处理的组件。许多广播是由系统代码产生的——例如，通知时区改变、电池电量低、拍摄了一张照片或者用户改变了语言选项。应用程序也可以发起广播——例如，通知其它应用程序一些数据已经下载到设备上并处于可用状态。

一个应用程序可以拥有任意数量的broadcast receiver，以对所有它认为重要的通知信息予以各种响应。所有的receiver均继承自BroadcastReceiver基类。

broadcast receiver没有用户界面。然而，它们可以启动一个activity或者service来响应它们收到的信息，当然也可以使用NotificationManager来通知用户。通知可以用多种方式来吸引用户的注意力──闪动背光灯、震动设备、播放声音等等。通知一般是在状态栏上放一个持丽的图标，用户可以点击打开它并获取所要消息。

(4)Contentprovider

content provider将一些特定的应用程序数据供给其它应用程序使用处理。数据可以存储于文件系统、SQLite数据库或其它有意丿的方式。content provider继承于ContentProvider 基类，实现了一套使得其他应用程序能够检索和存储它所管理的类型数据的标准方法。然而，应用程序并不直接调用返些方法，而是使用一个 ContentResolver 对象，调用它的方法作为替代。ContentResolver可以与任何content provider进行会话；与其合作对任何相关的进程间通讯进行管理。

lt;

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[146129]，资料为PDF文档或Word文档，PDF文档可免费转换为Word