Barrier #3 - Too many markup languages!
When we were finally ready to begin building our first mobile application, HDML (Handheld Device Markup Language) was all the rage.Conceptually like HTML, but optimized for mobile phones, the developer created 'pages' that were part of 'decks'.A deck was limited to about 2000 characters.As the specs and related documentation for these markup languages seemed to change daily, you were never quite sure if you were doing something the right way, or just getting it to work.We were always happy to just get something to work and considered this quite an accomplishment!
When we finally had a reasonable application running serving out HDML, WML (Wireless Markup Language) comes along.It was basically the same thing as HDML, but had been adopted by a different set of devices as standard. Our HDML app was useless on these devices of course, so a few 1000 prints and ifs later we sort of had an application that served WML.But WML's concept of a deck and the associated navigation model were just different enough that a one-to-one port wasn't possible - A lot of our UI logic broke as we moved between the 2 markups, calling for more than a simple development exercise.
When we had finally conquered the 2 major markup languages, our testing showed (and Google helped verify) that there were some not so subtle differences in how different phones actually interpreted and displayed them.We began to write our own device detection code to handle these exceptions directly. A slippery slope to say the least, as the proliferation of markup languages and their dialects was spiraling through the roof, and it was clear that dealing with them could become a full time job.
ASP .NET Mobile Controls, mentioned in the previous section on IDE's,
was born to solve this problem and shield me, the already maxed application
developer, from having to deal with the issue of markup language variations.
As it lives within Visual Studio .NET, the developer works visually
and intuitively, dragging UI elements onto a form and double clicking on
these elements to add their code in Visual Basic or C#.Sound familiar?
Behind the scenes at runtime, the application detects the device that is
connecting and consults it's vast database of device characteristics to
decide how to best deal with UI details such as how a listbox should be
presented to the user or if their device can handle graphics.Markup optimized
for the device is served out automatically.I focus on my business logic,
and let the technology at hand do the heavy lifting for me.
Barrier # 4 - GIS was hard and expensive
At NearMe I was privileged to be working with one of the founders of
MapInfo Corporation, John Haller, along with one of MapInfo's original
developers and software architects, Joe Schwartz.Between them, they had
nearly infinite wisdom related to mapping technologies.It seemed logical
that we would set out to build our LBS applications on the legacy GIS systems
we knew so well.As we quickly learned, this was like cracking a nut with
a sledgehammer, and would soon devour the majority of our resources- time
that could have been better spent on application development.The data
management and GIS interdependency issues alone were daunting, and we were
just dealing with the United States initially.Our problems compounded
when we looked to extend our application to Canada, and Europe was out
of the question.
For an organization like NearMe who was building LBS infrastructure and had a staff with the GIS experience we did, this seemed like an OK approach, yet we were still overwhelmed.Looking back, I now realize that the average corporation that doesn't have 30 man years of deep GIS experience at the nuts and bolts level has about zero chance of deploying a LBS application AND being profitable while doing so.GIS tools were built to solve different problems.How could anyone in the real world possibly get all of the components to work together, and do it efficiently enough that they would see some return on the investment of deploying LBS?
Wireless operators, or any organization wanting to integrate the element of location, don't want to become GIS experts.They don't want to bear the costs of GIS software and data licensing not to mention the dedicated GIS servers and staff needed to maintain the GIS infrastructure.They simply want to provide their users with compelling applications that just so happen to need these technologies.
When we finally had things working the way we wanted in the US, an interested customer asked us about the costs of porting the NearMe applications to Europe.A quick back of the envelope calculation put the costs over a quarter million dollars just for cartographic data, and that number grew almost linearly as we needed to add additional servers for scalability.A show stopper to say the least.For a more complete overview of the intricacies of multi country LBS, you may want to see my previous Directions Magazine article on Web Services for LBS.
MapPoint is device independent.Developers can use it to build mobile applications for any architecture WAP, J2ME, BREW, Compact Framework and more. MapPoint features a single, simple to use API that exposes all functionality for all geographies! Truly write once, run anywhere. And most importantly, an organization can get started with MapPoint without incurring nasty licensing fees.There is no need to spend hundreds of thousands of dollars to acquire high quality street data, a renderer to visualize it, a street level geocoder, a driving directions engine, and comprehensive Point of Interest data such as business listings, or hardware costs for GIS servers.Mapping for the masses is upon us.
Barrier #5 - No standard OS and Libraries
Having a standard platform for programmers to develop against can do
wonders to help create a deep catalog of applications. Windows took
off the way it did when it became really easy to build applications once
that ran on any compliant PC configuration.The Windows operating system
provided developers a standard set of libraries that they could depend
on, regardless of the hardware implementation.Entire classes of problems
that developers faced were wiped out, from how to deal with a variety of
input devices, to how to output video in a monitor independent fashion.
To date, there have been a few attempts at creating such a model for mobile devices.BREW (Binary Runtime Environment for Wireless) from Qualcomm, available for a number of years, is one such attempt, but is hampered as it requires developers to code in C/C++ in order to build native BREW apps. On the positive side, it does have a library geared towards LBS - Here is an article in DevX that illustrates how to use the BREW Location API along with Microsoft's MapPoint Web Service to build location into BREW applications.
J2ME (Java 2 Micro Edition) has also tried to reach wide acceptance, but hasn't been able to launch a developer revolution for a variety of reasons ranging from complexity, to lack of support for basic data types such as Doubles (How does one deal with Currency? Or Latitude/Longitude for that matter!!), and lack of support for industry standards such as XML Web services.That's not to say that there aren't J2ME applications available today.There certainly are, but they are generally developed by a small minority of developers dedicated to building mobile applications. The average corporate developer who makes up the majority or programmers hasn't yet been able to develop mobile apps with J2ME.
Microsoft is hoping that the .NET Compact Framework can change all of that.It gives developers familiar, standard libraries to target on multiple devices, allowing them to easily port code from their desktop applications to the mobile world.I've ported complete Windows XP applications to Pocket PC Phone edition in hours leveraging the Compact Framework.CF is basically the kid brother of the .NET Framework for Windows desktop and server systems. It provides almost all of the same functionality, saving space with tricks like not providing all of the overloaded versions of a method, instead providing the most common and the most exhaustive versions.And perhaps most significant in the mobile connected world of computing, CF allows me to make calls to XML Web Services such as the MapPoint Web Service to integrate Location without having to know a thing about GIS or license expensive basemap data.
Barrier 6 - Difficult to Acquire Location
A key component of Mobile LBS applications is knowing the location
of the handset.The air in upstate NY must have been quite thin, as we
really believed that a major wireless operator would give us unbridled
access to users X/Y coordinate information in real-time.In reality, it
isn't likely for a variety of reasons ranging from privacy issues to complexity
to the logistics of the business model.
There are tons of applications that are made possible with real-time location of mobile devices, but there's currently no way for the average organization to tap into this information.Take for instance a mid sized business machine repair company.They have 20 vans in the field each day doing installation and maintenance of copiers and printers.If the dispatcher could see the location of these trucks in real time and wed this information to their dispatch system, they could easily optimize the routes of each driver.Today this would require the installation of very expensive dedicated hardware in each truck to acquire coordinates via GPS and transmit the information over a cellular link to a central database.Major trucking fleets do this routinely as it is core to their business.But what about the 20 van fleet I mentioned above? Complexity and price keep this technology out of reach.But wait - Those 20 field staff already have mobile phones!
Soon Microsoft will release the Microsoft Location Server (MLS) with the intent to address this major barrier for the corporate developer.MLS features a 'plug in' architecture that will allow a wireless operator to work with Microsoft to give organizations access to real time coordinates for devices on their network.With Location Server installed, a simple, standard API call is all the developer will need to do to find the real-time location of a mobile device for a member of his organization.As MLS is hosted within the enterprises infrastructure, they retain complete control over privacy as it relates to location - at no time does MLS communicate real-time coordinate information to Microsoft or any other entity for that matter.MLS is also independent of any position determining equipment employed by the mobile network.And finally, MLS works in perfect harmony with the MapPoint Web Service to give the organization access to the same rich mapping, driving directions, geocoding, and other location services MapPoint offers, without steep up front costs and learning curves.
Compelling applications are requisite to any computing environment achieving
broad adoption.We've seen this time and time again.And applications don't
get built without good tools to do so.The pieces have all come together
leading me to conclude that the wireless ecosystem is about to be flooded
with killer LBS applications.