Posts Tagged ‘mobile’

* Mobile Geolocation Implementations

Posted on August 19th, 2010 by Dave Johnson. Filed under Uncategorized, phonegap.

Today I found some time to take a look at the various mobile implementations of geolocation.

Below is a table showing the properties that the geolocation API uses on the various platforms. The W3C geolocation API for browsers specifies a PositionOptions interface that requires a maximum age, timeout and accuracy. Below that row is all of the mobile platforms that we are interested in for PhoneGap and the properties that they support in their native implementations. Some of them support a distance filter that will cause the device to only return geolocation positions if the location has changed by more than that distance while others also support an explicit interval for watching for location changes (note that on Android that interval is only a hint to let the device know how much power to use in getting a location - the position may be reported at an interval either shorter or longer than the specified interval).

I am probably going to be adding these two additional arguments to the PhoneGap PositionOptions and they can be used on platforms that support them.

Max age Timeout Accuracy Distance Interval
BlackBerry maxAge timeout - - interval
iPhone - - desiredAccuracy distanceFilter -
Android - - - minDistance minTime
webOS maximumAge responseTime accuracy - -
WRT updateMaxAge updateTimeout - - updateInterval
Winphone - - DesiredAccuracy MovementThreshold

Image from cloneofsnake

Tags: , , , .

* PhoneGap Native Bridge

Posted on August 13th, 2010 by Dave Johnson. Filed under JavaScript, mobile, phonegap.

The “native bridge” is the secret sauce of PhoneGap and is what allows JavaScript in an embedded browser talk to native code and vice-versa.

On every platform we do this differently depending on what features that native browser has. Here is the list of platforms and how we do it.

iPhone: To communicate from JavaScript to native we call window.location = “gap://Class.method/args” and then intercept the url in native code and parse our the parameters. The class / method is then dynamically loaded / called. To call JavaScript from native we use UIWebView.stringByEvaluatingJavaScriptFromString.

Android: Communication from JavaScript to native takes advantage of the native WebView.addJavascriptInterface to expose Java objects directly to JavaScript. To call JavaScript from native we currently use WebView.loadUrl(”javascript:…”) but that has some problems so we are soon moving over to polling a Java message queue calling a local HTTP server via a long-lived XHR connection.

BlackBerry 4.x: document.cookie is the only way to talk between JavaScript and native. JavaScript sets the cookie for native to read and JavaScript polls the cookie for messages from native. Fucking elegant!

BlackBerry Widgets: Astoundingly the new BlackBerry Widgets SDK is pretty damn nice. You can expose Java objects to JavaScript with ScriptEngine.addExtension and you can call JavaScript from native with ScriptEngine.executeScript. The context for the JavaScript execution can even be specified. Seriously great work there.

QT: This one is not quite ready but it will use the QWebFrame.addToJavaScriptWindowObject to expose native objects to JavaScript and will likely use polling of those exposed native objects to get data back into JavaScript - much like the Android approach

Windows Phone 7: There is something called window.external.Notify in the browser (mapped to a native object through the ScriptNotify event) on Windows Phone 7 that we use to send messages into native code. Going the other way there is WebBrowser.InvokeScript.

webOS, WRT: The platforms that are just JavaScript don’t have any native code. Well, we might look into the native side of webOS one day but no time soon.

In an attempt to clean up the PhoneGap JavaScript API a bit, I have isolated all the places that we communicate from JavaScript to native code and put it into a single PhoneGap class. I am now in the process of converting over all the JavaScript to use this new PhoneGap interface and then most of the PhoneGap JavaScript will be completely cross platform. Any call to native code now has to go through the PhoneGap.exec() JavaScript method. The new code is up on Github and with any luck all the platforms will be using it soon!

Image by hb2

Tags: , , .

* Smart Grid Utilities

Posted on June 22nd, 2010 by Dave Johnson. Filed under smart grid.

The “smart grid” is a pretty popular term these days is used to describe a new generation of electricity distribution network or grid where electricity usage at by the end user is tracked in real time. Today, tracking of electricity is done by prediction until the utility physically sends a person to the consumers location who then reads the value on an electricity meter. This new real time tracking of usage also means that the consumer can not only see their usage at any given time, but they can also see the price of electricity at that time allowing them to make decisions to try and save money - generally that means using electricity at night when rates are lowest.

If there is one thing that is clear, it is that the smart grid is going to be built on Internet standards like TCP/IP, the only question is what medium it will use. It might be WiFi, mesh networks, power line communication, cell networks, radio, or just plain old broadband.

