Skip to Content

Building a cross platform hybrid mobile app with PhoneGap Part 1

Hello, I am finally joining the party that is the seriesChris Paine and I are writing about developing a mobile app that works with Netweaver Cloud as well as interfaces with an on premise backend (previous posts are here and here. My part in this fun is building the mobile app, and since I’m pro Apple and Chris is pro Android, we decided we had to make it available on both platforms.

Background: Why PhoneGap?

So of course the first conversation we had to have when discussing a mobile app was: native or web app? Having done a pure web app before, I was aware of the benefits, as well as the pitfalls (you can read more about it in my blog post). But before that, we very quickly ruled out the native solution. Why? Because given our expertise in XCode and pure Android development (which I can say for myself was virtually none), it would take far too long. So then we were tossing up between web app or hybrid, and finally settled on hybrid.

Of course if you do your research you will find that many developers out there have gone through the same decision making process, so I won’t go into too much detail of the pros and cons of each option. Basically we decided that though a web app would be easier to deploy updates with and be more accessible, we wanted our app to have those pros as well as have some of the pros of a native app too. Which is why we decided to go with a hybrid app. There are a few tools out there now, but we chose to go with PhoneGap as it works with jQuery Mobile and I like how it looks. Also, for the life of me I could not get Sencha Touch to install on my MacBook, maybe because it wouldn’t work on Mountain Lion. Sencha Architect worked but I needed to pay for it, plus I couldn’t work with jQuery Mobile.

PhoneGap: The Fun Parts

Before I let you in on the fun I had, let me just quickly cover the building blocks required to create a PhoneGap app:

  1. Download and extract PhoneGap
  2. Download and extract Cordova
  3. Create a project in the command line for the platform you want
  4. Open the project file in the relevant environment
  5. Install relevant plugins in each environment (Android SDK and tools for Eclipse and simulators in XCode)
  6. Build your HTML file with the required .js and .css files
  7. Test in simulator

The first thing I discovered was that PhoneGap had significantly changed since it’s last release (I used version 2.2.0). In the older version there was a UI friendly way of installing it and creating a project (in either XCode or Eclipse). PhoneGap has documentation to help you through installation though, so it wasn’t too bad in the end. The bottom line is you need both XCode and Eclipse Classic if you want to work on iOS and Android platforms. And both tools require project creation through the command line. Luckily for me PhoneGap had this in their documentation so I didn’t have to learn any commands!

Basically the way PhoneGap works is it creates a project in the relevant environment that references a Cordova library. This library is platform specific and gives you access to the platform API, and on device features such as the accelorometer, camera, etc. Even though in this development we are not using any of these capabilities, the plan was to be able to do so in the future. The project comes created with a HTML file that will be the basis of your web app that is encapsulated within the device browser (incidentally this is why it’s faster than a pure web app). Here’s a screenshot of the two environments I had to work in (Eclipse is FAR EASIER, but I refuse to say I’m pro Android yet, sorry Chris).

Screen Shot 2013-01-22 at 4.50.53 PM.png

Screen Shot 2013-01-22 at 4.50.34 PM.png

Now by far the most annoying thing about using PhoneGap is that I had to develop virtually the same thing in two environments. Thank God for the FileMerge tool to compare the two HTML files or I would have gone blind by now. Exacerbating this annoyance is the fact that jQuery Mobile has little quirks that happen in iOS and not in Android, so the two files couldn’t be exactly the same (I used jQuery Mobile version 1.2.0 and jQuery 1.8.0). The two projects also had their own www folders so I had to have duplicates of my .js and .css files (you quickly learn the hard way when something is missing).

HTML5 is awesome

Obviously in the app we chose to use HTML5, largely due to local storage. We wanted our app to appear to behave the same way to the user whether or not it was connected to the server. This meant saving everything onto the device, and refreshing it with server values when it was connected. If you’re familiar with HTML already, you won’t have any problem at all, as it was a BREEZE compared to some of the other things.

Sorry Android Lovers

The reason I chose to use jQuery Mobile is because I like how it looks. Very Apple like. Unfortunately this meant that Android users would also have that look and feel, and not everyone was that excited about it (that’s you Chris). However, to give me some credit, I tried to make the button placements and icons as similar to Android as possible. The bottom line is I still love how Apple apps look 🙂

Integration is a dirty word

Most people cringe at this word, but after creating the applications in the relevant environments, it was time to integrate with our server in the cloud (more details in the blog links at the top). The first thing we had to do was register/pair a device with a user. Once a user is logged into our website, they can pair any number of devices, which have their own ID. The idea is to pair the device once, which provides the id and password required to securely connect to the server. Needless to say the id and password is different for every device, but the beauty of this is that all devices for the same user can download the same data.

Having done that, all secure communication with the server is done via ajax calls to RESTful services.Chris came up with the API for all our resource GETs, PUTs, POSTs and DELETEs.  All data being received and sent is in JSON format. We had a bit of “fun” using ajax on cross-domain servers (Chris and I will be covering more on that in another blog post). For iOS I had to specify cross-domain = true for every ajax call or it wouldn’t work, but it was fine without in Android.

Testing on devices

In this regard, iOS didn’t want to play fair. Sure I could test in the simulator just fine, but I wanted to see it workon my own device. With Apple you need to register in the developer program (which costs $99) before you can deploy any application on your device. Android was a dream; you just plug in your device, turn on debugging and deploy it. Also, iOS apps require 1-2 weeks lead time of approval before they publish your app in the App Store, whereas the Google Play Store is much faster. Having said that, testing on the Android simulator was a little bit buggy too, such as the simulator device not connecting to the internet after awhile. I’m pleased to say that the overall look and feel is quite uniform between the platforms. You can see the screenshots below (iOS on left and Android on right)

iOS Simulator Screen shot 22.01.2013 4.44.05 PM.pngScreen Shot 2013-01-23 at 10.57.25 AM.pngiOS Simulator Screen shot 22.01.2013 4.49.23 PM.pngScreen Shot 2013-01-23 at 10.57.56 AM.pngiOS Simulator Screen shot 22.01.2013 4.50.08 PM.pngScreen Shot 2013-01-23 at 10.58.39 AM.png

Key Learnings

So here’s what I learned during this process:

  • Decide on the main purpose of your app, and choose the app type accordingly. If you need to be offline all the time, maybe a native app works better
  • Mock up the application in a platform agnostic tool like Balsamic so your design won’t be too biased towards any platform
  • Choose your target OS level wisely. I picked one that was too high in Android and realised my own device wasn’t even there yet. However too low and it won’t be compatible with Cordova
  • Ensure your HTML and CSS work in both platforms, as sizing of Androids in particular can be very different
  • Ensure you have a good web developer tool plugin for your browser. Unless you want to alert everything inside your app, this will prove invaluable for debugging
  • Always test in different device rotations (if you don’t want them to, lock it). You avoid lots of nasty surprises this way
  • To test RESTful calls independently, I recommend the Postman app in Chrome. Helps to determine if your problems are device related
  • Finally, Google is your friend. Embrace it warmly

Next Up…

I will be writing another blog with more in depth information about local storage on device and how we sync the data between the device(s) and the server. Stay tuned!!

You must be Logged on to comment or reply to a post.
  • Awesome! I really like how you show the differences/similarities between the iOS and Android displays. Much as I would love that the Android version looked more Android like (we know which team I barrack for 😉 ) choosing jQueryMobile meant that some of that formatting would be quite hard.

    Just wait until you’ve done a little more development, especially when we start accessing some of the device special features like scanning QR codes – I’ll make you an Android convert yet 😉

    Looking forward to the next blog 🙂



  • Hi Joanna, Found your blog interesting, I am a novice to mobile technology and making an effort to learn it. Have some basic questions,

    1. If I am using Phonegap do I need to know Java or is it enough if I know javascript, AJAX to call exposed services in SAP

    2. And How to do I connect my mobile device to SAP which is in corporate network, could you shed some light on what needs to be done to get the mobile access the SAP system.

    I could not get any information on this in all the blogs I have gone through.

    Will keep track of your blogs 🙂

    • Hi Raghavendra,

      Please see my answers below:

      1. You don’t need to know Java if you are just doing the mobile side of things. PhoneGap works with JavaScript and you can use ajax calls with jQuery Mobile.

      2. If you need your mobile device to connect with SAP within a corporate network, you will have to deal with network authentication as well as SAP authentication. There are several ways to authenticate with a corporate network; however if you want the user to only authenticate once, you can use a X.509 certificate which can be generated and installed on the device. You could use Gateway to provide services from SAP that can be consumed on the mobile app. You could also do it in a web app that accesses a BSP within the SAP system, and in that case you could the portal if you have one to generate a cookie which can perform SSO into SAP. It really depends on the nature of your app.

  • Hi Joanna,

    Great blog. I really like the way you and Chris are blogging about your experiences with SAP NetWeaver Cloud and Mobility and sharing it with the community. You two developed a great example application with a nice UI for showcasing all kind of possibilities. Really looking forward to your next blog.



  • Hi Joanna,

    Great blog! I have been doing some “PhoneGapping” myself and see that you had to duplicate the .js and .css files for android/iOS support. What we did in the project is create a link from the iOS www folder to the Android folder. This way we didn’t have to duplicate the folders.

    Kind regards,


  • Excellent Jo,

    So great to see you learning new things and sharing with the community. As you know, you’re one of the most talented developers I’ve worked with and that’s reflected in your blogs.

    Well done