What Is JavaScript?

When JavaScript first appeared in 1995, its main purpose was to handle some of the input validation that had previously been left to server-side languages such as Perl. Prior to that time, a round trip to the server was needed to determine if a required field had been left blank or an entered value was invalid. Netscape Navigator sought to change that with the introduction of JavaScript. The capability to handle some basic validation on the client was an exciting new feature at a time when use of telephone modems (operating at 28.8 kbps) was widespread. Such slow speeds turned every trip to the server into an exercise in patience.

Since that time, JavaScript has grown into an important feature of every major Web browser on the market. No longer bound to simple data validation, JavaScript now interacts with nearly all aspects of the browser window and its contents. Even Microsoft, with its own client-side scripting language called VBScript, ended up including its own JavaScript implementation in Internet Explorer from its very earliest version.

In this chapter, you will learn how and why JavaScript came about, from its humble beginnings to its modern-day, feature-packed implementations. To be able to use JavaScript to its full potential, it is important to understand its nature, history, and limitations. Specifically, this chapter examines:

• The origins of JavaScript and client-side scripting
• The different parts of the JavaScript language
• The standards related to JavaScript
• JavaScript support in popular Web browsers

A Short History

Around 1992, a company called Nombas began developing an embedded scripting language called C-minus-minus (Cmm for short). The idea behind Cmm was simple: a scripting language powerful enough to replace macros, but still similar enough to C (and C++) that developers could learn it quickly. This scripting language was packaged in a shareware product called CEnvi, which first exposed the power of such languages to developers. Nombas eventually changed the name Cmm to ScriptEase because the latter sounded “too negative” and the letter C “frightened people” (http://www.nombas.com/us/scripting/history.htm). ScriptEase is now the driving force behind Nombas products. When the popularity of Netscape Navigator started peaking, Nombas developed a version of CEnvi that could be embedded into Web pages. These early experiments were called Espresso Pages, and they represented the first client-side scripting language used on the World Wide Web. Little did Nombas know that its ideas would become an important foundation for the Internet.

As Web surfing gained popularity, a gradual demand for client-side scripting languages developed. At the time, most Internet users were connecting over a 28.8 kbps modem even though Web pages were growing in size and complexity. Adding to users’ pain was the large number of round-trips to the server required for simple form validation. Imagine filling out a form, clicking the Submit button, waiting 30 seconds for processing, and then being met with a message telling you that you forgot to complete a required field. Netscape, at that time on the cutting edge of technological innovation, began seriously considering the development of a client-side scripting language to handle simple processing.

Brendan Eich, who worked for Netscape at the time, began developing a scripting language called LiveScript for the upcoming release of Netscape Navigator 2.0 in 1995, with the intention of using it both in the browser and on the server (where it was to be called LiveWire). Netscape entered into a development alliance with Sun Microsystems to complete the implementation of LiveScript in time for release. Just before Netscape Navigator 2.0 was officially released, Netscape changed the name to JavaScript in order to capitalize on Java as a new Internet buzzword. Netscape’s gamble paid off and JavaScript became a must-have from that point on.

Because JavaScript 1.0 was such a hit, Netscape released version 1.1 in Netscape Navigator 3.0. Right around that time, Microsoft decided to throw its hat into the ring and released Internet Explorer 3.0 with a JavaScript-clone called JScript (so-called in order to avoid any possible licensing issues with Netscape). This major step for Microsoft into the realm of Web browsers is now a date that lives in infamy for Netscape, but it also represented a major step in the development of JavaScript as a language.

After Microsoft threw its hat into the ring, three different JavaScript versions were floating around: JavaScript in Netscape Navigator, JScript in Internet Explorer, and CEnvi in ScriptEase. Unlike C and many other programming languages, JavaScript had no standards governing its syntax or features, and the three different versions only highlighted this problem. With industry fears mounting, it was decided that the language must be standardized.

In 1997, JavaScript 1.1 was submitted to the European Computer Manufacturers Association (ECMA) as a proposal. Technical Committee #39 (TC39) was assigned to “standardize the syntax and semantics of a general purpose, cross-platform, vendor-neutral scripting language” (http://www.ecma-international.org/memento/TC39.htm). Made up of programmers from Netscape, Sun, Microsoft, Borland, and other companies with interest in the future of scripting, TC39 met for months to hammer out ECMA-262, a standard defining a new scripting language named ECMAScript.

The following year, the International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) also adopted ECMAScript as a standard (ISO/IEC-16262). Since that time, Web browsers have tried, with varying degrees of success and failure, to use ECMAScript as a basis for their JavaScript implementations.

