This email address is being protected from spambots. You need JavaScript enabled to view it.  202 643 5580

Porting PhoneGap App to Windows Phone

by Ian Dixon
on 14 July, 2013

So I have decided to port one or two apps over to Windows Phone. My primary motivation was getting an award Nokia Windows Phone device for pushing out the first app more than actually publishing in Window Phone. For me, the market share is still too low to provide the ROI I'd need to commit the time. But, it is a platform I'd like to keep an eye on, and it's fun to learn.

I decided to port over my most simple cross-platform app (SmarTrip Balance. A simple jQueryMobile app) over to Windows Phone. It's currently published in both the App Store and Google Play using PhoneGap and seemed like low hanging fruit. I also aimed to use PhoneGap Build, a cloud based build tool that allows you to upload the web assets of a mobile application and download installable apps for each platform. Depending on how this whole thing goes, I may consider building a native Windows App in the future, but for the time being I'll probably limit my Windows Phone projects to mobile web apps.

Issue #1 - Testing

I develop on MacBooks. As I had assumed before checking, there is no way to run the Windows Phone emulator natively in OS X. Annoying. To test anything I'll need a Windows infrastructure. That's time and money. I needed to install VMWare on my MacBook, and build a Windows 8 virtual machine.

I won't bore you with the details. VM installed configured, and Visual Studio installed. Emulator is up and running, app deployed.

Issue #2 - App can't make successful calls to my API

The big reward (only reward in my opinion) in choosing a cross-platform framework over native is develop once, deploy everywhere. Generally speaking that stands true for 90% of any given application I've developed for iOS and Android. But the remaining 10% usually proves to be a tedious exercise in tracking down isolated bugs and integrating any 3rd party and platform specific plugins. Even when just targeting iOS and Android, I have wondered if native would have been worth the extra effort. But that's for a different article. Porting over to Windows Phone was no different. I quickly tracked this bug down to a CORS issue. Not a biggie, but yet another small example of the fragmented mobile web standards you see across the different platforms.

Issue #3 - Pinned application icon does not contain application name

If i pin my application to the Windows Phone home screen, the icon contains a weird 'Cordova...' title instead of my app name. That seems like a detail the PhoneGap build folks needs to resolve (At time of writing I'm using 2.9). The solution for now is having to unzip the XAP file, update a tag in the WMAppManifest.xml file, and then convert the zip back to XAP. A rather manual and annoying step I'll need to perform every time I create a new build.

      <PrimaryToken TaskName="_default" TokenID="Cordova_1._5._0_Starter1Token">
          <BackgroundImageURI IsRelative="true" IsResource="false">Background.png</BackgroundImageURI>
          <Title>SmarTrip Balance</Title>

Issue #4 - Windows Phone required back button behavior

So I submit the app for 'certification'. It took about 5 business days for a response. This is pretty much identical to the average response time I get when submitting apps to the iTunes App Store, and I find the wait agonizing. Being so similar to the App Store model, I can't really dock it too many points, but it's a slight impediment for a developer when compared to publishing in Google Play which has next to no wait for new or updated apps.

When I hear back from Microsoft, my app is denied. Windows Phone apps must exit if you hit the Back button immediately after app launch. SmarTrip Balance didn't do this. It defaulted to the in-app web view back button behavior and either did nothing, or attempted to go back to the launch page prior to my apps login redirection. I ended up spending a lot of time experimenting with the jQuery to get this working properly. This requirement is unique to Windows Phone, and it is something every mobile web app I plan to port over will need to account for. Annoying. So much for develop once.

I solved the issue with a broadstroke removal of the web view's history back function.

var _back = window.history.back;
window.history.back = function () {
     // to prevent the default behavior(exit) return a truthy value, ie. true, 1, "You can never go back!", ...

I resubmitted today and now I wait again. I'm hopeful the Back button issue will get me in the door, but I'll need to go back and implement a more robust solution that doesn't simply remove the back stack in my application. As it stands, hitting the Back button will cause an application exit at any time, not just on initial launch. This behavior isn't ideal, and obviously won't work for an app that contains more than one application page.

I'll post my results once I hear back from Microsoft.

---------- Update 7/16/2013--------------

Denied again. Disabling the back button within my app completely doesn't enable users to dismiss my context menu with the back button as apparently it needs to. I've updated the event listener to it's default value when my context is visible, and overridden it when the context menu is gone. Hopefully that will suffice for Microsoft. Submitting again.

$(document).on( "panelopen", function( event, ui ) {
	window.history.back = _back;
} );
$(document).on( "panelclose", function( event, ui ) {
	window.history.back = function () {
	// to prevent the default behavior(exit) return a truthy value, ie. true, 1, "You can never go back!", ...
} );


Leave your comments

terms and condition.


  • No comments found