A Technical Overview of the Mobile Web : OTHER MOBILE TECHNOLOGIES

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
3/15/2012 3:08:01 PM

1. Apps and App Stores

Since the advent of Qualcomm's BREW and Java's J2ME technology in the early 2000s, mobile users have had the ability to download applications to their mobile devices. These applications (or "midlets" in the J2ME terminology) were simple at first, partly because the environments were limited and partly because the devices themselves did not feature powerful CPUs and graphic capabilities. Indeed, some of the first J2ME handsets did not even feature color displays.

As handset technology developed, however, such client-side technologies started to prove an effective way to add exciting functionality to devices that were not otherwise upgradable. The games industry in particular started to use J2ME and BREW as a way of delivering small games or ports of classic arcade titles, and devices started to support richer, faster APIs to allow such applications to do so effectively.

The advantages of even a client-side application are manifold. For a user, after the application has been downloaded, there is no limit to how or where it can be used, and since most applications do not require a network connection, there is no risk of incurring high data network charges. The applications can run full screen, store data locally, and access much of the handset's physical capabilities (such as the camera or audio hardware). For a network carrier or application provider, the single event of downloading an application is eminently billable, and beginning around 2005, mobile carriers' portals worldwide quickly filled with directories of games and utilities that could be downloaded for a few dollars.

However, such applications still require the user to have a correctly configured data connection in order to download them, and such directories remained notoriously difficult to search and navigate. When Apple launched its App Store in mid 2008, together with preconfigured support on its iPhone models which made it particularly easy to download and pay for applications, the concept of client-side mobile applications started to attract mainstream attention. Less than two years later, the App Store features 200,000 different applications and has provided 4 billion downloads.

Figure 1 shows Apple's App Store as it appears in iTunes on a user's computer. Purchased applications are then synchronized with the handset via a USB cable. More easily, users can browse and purchase applications directly from their iPhone, iPod, or iPad device, as shown in Figure 2, and download them over a cellular or wireless network.

Figure 1.

Figure 2.

This volume of traffic on Apple's App Store and the potential to allow users to pay for applications via their iTunes account causes lots of interest among developers, and currently a large and vibrant community of individuals and start-ups create games and applications for the iPhone. A significant number can be considered commercial successes, although many are available for free or do not become profitable given the common price point of a few U.S. dollars per application. More intriguingly, however, many larger companies or well-known brands have developed and published apps into the App Store, and in many cases these are designed to act much like a corporate website.

Figure 3 shows a screenshot of the BBC News application running on the iPhone platform, which shows a formatted version of the news feed from its website. Figure 2-18 shows an application made by fashion house Chanel, which amounts to little more than a simple synthesis of its corporate website.

Figure 3.

Figure 4.

Driven by the evident success of Apple's service, many other mobile device manufacturers have pursued similar strategies for getting third-party designed content onto their handsets. Google's Android Market provides applications for all handsets using that operating system and is known for being somewhat less moderated and quality-controlled than Apple's. Nokia's Ovi store provides downloads for the company's Symbian and Series 40 devices, and Palm, Blackberry, Microsoft, and others have similar, smaller services.

Many network carriers are also developing app stores for their own subscribers. A joint effort by at least 40 such companies — the Wholesale Applications Community (WAC) — endeavors to provide a similar, yet universal, application download platform for multiple handset and operating system platforms.

At the time of this writing, client-side applications are still a growing phenomenon, and most mobile users with suitable handsets have downloaded at least one to their device. Where does this all leave a mobile web developer? Although opinions vary, there is increasingly a consensus that mobile applications will not end up being the predominant, or certainly not the only, way of accessing third-party content on a mobile device. While many developers were drawn to the initial commercial attraction — and platform homogeneity — of Apple's App Store and iPhone environment, that enthusiasm has faded with the realization that only the most successful applications are commercially viable and that applications must be ported or rewritten for each client-side environment: There is no way to make an iPhone application run on a non-Apple device. Similarly, the increasing popularity of Google's mobile operating system has drawn developers to that platform, and yet the number of diverse device models that run Android introduces a new set of interoperability challenges.