JavaScript Implementations

Although ECMAScript is an important standard, it is not the only part of JavaScript, and certainly not the only part that has been standardized. Indeed, a complete JavaScript implementation is made up of three distinct parts :

• The Core (ECMAScript)
• The Document Object Model (DOM)
• The Browser Object Model (BOM)

ECMAScript

ECMAScript doesn’t have ties to any browser in particular and, actually, has no methods for user input or output to speak of. (It is not unlike languages such as C, which rely on external libraries to accomplish such tasks.) So what is ECMAScript? ECMA-262 (p. 2) describes it like this:

“ECMAScript can provide core scripting capabilities for a variety of host environments, and therefore the core scripting language is specified...apart from any particular host environment.”

A Web browser is considered a host environment for ECMAScript, but it is not the only host environment. Indeed, numerous other environments (such as Nombas’s ScriptEase and Macromedia’s ActionScript, used in both Flash and Director MX) can host ECMAScript implementations. So what does ECMAScript specify outside of a browser? To put it simply, ECMAScript describes the following:

• Syntax
• Types
• Statements
• Keywords
• Reserved Words
• Operators
• Objects

ECMAScript is simply a description, defining all the properties, methods, and objects of a scripting language. Other languages implement ECMAScript, as JavaScript does (see Figure 1-2), as the baseline for functionality.

Each browser has its own implementation of the ECMAScript interface, which is then extended to contain the DOM and BOM (discussed in the following sections). There are other languages that also implement and extend ECMAScript such as Windows Scripting Host (WSH), ActionScript in Macromedia Flash and Director, and Nombas ScriptEase.

ECMAScript editions

ECMAScript is separated into editions rather than versions because it is defined in a standard called ECMA-262. Like any standard, ECMA-262 can be edited and updated. When a major update occurs, a new edition of the standard is published. The most recent edition of ECMA-262 is edition 3, released in December of 1999. The first edition of ECMA-262 was essentially the same as Netscape’s JavaScript 1.1 with all browser-specific code removed, but with a few changes. First, ECMA-262 required support for the Unicode Standard (to support multiple languages). Second, it required that objects be platformindependent (Netscape’s JavaScript 1.1 actually had different implementations of objects, such as the Date object, depending on the platform). This was a major reason why JavaScript 1.1 and 1.2 did not conform to the first edition of ECMA-262.

The second edition of ECMA-262 was largely editorial in nature. The standard was updated in order to get into strict agreement with ISO/IEC-16262 and didn’t feature any additions, changes, or omissions. ECMAScript implementations typically don’t use the second edition as a measure of conformance.

The third edition of ECMA-262 was the first real update to the standard. It provides updates to string handling, the definition of errors, and numeric outputs. It also adds support for regular expressions, new control statements, try...catch exception handling, and small changes to better prepare the standard for internationalization. To many, this marked the arrival of ECMAScript as a true programming language.

What does ECMAScript conformance mean?

In ECMA-262, the definition of ECMAScript conformance is laid out. A scripting language must subscribe to four basic tenets:

• A conforming implementation must support all “types, values, objects, properties, functions, and program syntax and semantics” (ECMA-262, p. 1) as they are described in ECMA-262.
• A conforming implementation must support the Unicode Character Standard.
• A conforming implementation may add “additional types, values, objects, properties, and functions” that are not specified in ECMA-262. ECMA-262 describes these additions as primarily new objects or new properties of objects not given in the specification.
• A conforming implementation may support “program and regular expression syntax” that are not defined in ECMA-262 (meaning that the built-in regular expression support is allowed to be altered and extended).

