Mobile Device APIs Objectives

From MemberWiki

Jump to: navigation, search

This wiki page is one of several wiki pages for the Mobile TF work on Mobile Device APIs. Here are the pages:

Contents

Introduction

The Mobile OpenAjax APIs form an alternative platform for developing mobile Ajax applications. This is an attempt to capture the kind of industry-changing impact that OpenAjax Alliance aims to create as a result of current and future efforts in the area of mobile computing.

Here we identify the objectives of and principles behind the Mobile OpenAjax APIs. The objectives identify the interested stakeholders, the benefits are accrued to the various stakeholders and the relative importance of those benefits. The principles of are intended to guide the development of these APIs in order to achieve the objectives. We also describe future activities to orient the reader about the possible evolution paths for the OpenAjax Mobile APIs.

Objectives

Why developers of applications, manufacturers of systems, and the consuming public should care for Mobile OpenAjax.

Faster time-to-market
First and foremost, the APIs will benefit the mobile consumer. Ajax applications speed the delivery of mobile software by giving the end user a direct choice for selecting and using applications on their devices.
Unleashing innovation around rich mobile applications
Mobile OpenAjax APIs will bring to consumers high value applications that interact with device services while being delivered over the Web and having access to the open Web.
Reduce costs
By developing open standards for device services, by promoting device vendors and operators to adopt these standards, and by providing open source implementations of these standards, OpenAjax expects a major cost-reduction benefit. The result of Mobile OpenAjax APIs would be that developers are able to program to a ubiquitous and comprehensive mobile platform instead of having to code and test for each individual mobile platform.
Lightweight and reliable
The applications using and devices providing Mobile OpenAjax APIs are not sluggish or unreliable. They do not encumber the end user with additional burden or costs.

Principles

How the APIs are developed so that the above objectives are satisfied. These apply first and foremost to the designers of Mobile OpenAjax APIs and then to anyone who builds upon them.

Balance scope against usability and time-to-market
Focus initially on the 20/80 cases where a more limited set of common features address the most important use cases in order to deliver simplicity and accelerate time-to-market.
Make don't break
Don't take away things that work on existing Ajax platforms. Therefore, don't introduce mechanisms or abstractions that make it impossible or very hard to write Ajax applications that can work on, say desktop Web browsers. If the APIs work only on mobile devices or work very different on mobile devices than on desktop, they raise the cost of developing applications for mobile and non-mobile platforms.
Interoperable
The cost of developing and consuming applications can be kept down by the APIs that are made available in a non-preferential manner to all platforms and vendors without requiring licensing agreements.
User understandable security implications
Mobile Ajax applications puts the user in charge of security decisions (for which they need to be able to understand security). If system vendors (which includes platform vendors and carriers) need to make these decisions, we would be back to square one. If a feature introduces a vulnerability, then make sure that the vulnerability can be explained to an average person. This is necessary if we are to empower an average person to make the right security decision for themself. If they can't understand it, they won't make the right calls and end up blaming OpenAjax. If we entrust the decision to a third-party, such as a system vendor, then it would be detrimental to innovation as we have seen so far.
Modular
Separation of concerns or orthogonality is a general architecture principle. Good separation of concerns can be considered a reason why the conventional Web has succeeded till now. With different parts of the mobile Ajax technologies evolving at different rates and becoming ready for mass market at different times, it is even more important to carry over this success-inducing trait to mobile Ajax.
Forward looking
It is necessary to be forward looking in order to foster innovation. If innovation is only to make existing device capabilities available to browser applications, then innovation is going to end not too far from now. Although its hard to predict the future, don't preclude possibilities that can't be proven right now.
Extensible
Extensibility is a general architecture principle. Extensibility is the property of a technology that promotes evolution without sacrificing interoperability. Application developers and system manufacturers can extend these APIs for incremental evolution and niche solutions. It is possible for vendors to experiment with new features without creating an unwanted burden for anyone not interested in these extensions.
Ergonomic APIs
APIs should be consistent in their style and usage requirements.
JavaScript friendly
OpenAjax APIs are used primarily by JavaScript programs. Therefore, the APIs must be supportive of typical JavaScript design techniques such as dynamic loading and composition and the easy ability for toolkit developers and application developers to create custom JavaScript APIs to allow convenient functions to access a service or convenient functions to join together services.

Possible future activities

Here are some of the types of future activities that OpenAjax Alliance might pursue to accomplish the above high-level objectives. Note that the options listed below have multiple variations and are not mutually exclusive:

  • White papers (or other similar documents) - If the alliance has assembled a set of useful information that has educational or evangelical value for the community, it might collect that information into a published white paper or other document (e.g., a best practices document). For example, there has been some discussion about developing one or more white papers directed at security considerations relative to giving the Web Runtime access to device APIs.
  • Standards (or pre-standards) - OpenAjax Alliance might develop one or more specifications, such as a specification that defines industry standard APIs to access various mobile device services. Depending on the nature of the specification, a spec produced by OpenAjax Alliance start and end at the alliance, or it might be a "pre-standard" spec where the alliance does initial work towards defining technology and gaining industry consensus, but then turns over the specification to a different standards body for completion and formal approval.
  • Open source - OpenAjax Alliance might launch one or more open source efforts. For example, the alliance might develop a set of JavaScript that performs typical "Ajax library" features of providing a single API to mobile device APIs even though the underlying platforms are different, where this Ajax library takes care of the underlying platform differences.
  • Layered API model - (from David Pollington of Vodafone) Provide a layered API model whereby the full set of device APIs may be provided by the underlying platform but the developer has the freedom of developing his own set of 'working' APIs through JavaScript wrappers.
Retrieved from "http://www.openajax.org/member/wiki/Mobile_Device_APIs_Objectives"
Personal tools