The embedded approach is without doubt the most flexible of all the options, so we could say that it is the ‘king’ of approaches. Anything that a particular device is capable of being programmed to do is theoretically possible using the embedded approach. There are fewer restrictions on accessing the underlying device resources, as compared to the other approaches. This is because the embedded approach provides the ability to get right down to the guts of the device and programmatically access its low-level functions and hardware peripherals. In practice, the level of programming power available is determined by the provisions made available by the device manufacturer to third-party programmers, such as APIs, documentation and related programming tools. These considerations will become clearer as we progress.

Consider coming up with a new method of handwriting recognition. In theory, we could program the solution as an embedded application. Using a browser approach, we would not have sufficient access to the device resources. Although, to be fair, the browser paradigm is not intended to allow for this degree of flexibility – the programming and interface model is deliberately simplified for good reasons. Functional extensions to the browser might be possible4, but this would involve a hybrid approach that still requires that the extended functions be programmed as an embedded application.

An embedded application runs on the main device processor on top ...

Get Next Generation Wireless Applications: Creating Mobile Applications in a Web 2.0 and Mobile 2.0 World, 2nd Edition now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.