All implementations of ECMAScript must be in agreement with these criteria.

ECMAScript support in Web browsers

Netscape Navigator 3.0 shipped with JavaScript 1.1 in 1996. That same JavaScript 1.1 specification was then submitted to the ECMA as a proposal for a new standard. With JavaScript’s explosive popularity, Netscape was very happy to start developing version 1.2. One problem: ECMA hadn’t yet accepted Netscape’s proposal.

A little after Netscape Navigator 3.0 was released, Microsoft introduced Internet Explorer 3.0. This version of IE shipped with JScript 1.0 (Microsoft’s name for its JavaScript implementation), which was supposed to be equivalent to JavaScript 1.1. However, because of undocumented and improperly replicated features, JScript 1.0 fell far short of JavaScript 1.1.

Netscape Navigator 4.0 was shipped in 1997 with JavaScript 1.2 before the first edition of ECMA-262 was finalized; ECMA-262 was accepted and standardized later that year. As a result, JavaScript 1.2 is not compliant to the first edition of ECMAScript, even though ECMAScript was supposed to be based on JavaScript 1.1.

The next update to JScript occurred in Internet Explorer 4.0 with version JScript 3.0 (version 2.0 was released in Microsoft’s Internet Information Server version 3.0 but was never included in a browser). Microsoft put out a press release touting JScript 3.0 as the first truly ECMA-compliant scripting language in the world. At that time, ECMA-262 hadn’t yet been finalized, so JScript 3.0 suffered the same fate as JavaScript 1.2: It did not comply with the final ECMAScript standard.

Netscape opted to update its JavaScript implementation in Netscape Navigator 4.06. JavaScript 1.3 brought Netscape into full compliance with ECMAScript Edition 1. Netscape added support for the Unicode standard and made all objects platform-independent while keeping the features that were introduced in JavaScript 1.2.

When Netscape released its source code to the public as the Mozilla project, it was anticipated that JavaScript 1.4 would be shipped with Netscape Navigator 5.0. However, a radical decision to completely redesign the Netscape code from the bottom up threw a monkey wrench into the works. JavaScript 1.4 was only released as a server-side language for the Netscape Enterprise Server and never made it into a Web browser.

Today, all popular Web browsers comply with the third edition of ECMA-262. The following table lists ECMAScript support in the most popular Web browsers:

The Document Object Model (DOM)

The Document Object Model (DOM) is an application programming interface (API) for HTML as well as XML. The DOM maps out an entire page as a document composed of a hierarchy of nodes. Each part of an HTML or XML page is a derivative of a node. Consider the following HTML page:

<html>

<head>

<title>Sample Page</title>

</head>

<body>

<p>Hello World!</p>

</body>

</html>

This code can be diagrammed into a hierarchy of nodes using the DOM (see Figure here).

By creating a tree to represent a document, the DOM allows developers an unprecedented level of control over its content and structure. Nodes can easily be removed, added, and replaced by using the DOM API.

Why the DOM is necessary

With Internet Explorer 4.0 and Netscape Navigator 4.0 each supporting different forms of Dynamic HTML (DHTML), developers for the first time could alter the appearance and content of a Web page without reloading it. This represented a tremendous step forward in Web technology, but also a huge problem. Netscape and Microsoft each went its own way in developing DHTML, thus ending the period when Web developers could write a single HTML page that could be accessed by any Web browser.

It was decided that something had to be done to preserve the cross-platform nature of the Web. The fear was that, if someone didn’t rein in Netscape and Microsoft, the Web would develop into two distinct factions that were exclusive to targeted browsers. It was then that the World Wide Web Consortium (W3C), the body charged with creating standards for Web communication, began working on the DOM.

DOM levels

DOM Level 1 became a W3C recommendation in October of 1998. It consisted of two modules: the DOM Core, which provided a way to map the structure of an XML-based document to allow for easy access to and manipulation of any part of a document, and the DOM HTML, which extended the DOM Core by adding HTML-specific objects and methods.

