Effect of Data Traffic Explosion on Mobile LBS

These days it is hard to go to any mobile conference without hearing someone talking about the pending explosion of data traffic volume brought on by the dawn of the Internet video age.  If you haven't tuned into the latest yet, GigaOM has a nice recap on the latest Cisco traffic study.  Is there a correlation between this onslaught of data volume and mobile LBS?  You bet.  Read on.

A key issue in mobile LBS is location accuracy and positioning duration.  Today, a mobile location is typically estimated from either GPS signals or cell towers.  GPS is well suited for high-accuracy LBS applications such as car navigation.  But the consumer applications of GPS have long been hindered by technology limitations such as long signal acquisition time and limited signal coverage.  The recent boom of mobile LBS has largely been fueled by cell-based positioning technologies.  Unlike GPS coverage, cell locations are not only much quicker to obtain but also 100% available both outdoors and indoors.  The accuracy of a cell location depends on the cell size.  The smaller the cell-size, the more accurate the cell-derived location.  This where the looming data explosion will benefit LBS.

A two-part series, titled "The Network Paradox: Meeting the Mobile Data Demand", quoted industry sources as saying that the only way to increase mobile data capacity by more than 9X is to deploy 4 or more times of cell sites.  These new cell sites will lead to at least 2 times reduction of the overall cell size according to cellular traffic engineering rules.

So, mobile LBS will see its better days ahead.

A Gotcha Moment with the View Attribute android:id

When editing layout xml files using Google's Eclipse plugin, the plugin is usually smart enough to flag typos when they cause code generation problems. However, errors that slip through the plugin undetected can cause nasty bugs at run-time. One such error involves the use of the attribute android:id. Usually, an id should be specified like this:

<!-- Correct Syntax -->
<Button android:id="@+id/abutton" />

But the following XML will compile fine without any error:

<!-- Incorrect Syntax -->
<Button id="@+id/xbutton" />

Android will even draw the button on the screen. The gotcha moment comes when you try to lookup this button in the view on a newer (such as Android 2.1) emulator/device:

Button aButton = (Button) thisView.findViewbyId(R.id.xbutton);

The aButton variable will be null after this call! What makes this a particularly hideous bug is that it was actually valid pre-Android 1.6! So apparently, the plug-in and the compiler are made backward compatible to allow the old syntax but not the run-time. Welcome to the bleeding edge...