The interesting part is that however the data gets from your house or business to the utility, it will have to be over a TCP/IP network that could conceivably have enough bandwidth to also provide you with services ranging from Internet to phone to television - as many telecommunication companies do today.

With enough bandwidth a smart grid utility could provide ALL of your utilities.

Companies like Google are certainly ready to be the provider of all the software a utility might need on top of an Internet connection to be your single utility provider. With Chrome OS or Android as the nervous system of a smart house to Android on your mobile phone, TV, Voice and PowerMeter. These pieces of software could even come from various providers like Skype or Microsoft but certainly using a battle hardened, open source, developer friendly operating system like Android at the core makes sense. Beyond that they should also be taking advantage of the increasingly powerful smartphones like the Android, iPhone and Blackberry and using them as the user interface to all of their smart systems.

In the past the stringent security and reliability requirements placed on utilities probably forced them to write their own software preferring security through obscurity rather than using open source software that probably didn’t even exist. Today is different though and there are many open source software projects that can likely stand up to their requirements.

If utilities were as smart as they hope their grid will be, they would be ensuring that their smart grid offering gives them the ability to offer other value added services to their customers just as other communications companies have either moved from providing broadband to providing voice services or vice versa.

Image credit Tom Raftery

Tags: , , , .

* PhoneGap Desktop

Posted on April 20th, 2010 by Dave Johnson. Filed under phonegap.

So if PhoneGap was running on the desktop, what would you call it? Well I have not come up with a good name yet but after a few nights of hacking we threw together a version of PhoneGap for Mac OS and a version for Windows

@shazron has implemented the sound API on the Mac version and I did Geolocation on the Windows version using a simple GeoIP lookup.

Check it out, write some code, and let us know what you think!

For the Windows version I have used the awesome WebKit .NET project written by Peter Nelson. If you use the Visual Studio 2008 solution file, you will have to download the source or binary versions of WebKit .NET and setup the references correctly. I have so far used the 0.3 release of WebKit .NET. It is pretty cool being able to write a native Windows app (or Mac OS) in Canvas using all free and open source code :)

One other caveat on the Windows side is that you might need to install some Visual Studio C++ redistributables for building it … check the WebKit .NET forum on SourceForge for all the details.

Tags: , , .

* Long Live PhoneGap for BlackBerry

Posted on July 30th, 2009 by Dave Johnson. Filed under phonegap.

There have been some new developments in the PhoneGap on BlackBerry breathing new life into the project! It all boils down to the fact that in RIM OS >= 4.6 there is a browser rendering option that you can set to make the browser render using the modern rendering engine rather than the archaic one from OS 4.2.

It look something like this:

  RenderingOptions.CORE_OPTIONS_GUID, 17000, true);

After much trial and error it was found that the BrowserContentManager did not support this rendering option (and RIM says it is completely unsupported / experimental anyhow) yet the Field returned from BrowserContent.getDisplayableContent() does support it!

Long story short it looks like PhoneGap on RIM OS >= 4.6 is going to work really well.

Next up is looking at the new features in OS 5.0.

Tags: , , , .

* PhoneGap iPhone Approval

Posted on June 13th, 2009 by Dave Johnson. Filed under mobile, phonegap.

The guys over at Rhomobile posted about IPhone App Store rejection issues the other day - I can only assume due to the recent problems that some users of PhoneGap have been having. Rhomobile and PhoneGap are similar in that they are frameworks that enable developers to build native mobile apps in a language they are familiar with, Ruby and JavaScript respectively.

I think that they are pretty much spot on in terms of their interpretation of the App Store rule 3.2.2 that states:

An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).

The two key points in this App Store rule are where it says an app “may not itself install or launch other executable code by any means” and this is exactly what users of PhoneGap are doing if their apps are downloading JavaScript over the network rather than including it in the application www folder. By downloading JavaScript over the network at runtime the application is downloading and running interpreted code that Apple has not control over during their app approval process.

So if any of you PhoneGap developers are worried about Apple rejecting your app just make sure that you don’t download any JavaScript at runtime and instead include it in the application. Having said that, also make sure that you apps don’t look like you just took a shit and emailed it to Apple :)

That is just my thoughts on the issue, whether or not that is the *real* reason that Apple is rejecting PhoneGap apps we may never know but that is certainly one reason that they would do it I think. It could just be because they feel like it…

Tags: , , , .

* Where 2.0 Slides

Posted on June 7th, 2009 by Dave Johnson. Filed under Conference, mobile.

Here are my slides from my workshop at the recent O’Reilly Where 2.0 conference down in San Jose.