Note that the DOM is not JavaScript-specific, and indeed has been implemented in numerous other languages. For Web browsers, however, the DOM has been implemented using ECMAScript and now makes up a large part of the JavaScript language.

Whereas DOM Level 1’s only goal was to map out the structure of a document, DOM Level 2’s aims were much broader. This extension to the original DOM added support for mouse and user interface events (long supported by DHTML), ranges, traversals (methods to iterate over a DOM document), and support for Cascading Style Sheets (CSS) through object interfaces. The original DOM Core introduced in Level 1 was also extended to include support for XML namespaces.

DOM Level 2 introduced several new modules of the DOM to deal with new types of interfaces:

• DOM Views — describes interfaces to keep track of the various views of a document (that is, the document before CSS styling and the document after CSS styling)
• DOM Events — describes interfaces for events
• DOM Style — describes interfaces to deal with CSS-based styles
• DOM Traversal and Range — describes interfaces to traverse and manipulate a document tree

DOM Level 3 further extends the DOM with the introduction of methods to load and save documents in a uniform way (contained in a new module called DOM Load and Save) as well as methods to validate a document (DOM Validation). In Level 3, the DOM Core is extended to support all of XML 1.0, including XML Infoset, XPath, and XML Base.

When reading about the DOM, you may come across references to DOM Level 0. Note that there is no standard called DOM Level 0; it is simply a reference point in the history of the DOM (DOM Level 0 is considered to be the original DHTML supported in Internet Explorer 4.0 and Netscape Navigator 4.0).

Other DOMs

Aside from the DOM Core and DOM HTML interfaces, several other languages have had their own DOM standards published. The languages are XML-based and each DOM adds methods and interfaces unique to that language:

• Scalable Vector Graphics (SVG) 1.0
• Mathematical Markup Language (MathML) 1.0
• Synchronized Multimedia Integration Language (SMIL)

Additionally, other languages have developed their own DOM implementations, such as Mozilla’s XML User Interface Language (XUL). However, only the languages in the preceding list are standard recommendations from W3C.

DOM support in Web browsers

The DOM was already a standard for some time before Web browsers started implementing it. Internet Explorer took first stab in version 5.0, but it actually didn’t have any realistic DOM support until version 5.5, when it implemented most of DOM Level 1. Internet Explorer hasn’t introduced new DOM functionality since that time.

For Netscape, no DOM support existed until Netscape 6 (Mozilla 0.6.0) was introduced. To date, Mozilla has the best support for the DOM, implementing all of Level 1, nearly all of Level 2, and some parts of Level 3. (The goal of the Mozilla development team was to build a 100% standards-compliant browser, and their work paid off.)

Latecomers such as Opera, which didn’t add DOM support until version 7.0, and Safari, which has implemented most of DOM Level 1, are mostly on par with Internet Explorer 5.5; and in some cases, they exceed it. However, all the browsers are still a distant second to Mozilla as far as DOM support goes. The following table shows DOM support for popular browsers:

The Browser Object Model (BOM)

The Internet Explorer 3.0 and Netscape Navigator 3.0 browsers feature a Browser Object Model (BOM) that allows access and manipulation of the browser window. Using the BOM, developers can move the window, change text in the status bar, and perform other actions that do not directly relate to the page content. What makes the BOM truly unique, and often problematic, is that it is the only part of a JavaScript implementation that has no related standard.

Primarily, the BOM deals with the browser window and frames, but generally any browser-specific extension to JavaScript is considered to be a part of the BOM. Such things include:

• The capability to pop up new browser windows.
• The capability to move, resize, and close browser windows.
• The navigator object, which provides detailed information about the Web browser.
• The location object, which gives detailed information about the page loaded in the browser.
• The screen object, which gives detailed information about the user’s screen resolution.
• Support for cookies.
• Internet Explorer extends the BOM to include the ActiveXObject class, which can be used to instantiate ActiveX objects through JavaScript.

Because no standards exist for the BOM, each browser has its own implementation. There are some de facto standards, such as having a window object and a navigator object, but each browser defines its own properties and methods for these and other objects. Chapter 5, “JavaScript in the Browser,” goes into more detail about the implementation differences.

