武汉理工信管协会活动管理APP应用开发外文翻译资料-开题报告网

Android: A Programmerrsquo;s Guide

1 What Is Android

1.1 Key Skills amp; Concepts

● History of embedded device programming

● Explanation of Open Handset Alliance

● First look at the Android home screen

It can be said that, for a while, traditional desktop application developers have

been spoiled. This is not to say that traditional desktop application development is

easier than other forms of development. However, as traditional desktop application developers, we have had the ability to create almost any kind of application we can

imagine. I am including myself in this grouping because I got my start in desktop

programming.

One aspect that has made desktop programming more accessible is thatwe have

had the ability to interact with the desktop operating system, and thus interactwith any underlying hardware, pretty freely (or at least with minimal exceptions). This kind of freedom to program independently, however, has never really been available to the

small group of programmers who dared to venture into the murky waters of cell phone development.

NOTE:I refer to two different kinds of developers in this discussion: traditional

desktop application developers, who work in almost any language and whose end

product, applications, are built to run on any “desktop” operating system; and Androiddevelopers, Java developers who develop for the Android platform. This is not for the purposes of saying one is by any means better or worse than the other. Rather, the distinction is made for purposes of comparing the development styles and tools of 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 a 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 p

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