Discovery Cloud Based Time Sheet - How It All Came Together

[Former Member]

Hello again, here is the final blog in the series chris.paine and I have been doing in the process of building our mobile time sheet app that integrates with Netweaver Cloud. We've finally come to the end of that interesting journey, so I thought it would be nice to give an end to end perspective of how it all came together.

You can read our previous posts here:

Building a cross platform hybrid mobile app with PhoneGap Part 1

Building a cross platform hybrid mobile app with PhoneGap Part 2: Local Storage

Building a cross platform hybrid mobile app with PhoneGap Part 3: Deployment

Using SAP NetWeaver Cloud to link from a QR code to Apple App Store or Google Play

Using OAuth as an alternate user authentication strategy for SAP NetWeaver Cloud

RESTful APIs in SAP NetWeaver Cloud with a mobile device

Linking to and managing a mobile app using a simple solution in SAP NetWeaver Cloud

Sending formatted email with inline images from #sapnwcloud

Sending formatted email with inline images from #sapnwcloud (part two, the fixes)

CORS and #sapnwcloud on a whiteboard

CORS or "how to make that damn iPhone simulator work"

Should I really be sharing all this?

Wow looking at that list; we've been busy little bees (Chris more so than me!).

What did we do again?

To refresh our memory, and to celebrate a successful journey, we have put together the mother of all videos to bring it all together (Chris and I are particularly proud of this video).

That was a lot of (bad) drawing and information, but a pretty accurate overview of how much we had to incorporate into this solution. So now that we remember what we set out to do, here's how we did it, and the order in which it happened:

Broad strokes of what we did

Without going into too much detail (you can visit our previous blogs for that), here's how we achieved our overall outcome:

• Built the mobile app with PhoneGap and jQuery Mobile in HTML5 for both iOS and Android (using XCode and Eclipse respectively)
• Used social networking applications for authentication with OAuth (Facebook, Twitter and Google)
• Based on that authentication, generated pairing code and subsequently 'secret' (password) to attach device to that login and use to authenticate all ajax calls to cloud
• All sorts of awesome logic to get and set entries, settings and projects in the cloud
  
• Incorporated CORS into all ajax interaction between device and cloud
• Used JSON and REST (not OData) to push and pull data from the cloud
• Used fancy logic in cloud server to send emails to users when time entries are submitted
• Generated QR code to link to Apple app store and Google Play stores for app download

Phew that's a lot of stuff, and most of it is covered in our previous posts, but that wasn't the end.

What's happened since last time?

As mentioned in my first post in this series, I got the fun job of creating the app for both iOS and Android. As mentioned before, we created the app using PhoneGap, and paired it with jQuery Mobile to make it look all pretty and Apple-ly. I must say that the more complex the app got, the less I liked using jQuery Mobile. I went into this process thinking that PhoneGap would be a great idea, but after jiggling the same code to work for both platforms, I think I'm going to try native next time.

All in all, working with PhoneGap was very easy because I was already familiar with JavaScript and jQuery Mobile, and I still really like how it made the app look. Below are the screenshots of the final product:

I'm pretty happy with how the UI looks. I wanted it to be clean and simple, and I'm pleased that it managed to stay that way. Now that the app is ready in both platforms, what's next?

The submission process

After getting all the code up to to date and fully testing everything, came the fun part of submitting the apps to the relevant stores. We always knew that submitting to Google Play would be easy, but I was actually surprised at how quick it was. Before I go into that, let's look at submitting the iOS version first. There are quite a few things you have to do, and they're not all located in the same spot either.

iOS Submission Steps (in the order I did them)

• First thing you have to do is create an application in iTunes Connect, with all the relevant details such as release date, pricing, description, screenshots, etc. Note that the app ID you choose has to link with one in the Apple Developer center so you can provision the certificate correctly
• Once you've completed all the information you have to make sure the status is ready for binary upload before you can continue
• Now you have to archive your final application to get the binary ready. This usually involves setting the schema to point at iOS Device (don't have any device plugged in) first, then choose Product >> Archive
• But at this point I realised I didn't have the final schema set up for the App Store, so I went and created it

• I also had to update the build settings with the AppStore schema build settings before archiving the product

• Then you open up the Organizer and look for Archives. Select the latest one (the one you just created) and choose Validate

• But before you can validate you need to sign it with a certificate, which I'd previously done for testing and development, but not for actual release yet
• So back to the Apple Developer center I go and create a distribution certificate in the Provisioning Portal
• Then I download the certificate and drag it into XCode to be installed
• Now I go back to validating the archive and choose the correct code signing identity (for the correct app if you have several)
• Once that's validated, you can now submit to the app store, and again use the correct code signing identity

Once that's all done, we have to wait for Apple to review and approve the app. In our case we waited 9 days for this to happen. Now let's take a look at Android:

Android Steps

• Register as a developer in Google Play and pay $25
• Go to the Developer Console and put in information about the app (similar to the iOS process)
• In Eclipse, use Android Tools to export the APK and generate a key to sign it with (there's a handy little wizard to follow)

• Validate all information, upload APK and submit for publishing
• Wait....publishing? No approval lead time? No. Awesome
• App is published a few hours later (chris.paine continues to crow over this)

I quite agree with Chris that submission was far easier for Android. It took me quite a few hours to figure out how to submit the iOS version (due to me being a newbie at it too), but I submitted the Android version in half an hour. Google Play does actually scan your app - http://googlemobile.blogspot.com.au/2012/02/android-and-security.html, just that they do it automatically, rather than manually.

So now both version are available in the respective stores for download on App Store and Google Play Store. The next section details the steps to use the app itself.

Overview of how the app works in entirety

• User downloads the app from App Store or Google Play
• User visits http://bit.ly?TSHEET and logs in with Facebook, Google or Twitter account
• User creates a mobile device on the Mobile page, which generates a pairing code
• User enters in pairing code into the app, and authenticates with the server
• Default settings are pulled down to the device, and user can now modify email, add projects, etc.
• User can now enter in time by day or week. Entries are marked in yellow
• To submit entries to the server, user taps on 'Submit all entries' button. This picks up all the entries that are 'dirty' (modified) and sends them to the server via ajax POST/PUT/DELETE. Once the response comes back from the server, submitted entries are coloured green
• To pull down existing data from the server, user can tap on 'Sync all data' button
  

We put together a video (of course :smile: ) of how to use the app, to help give users an idea of what to do, so now you can have a look too!

That's all from us for now, hope you enjoyed the series and stay tuned for our next endeavour!

Disclaimer: All opinions are wholly our own, and do not necessarily reflect on our awesome employer who have supported us throughout this exciting project.