Summary (Conclusion)

This chapter introduced JavaScript as a client-side scripting language for Web browsers. You learned about the various parts that make up a complete JavaScript implementation:

• ECMAScript, the core of JavaScript, describes the language syntax and basic objects.
• The Document Object Model (DOM) describes methods and interfaces for working with the content of a Web page.
• The Browser Object Model (BOM) describes methods and interfaces for interacting with the browser.

Additionally, you explored the history of JavaScript to gain an understanding of how various parts of the language developed and how browsers historically have dealt with the implementation of standards.

Thanks, best Regards !

Source : book of Professional JavaScript™ for Web Developers by Nicholas C. Zakas

Read more »

Java ME History

A mobile information device (MID) is usually understood to be a computer that you can hold in your hand. Such devices are familiar in the world today as cell phones, iPods, iPhones, and BlackBerries. All such devices have their own operating system, but at the same time, they are developed according to standards that international organizations and corporations have established. Java is a popular language for programming such devices because Java runs on a virtual machine. Sun can create a virtual machine for almost any device, and for this reason, Java has become the premier language for mobile information device programming. For those unfamiliar with Java and mobile information device programming, this chapter provides a few introductory notes. It is not intended as a comprehensive introduction to the topic, but it presents a brief outline of the history of the Java programming language and related technologies. It also discusses the capabilities and limitations of mobile phones.

Java’s Acorn

In early 1995, Sun Microsystems released an alpha version of a new software environment called Java. During the first six months after Java’s release, many people in the software development industry spent their time exchanging bad jokes and puns about coffee beans and Indonesian islands. It didn’t take long, however, for the slogan of ‘‘Write Once, Run Anywhere’’ to supplant the jokes and puns. Java was taken up by thousands of developers, and Java began itsmarch to the top.

The earliest traces of Java go back to the early 1990s, when Sun formed a special technical team (known as the Green Team) tasked with developing the next wave of computing. After an 18-month development effort, the team emerged with the result: a handheld home-entertainment device controller with a touchscreen interface known as the *7 (Star Seven).

The real action, however, was not with the *7 or the device running it; it was with the backend technology that powered it. One of the requirements of the project was a robust, hardware-independent, embedded software environment that facilitated low-cost development.

At this point, James Gosling entered the picture. Gosling, a Canadian software engineer working with the Green Team, was the primary designer of Java. He began to develop the basics of Java by using some of the best elements of C++, such as its general syntax features and object-orientation. He excluded such things as memory management, pointers, and multiple inheritance. Gosling endeavored to create a simple, elegant language that developers could use to quickly deploy applications.

Gosling’s first version of Java, called Oak, ran on the *7 device and featured the familiar Java mascot Duke. Oak’s power wasn’t only in its language design; there were plenty of other object-oriented languages. Oak blossomed because it encompassed everything. Gosling did not create a language and then let other people implement it as they saw fit. The goal of Oak was hardware independence, and with that in mind he created a complete software deployment environment. From virtual computers to functional application programming interfaces (APIs), Oak provided—and, more importantly, controlled—everything.

Unfortunately, the *7 did not last long. The notion of running programs on a fixed device (and devices in this respect ranged from toasters to garage door openers) was promising but not what was really needed. What was really needed was something that went worldwide during the mid-1990s: the Internet. With the help of developers such as Bill Joy, Wayne Rosing, John Gage, Eric Schmidt, and Patrick Naughton, Gosling was able to make Java a core programming language for the Internet.

The Internet emerged as the predominant technology of the day. Browsers could be used to transfer and display digital content in the form of pictures, text, and even audio almost universally on a variety of hardware. Servers could link millions of Internet users. Java proved ideal as a programming language that could accommodate the needs of both browsers and servers.

The goals of the web were not dissimilar to that of Oak: provide a system to let you write content once, but view it anywhere (running on a variety of operating systems). Oak was designed to allow programmers to develop on different devices. Programs running on servers or applications running in browsers amounted to the same thing. The Internet became the framework within which Oak software could be distributed and universally deployed.

Java’s Growth in the Sun