Against this backdrop of jaded enthusiasm for investing in client-side applications, the mobile web yet again starts to become a compelling option for many developers. A mobile web browser may not (yet!) be the best runtime environment to host a high-performance application such as an action or arcade game, but for many other applications the web medium is indeed a feasible alternative for delivering a good experience to a mobile user.

The mobile web brings with it a number of particular attractions in this regard. First, the quality of mobile browsers and the popularity of the WebKit engine on higher-end devices (notably the same ones as those with app stores) means that rich, interactive web content is quite feasible. It is possible to create websites that are almost indistinguishable from a native application on a given device, and indeed some manufacturers provide guidelines concerning the HTML and CSS styling required to do this.

Second, devices are starting to provide richer APIs for web applications to access their local functionality and hardware. The BONDI set of standards prescribes how JavaScript-based scripts can access (with the user's permission) such local data as the device's file system, gallery, contacts and calendar. Similarly, there is the potential for web applications to access camera functionality, geolocation, and some telephony features of the device — all of which have previously been posited as reasons for choosing to build native applications. At the time of this writing, newly released models are starting to support such APIs. "Bridging" technologies, such as the popular PhoneGap, also allow you to write self-contained HTML- and JavaScript-based applications that can access native capabilities and APIs, on multiple platforms, in the meantime.

Third, and perhaps most critically, the mobile web provides a single, cross-platform medium for building applications and services that work on all the mobile operating systems and browsers. As you've seen, fragmentation and device diversity are a critical challenge, but it remains far easier to craft a mobile website that works reliably on all mobile devices than it would be to build or rewrite entirely different applications for every operating system. The fact remains that whichever platform you might choose to target first for a client-side application, the majority of your potential users will be using one of the others. A mobile website, conversely, can be given a respectable chance of working on every user's web-enabled handset from the day it is launched — and can be easily and centrally upgraded as it develops and grows.

As is surely becoming clear by now, the mobile industry is fast moving, and trends come and go.For most types of applications, an investment in web-based technology is likely to be more valuable in the long term than platform-by-platform client-side development.

Figure 5.

2. Mobile Widgets

Straddling the philosophies of both the native client and the mobile web, widgets are small applications built with mobile web technologies, and are installed on a user's device. Mobile widgets are similar to the widget concept found on desktop operating systems (where they often appear on the desktop or "dashboard" screens) and typically provide small, focused pieces of regularly updated information, such as sports scores, news tickers, or weather updates. Figure 2-19 shows a Nokia N770 Internet tablet running a selection of home screen widgets, including a news reader, a clock, and a search bar.

As far as developing widgets is concerned, most web developers will feel familiar with the standards used for mobile deployments: HTML, CSS, and JavaScript. But, in contrast to true web-based applications, widget component files are zipped into a compressed archive (along with a descriptor file) which can be downloaded and installed by users like an application. Because of their typically small size and low complexity, the widget approach is probably not suitable for helping to mobilize a full CMS-driven website. However, they can serve as useful promotional tools — for example, to display news from your site on the user's home screen — which when clicked will launch the user's full mobile browser to visit the site itself.

3. Messaging and Short Codes

Back in the mid- to late-1990s, and long before the advent of data network connections, mobile devices did not do much more than make and receive voice calls. But one small innovation in the original GSM Specification, which started off as little more than a mechanism for utilizing spare network capacity, soon became a global phenomenon: the Short Message Service (SMS), now known more colloquially as texting.

SMS originally provided the sending of a short text message (up to 160 characters in length) from one handset to another on the same mobile network. It served as a non-intrusive way for people to send small messages to friends, family, and colleagues. Given that nearly all devices at the time had numeric keypads, the length limit was not considered a particular restriction compared to the usability of typing them.

For several years, SMS remained of limited appeal, until the time when most networks allowed them to be sent from one network to another. A "viral" networking effect ensued as more people became familiar with the concept, and texting quickly became a mass-market medium. At the end of 2009, 4 billion messages were being sent daily, worldwide.

Since then, SMS has evolved from being a simple text protocol between individuals. The Enhanced Messaging Service (EMS) standard allowed users to insert formatting, animated icons, and simple sounds into their messages. A technically more complex successor, the Multimedia Messaging Service (MMS) standard, allows larger, richer messages containing sound, video, ringtones, and the like.

More importantly for this discussion, these messaging technologies are often used between users and automated systems, not just between individuals. Most network carriers provide gateways that permit external systems to send and receive SMS messages to and from users on their network, and a number of companies provide aggregator and wholesale messaging services to make such integrations easy across multiple network carriers.

From the point of view of a web developer, this provides a number of interesting possibilities. As well as delivering web pages to a mobile phone, it's almost as easy to send an SMS (or even an MMS) to the user (assuming you know his mobile telephone number). This provides a push mechanism to complement the pull philosophy of a website.

Further, most mobile carriers support short codes, which are shortened numbers, usually 3 to 5 digits long, that users can use to send messages to network systems or external gateways. By registering a short code (or leasing a keyword on an existing one), a website or other system can receive messages from users as well as send them.

Commonly, this configuration is used to promote mobile web-based services on products or printed media. For example, a soft drink can might feature a promotion urging the purchaser to "Text BUBBLE to 5557," and this message is routed to the confectioner's server registered with the BUBBLE keyword on short code 5557. In response, that server can send back an MMS or SMS containing a link to the mobile version of their website, and the user can click that to open her web browser and see the promotion. (Most mobile devices detect web addresses in text messages and render them as links for the user to click. For those that do not, it is also possible to send special binary "WAP push" messages that invoke the browser directly.)

Messaging can also become an integral way in which a web service interacts with its users. For example, the popular social networking site Twitter has both a website and a mobile website. But at its launch, the mobile user-interface for the service was predominantly SMS-based. As well as sending status updates to the service via a short code, users could send instructions to follow or unfollow other users via a special SMS syntax.

So although mobile messaging uses a set of technologies more or less distinct to the Web, it is important for you to remember that there are plenty of ways in which you can use SMS or MMS capabilities to augment, or help discover, any website.

4. Bar Codes

One of the common frustrations voiced by users of mobile websites is that entering a long and complex URL into a mobile browser can be arduous, even for those devices with full keyboards. This is one reason why mobile search and directory services have been popular. But there is still a need for site owners to be able to indicate to a user that a mobile website exists and to be able to help them navigate to it quickly.

You've seen how SMS messages sent to short codes can generate responses to users containing clickable links, but a more visual technique exists — in the form of mobile bar codes. These are mobile-device-readable images that contain encoded information that the device can act upon. Figure 2-20 shows a typical bar code containing a web address.

Pioneered in Japan in the last decade, a number of standards originally emerged to encode data in bar codes and in forms that are easily read by camera-enabled mobile devices. At the time of this writing, the most prevalent is the QR-code format shown in Figure 6, and most new devices contain built-in readers for them.

Figure 6.

Users simply start their bar code reader application, point the camera at the bar code itself (be itin printed media, on a billboard, or on a screen), and the device recognizes it and decodes the image. In the case of a code containing a web address, the reader typically opens the device browser and navigates directly to it, providing a quick and user-friendly way of attracting visitors to the site. Figure 7 shows such a reader in use.

Figure 7.

Although mobile bar codes have yet to see as much widespread use in the rest of the world as they have had in Japan, they remain a viable way to encourage users to visit mobile sites and make it easy for them to do so.

5. Geolocation and Augmented Reality

It's exciting to remember that a mobile device is not the same as a desktop computer. While that may seem obvious, it is important to remember the enhancements that a mobile device has over its larger cousin, rather than just the more evident limitations. In other words, you should constantly explore the characteristics of a mobile device that make it unique, not only in terms of its technology, but also the way in which it is used.

The word mobile is an adjective, and the fact that these devices can be held and used anywhere — the home, the office, the car, the street, the countryside — is itself a unique characteristic. More than that, the device itself, often in conjunction with the mobile network, can provide feedback as to exactly what that location is, at any time. Suddenly, every mobile user potentially owns a modern-day compass, sextant, and detailed world map in their hand.

For many years, the main way of locating a mobile device was a cellular-based process: by triangulating the relative positions of cell towers, a mobile carrier could determine a reasonable position for the device. But this information resided within the network and was not necessarily easy for third parties (such as mobile web developers) to access, notwithstanding the privacy concerns of doing so without user agreement.

In late 2006, however, mobile devices containing Global Positioning System (GPS) capabilities started to increase in number and became popular in the mid- to high-end market. Such devices use satellite positioning to determine their longitude, latitude, and altitude — without assistance from the cellular network — and expose this data to applications that run on the device.

Early to capitalize on this new capability, companies like Google started to provide mapping applications for mobile devices, where of course the most impressive feature was for the device to identify the user's location and plot it on the map. Additionally, by correlating those locations with the cells that the devices were using for their data connections, such services built up databases of cell tower locations, thereby providing approximate location services to those handsets still without GPS. (Similar databases that correlate WiFi access points to location further enhance this concept). More recently, most high-end devices now also include compass and accelerometer hardware, allowing applications to determine the device's direction and orientation as well as location.

Figures 8 and 9 show the Nokia Maps application running on a Symbian S60 device, which uses GPS positioning and provides satellite images, vector maps, and driving and walking directions between points.

Figure 8.

Figure 9.

As well as the capability for native client apps to access such geolocation data, mobile browsers themselves are increasingly able to do so via JavaScript APIs defined by the W3C. For websites and services that have location-based capabilities or relevance, this opens up lots of opportunities: Imagine a mobile user who doesn't have to type his location to find the nearest store on a retailer's website, for example.

As a result of this commoditization of the geolocation data itself, there has been a renaissance in services that are built upon it. Naturally, mapping and navigation applications are popular, but there has also been a rise in location-based social networks, such as Foursquare and Gowalla.

One of the most visually appealing applications of location data is known as augmented reality (AR), whereby a mobile device that has been geolocated is used to view information about the local area. By combining geolocation with data from a device's compass and accelerometer, a view (through the camera) of the user's surroundings can be overlaid with information and data. Figure 10 shows Wikitude, an augmented reality browser that overlays Wikipedia information onto the camera image.

At the time of this writing, such services are fairly new and still rapidly evolving. Suffice it to say, mobile devices provide a unique way to blend location, web-based data, and mobility, and it is highly likely that such technologies will evolve rapidly over the coming decade.

Figure 10.
Other -----------------
- A Technical Overview of the Mobile Web : THE MOBILE NETWORK
- Programming WCF Services : The Response Service (part 4) - Transactions
- Programming WCF Services : The Response Service (part 3) - Queued Service-Side Programming & Response Service-Side Programming
- Programming WCF Services : The Response Service (part 2) - Client-Side Programming
- Programming WCF Services : The Response Service (part 1) - Designing a Response Service Contract
- Programming WCF Services : Queued Versus Connected Calls - Requiring Queuing
- Programming WCF Services : Queued Services - Playback Failures
- DotNetNuke Skinning : Package and Deploy
- Unit Testing in Visual Studio 2010 (part 2) - Running a battery of tests
- Unit Testing in Visual Studio 2010 (part 1) - Creating unit tests
- Microsoft ASP.NET 3.5 : AJAX-Enabled Web Services - Remote Calls via Page Methods
- Microsoft ASP.NET 3.5 : WCF Services for ASP.NET AJAX Applications
- Mobile Game Networking Essentials : Network Programming and J2ME
- Mobile Game Networking Essentials : Multiplayer Game Basics & Network Game Problems and Solutions
- Software Testing with Visual Studio Team System 2008 : Debug and running web test (part 2) - Running the test
- Software Testing with Visual Studio Team System 2008 : Debug and running web test (part 1) - Settings for .testrunconfig file
- Visual Studio Team System 2008 : Web test editor (part 3) - Toolbar properties
- Visual Studio Team System 2008 : Web test editor (part 2) - Other request properties
- Visual Studio Team System 2008 : Web test editor (part 1) - Web test properties & Web test request properties
- Build Mobile Websites and Apps for Smart Devices : Design for Mobile - Standing on the Shoulders of Giants
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us