Where 2.0
View more PDF documents from davejohnson.

Tags: , , , , .

* Where 2.0 Workshop

Posted on May 17th, 2009 by Dave Johnson. Filed under Conference, mobile.

I am going to be running a workshop down at the O’Reilly Where 2.0 conference on Tuesday called Giving Your Mobile Apps a Sense of Place.

I am going to cover Geo related features and issues of IPhone 2.2.1, Android 1.5 (aka Cupcake), RIM OS 4.7, and, most importantly, PhoneGap. I will be sure to post the slides once I am done them as well as put all the sample projects up on my GitHub.

If you are in San Jose Monday night then you will probably find me in the bar, whether I am done my slides or not!

Tags: , , , , , .

* BlackBerry PhoneGap RIP

Posted on January 25th, 2009 by Dave Johnson. Filed under mobile, phonegap.

I was probably the only one working on PhoneGap for BlackBerry and now there might not be anyone. I have officially given up my BlackBerry programming endeavours for the time being in favour of greener pastures in the form of a Google Android G1. The final straw was when I found that the BrowserContentManager, which is the class one can use in their own BlackBerry application to render HTML content, does not support the same APIs as the actual web browser on the phone! In version 4.6 of the BlackBerry OS they introduced a proper, and fairly decent, web browser (that is definitely *not* WebKit as so many people like to say) and yet the BrowserContentManager is stuck back in the OS 4.2 days. Not sure if the Storm (OS 4.7) has changed that or not, although the API of the normal browser in 4.7 is identical to 4.6 so I assume not and somone on the BlackBerry support forums corroborates my findings.

I am working on my first Android application today and will hopefully get some PhoneGap work in there too.

Tags: , , , , .

* BlackBerry PhoneGap Progress Report

Posted on December 6th, 2008 by Dave Johnson. Filed under phonegap.

BlackBerry PhoneGap
We had a PhoneGap sprint just over a week ago which was pretty successful for me and my BlackBerry ambitions as well as everyone else. Through that sprint and over the past week, despite some setbacks, I got the OS v4.5 installed on my phone and the simulator on my computer giving me access to a few new things but I was sad to find that a few other things were still sorely lacking that are pretty important for something like PhoneGap. Just so you know, OS v4.5 is the latest OS that will run on my Curve 8310 - 4.6 will run on the Bold, Pearl Flip and newer Curves while 4.7 works on the Storm. The two biggest gaffs by RIM are in the BlackBerry web browser for OS v4.5 where that the following rather important features are missing:

  1. You can’t pass function pointers to setTimeout.
  2. You can’t access DOM Nodes in any way shape or form (aside from form fields). So there is no getElementById or innerHTML on the resulting nodes. This make web application development a little bit difficult.
  3. There is no XMLHttpRequest object.
  4. While not really expected, there is no SQLite support
    anywhere on the phone as of yet, let alone the browser.

Anyhow, despite those setbacks on the v4.5 OS I did get the communication between the BlackBerry device and the web page all dialed now. Not only that but I have implemented the W3C geolocation API and am going to follow that same pattern for the other APIs. Check out the geolocation JavaScript interface as well as the platform specific implementation.

In the actual BlackBerry code there is lots of boiler plate stuff. The main hurdle was figuring what the best (or any) way to embed the browser in the application was and enable communication between JavaScript in the browser and the BlackBerry Java code. In the end I pretty much had to take the route of implementing the browser myself through the BrowserContentManager. This means that I have to implement lots of functionality, but it also means that I am in control of cookies and responsible for accepting them from JavaScript in the web page through the implementation of the browser fields RenderingApplication.eventOccurred method when the event type is EVENT_SET_HTTP_COOKIE and returning them to JavaScript by implementing the RenderingApplication.GetHTTPCookie method.

When the set cookie event occurs I parse out the cookies looking for one named bb_command and expect it to contain some JSON object (that is parsed with the J2ME port of a Java JSON lib) with a command property (like for opening maps or getting the GPS location) and some arguments (like points to plot on the map or how long to vibrate for). The case statement just looks like this:

switch (command)
  case 0:
    this._getLocation = true;
  case 1:
      new MapsArguments(MapsArguments.ARG_LOCATION_DOCUMENT,
  case 2:
      new CameraArguments()
  case 3:
    if (Alert.isVibrateSupported())
  case 4:
      new PhoneArguments(PhoneArguments.ARG_CALL,

where args is just a JSON string that the various methods like getPhoneNumber parse to get the args they want.

I will post some more specific code snippets like how to send text messages and so on very soon.

Tags: , , , , , , , , .