Given the match between the needs of the Internet and the design of Oak, the mission and description of Java soon emerged from Oak. Gosling and the team at Sun developed a host of technologies around the concept of a universally deployable language and platform. One of their first tasks was to develop the Java-compatible browser known as HotJava. (The early versions were named WebRunner, after the movie Blade Runner.) shows the original HotJava browser.

If Sun sought to dominate the Internet through HotJava and distribute Java in that way, something even better soon arose. On May 23, 1995, the Netscape Corporation agreed to integrate Java into its popular Navigator web browser, thus creating an unprecedented audience for the Java software.

Soon programmers from all over the globe flooded the Java website to download the new platform. Sun completely underestimated the platform’s popularity and struggled to increase bandwidth to cope with the rush. Java had arrived.

Development of the Java platform has continued ever since. As the years have passed, it has been expanded to include a number of technologies, such as JSP and XML. Interface components have been rewritten as Swing. The overall platform has been expanded to meet database and security needs. Each new release brings new supporting technology.

Despite Java’s complexity, one of its great attractions continues to be Gosling’s original design. The syntax remains elegant, the development effort proves much easier than it is in many other languages, and the work of documenting and debugging is much more straightforward.

What Is Java?

Java is an object-oriented programming language that you compile to byte code that runs on a virtual machine. In this respect, it differs from traditional programming languages such as C. The C programming language remains a strong foundation language, but it is also a procedural programming language (based on functions). C++ is the object-oriented precursor of Java, but to develop with C++, programmers compile their code directly to a specific operating system. (Microsoft has changed this picture with managed C++.)

ANSI-compliant C++ makes it possible to port code from one operating system to another with relative ease, but programs still must be recompiled as you move them from operating system to operating system. With Java, programmers can either compile or interpret code.

As Figure illustrates, the initial compile phase translates your source code (*.java files) into an intermediate language called Java bytecode (*.class files). The resulting bytecode is then ready to be executed (interpreted) within a special virtual computer known as the Java

Virtual Machine (JVM).

The JVM is a simulated computer that executes bytecode instructions. It acts as a consistent layer between bytecode and the actual machine instructions. Bytecode instructions are translated into machine-specific instructions by the JVM at runtime. This enables programmers to write one program and run it on different operating systems without having to engage in extensive rewriting (porting) work.

The expression often used to sum up the work of the JVM is ‘‘Write once, run anywhere.’’ As Figure 1.4 illustrates, the target platform for a Java program requires only a JVM. Sun provides a JVM specific to each platform (or operating system), and after the JVM is installed, the Java program can run in it regardless of which environment it was developed in.

Running a Java program remains elementary. Developing a Java program involves a bit more activity. You need more than just a programming language; you need a programming platform. The Java platform is made up of three significant components :

• The Java Development Kit
• The Java Virtual Machine
• The Java Application Programming Interface

The Java Development Kit (JDK) is the general name for the entire suite of tools that allows you to develop with Java. Central to this are the compiler and its associated tools. As mentioned previously, the role of the JVM is to provide an interface to the operating system of the underlying device. The Java API provides a limited view of the operating system to the Java program. This makes the JVM the judge, jury, and executor of program code.

The Java API is a collection of Java classes covering a vast range of functionality including containers, data management, communications, IO, and security. There are close to a thousand basic classes available as part of the Java API. Secondary developers provide thousands more that extend and specialize the API.

Multiple Editions

The Java language has evolved over the years. The first major edition, now known as the Java 2 Standard Edition (J2SE) was aimed at the development of GUIs, applets, and other standalone applications. A few years ago Sun expanded the Java suite with the Java 2 Enterprise Edition (J2EE), which was built for use in server-side development. This version included expanded tools for database access, messaging, content rendering, inter-process communications, and

transaction control.

Sun didn’t stop there, though. Desperate to satisfy every programmer on the planet, Sun set its sights on handheld or portable devices. The version of Java Sun designed for these devices is designated Java 2 Micro Edition (J2ME). The current version of Java has been incremented beyond the first release, so Sun often refers to it simply as Java ME.

