I’ve been doing some thinking and prototyping for an LBS (Location Based Services) application with Flash recently and each of the items mentioned in the title of this entry, plays a part in what I’m working on. The end goal is to be able to deliver an application for mobile devices that provides discreet contextually aware LBS to an end user upon realtime requests. I want the app to be extremely intuitive, aesthetically pleasing and consistent from one mobile device to the next. I want to say that Flash Lite is perfect for this, however I have a few challenges in using Flash Lite at this point. Here are my challenges thus far:
Challenge 1: I want to incorporate a system similar to, if not actually Semacodes  or ShotCodes  formerly known as Bango Spots  in order to gather input from a users surroundings. Both Semacodes and ShotCodes both rely on using a camera to take snapshots of visual symbols and then retrieve information encoded in the symbols – ShotCodes go even further and allow the device to interact with the symbol rather than just decode information from it which adds another level of usage I am interested in pursuing – I have seen demos of a Nokia 3650 phone using ShotCodes and interacting with a local server via Bluetooth to report its rotation and orientation in relation to the ShotCode it has targeted. GPS systems can be great for a 30,000 foot view LBS system. The API for LBS and GPS is built right into most modern mobile devices, but once I know the users physical location, I want to allow the user to drill down further, and acquire and report more granular information about their immediate surroundings and even interact with their surrounding via their mobile device. I’ll give this a really bad acronym: GEBS (Granular Enviroment Based Services). So I’ll need to develop a way for GPS, GEBS, and Flash Lite to interact and communicate with each other. I would like it to be based on standards, but it will probably involve a custom app on the targeted device and a custom integration of either SemaCode or ShotCodes – not impossible at all, but will require some coding for sure and a license for either. There are some open source solutions for general barcode decoding for mobile devices but they are slow and don’t encode the right kind of info and just arent as elegant and refined as the other two solutions.
Challenge 2: I would like to deploy this Flash Lite 1.1 based interface to the app, on more platforms and phones then what are currently supported by Flash Lite. Specifically I want to deploy a Flash Lite app that can run inside or on top of BREW to extend its reach and deployment. There are at least two places I have seen that have referenced an extension for BREW that would allow Flash to run on top of it via an extension to BREW. So far I havent seen anything about it other than a mention here in this white paper from Qualcomm about BREW  on the first page it specifically states: “Other languages such as Flash and XML can also be supported via extensions to BREW” that sounds great, but where is this available from? Anup Murarka from Macromedia makes mention of a reference platform for Flash Lite on top of BREW earlier in the year at CES you can find it here  – the interesting quote is, “…this week, at CES, he’ll [Anup Murarka] be able to demonstrate a ‘reference design’ for Flash Lite on a Qualcomm BREW software platform. ‘It hasn’t been announced, but we’d love to see Flash on a BREW phone, and we have been able to demonstrate it…’ ” to me thats great news – as this would solve one of my challenges in getting the app into the hands of users with devices provided by carriers who lock down their devices to only accept signed/certified BREW apps. It is practically childs play to build a Flash Lite app, create an .sis file and distribute your app to Symbian OS based devices – no wonder Macromedia chose this as the low hanging fruit to go pursue first following their success with DoCoMo phones. I’m hoping BREW is next is next so I can leverage all my Flash knowledge instead of mucking around in JAVA or C/C++. Not that either of those are bad – just not my area of expertise.
Challenge 3: I want to deliver video as one of the content types that can be returned as a result of interacting with this system. The great majority of phones shipping now support some form of MPEG-4/3GPP video files. Right now Flash Lite doesn’t support video but I am hoping that given the adoption of video standards for phones and mobile devices this might be an area Macromedia fleshes out support for as well. It’s logical this might be explored, if you consider that Macromedia added support for TinySVG into Flash Lite 1.1 just for the mobile space. Similarly I can see support for MPEG4/3GPP video being added to the Flash Lite platform for the same reason: to support established standards. I can download a copy of Apples Quicktime Streaming Server for all the major server platforms and stream out MPEG4 and 3GPP video right now thanks to their Darwin based version of the QTSS.
So I’m going to give all this some more thought and continue to map out potential solutions and challenges. I think LBS and my self coined term, GEBS, for mobile devices are where the future lies for delivering realtime information to the general public.
I’d love to hear thoughts from folks who are exploring and experimenting with similar ideas and technologies.