Mobile Information Devices Everywhere

Mobile information devices are generally small enough to carry in your pocket or purse. The most popular such devices are cell phones, iPods, and iPhones. Sun manufactures special versions of its Java virtual machine to allow your Java programs to execute on such devices. Since such devices are available in every description, the virtual machine approach to application deployment enjoys the same advantage with MIDs that it enjoys with the Internet. You can write an application on one operating system and deploy it to many others.

The purpose of portable Java programs is often to provide an interface for the user. Device manufacturers create operating systems that manage such things as games, telecommunications, or music. The user of such devices browses the Internet, answers a phone call, receives a text message, manages and selects tunes, or plays games. The games you find on such devices are often fairly basic, but with each new day, as the memory, speed, and virtual machine profiles of the devices improve, the software built to run on them increases in complexity.

Applications once considered too large for portable devices are now becoming common features of them.What is significant about this is the sheermagnitude of the market calling for this transformation. Cell phone manufacturers deal with a market that includes billions of possible users. Cell phones are so inexpensive that they are often given away as part of a telecommunications package. The device becomes trivial. The interface and services become much more significant. What applies to cell phones applies in general to all mobile devices. As the hardware decreases in significance, the software and services become more important.

It is generally not at all unreasonable to imagine a world (of over six billion people to date) in which everyone from childhood on is equipped with one or two portable devices. Picture a cell phone and an iPod to start with. In time these might be merged into a single device (like the BlackBerry or iPhone), but the general market for applications to run on such devices remains the same.

As a slight digression, it is important to remember that mobile devices often have very specific and somewhat humble market niches. Consider, for example, a device that is responsible for monitoring the output of a microtransmitter embedded in an automobile tire. By pressing a few buttons, a mechanic can see the tread depth and tire pressure of the tire. This basic information is then fed to a PC with an Internet connection. Someone in a back office can then monitor the status of the tire. This technology can be extended to the shoes of runners in a marathon. If a transmitter is clipped to each running shoe, as runners run by given auditing points, their names and times can be fed into a central database and displayed on a website. All the applications involved might be developed with Java. All involve MID development.

Micro Devices and Software

MIDs are often referred to as micro devices. As you will see in Chapter 2, the support for such micro devices broadens as different devices come into the picture. Figure overhead shows several categories of micro devices.

Generally, large corporations can afford (at least to an extent) to create and deploy proprietary development platforms for the devices they produce. In most cases, Java ME provides you with the ability to make use of some of the features of the proprietary development platforms. To use some of these development platforms, you must pay a license fee. In other cases, you can obtain the software for free, but you must integrate software modules with your Java code.

Over the past two decades, micro-device manufacturers have provided programmers and other content creators with various sets of tools to build software applications. This approach to development has met with greater and lesser degrees of success. Generally, the trend now favors open approaches like Java,

and almost every major device manufacturer has made a strong effort to incorporate Java ME. The tendency in this respect is toward standardization of hardware and software. Device manufacturers realize that their surest path to the broadest market is through the interoperability Java provides.

some of the categories into which proprietary efforts have fallen.

Conclusion

With millions of programmers and worldwide distribution, Java is an enormously popular development platform. As a language, it is easy to learn. Given the extraordinary store of libraries and other supplements that exist for Java, mastery of it is probably no longer a possibility for any lone individual. Still, if you can learn how to work with the basic development environment, whether itis the general JDK or a specialized version of the JDK such as Java ME, you are probably on your way to a lifetime of work.

Developing software for portable devices is one of the key areas of development for Java programmers. The programs they produce often center on user interfaces, which vary according to the device on which the interface is deployed and the market the device manufacturer or service provider targets. One of Java’s strengths is that it allows developers to provide software that is both portable and safe for deployment on different devices.

Warmes Regards !

Soure : Thomson Course Technology PTR, a division of Thomson Learning Inc. book of Java™ ME Game Programming second edition by John P. Flynt, Ph.D., and Martin J. Wells

Read more »

Introducing about Website

Ringkasan ini tidak tersedia. Harap klik di sini untuk melihat postingan.

Read more »