Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member182638
Active Contributor
0 Kudos

A little over six months ago I released a iPhone App for searching HELP.SAP.COM describing my efforts and learnings to build an iOS app 'myHelp for SAP Professionals' that delivers search results from help.sap.com.  That app is entirely free (and devoid of any advertising or other revenue), has achieved over 8000 downloads, and continues to see a consistent download rate of ~200 per week (perhaps that is the rate at which SAP professionals are adopting iOS devices?).

I decided this year to explore how this could be ported to an Android platform.  Partly this was driven out of a desire to understand the Android platform from a native developers perspective, and partly out of a duty as a SAP Mentor to help the SAP community consume more knowledge (in this case the Android users in the community).

In embarking on this personal challenge, I did face one big problem .... I don't actually have an Android device.  This is not out of any strong preference for iOS, it is more related to the fact that when I acquired my iPhone there were very few Android options available locally.  I will describe later in this blog how I addressed this challenge.

Let's have a look at the app in the below YouTube video ...

If you cannot see the YouTube video, a Flash version is hosted here ... http://www.johnmoy.com/scn/resources/myHelp_Android_flashvideo.swf

If you are wondering how this app works, well it really is quite simple. This app reframes content delivered by help.sap.com not unlike what apps like Flipboard and others do (although not nearly as elegantly as Flipboard).  In order to incorporate SAP content I needed to source permission via SAP.  Thankfully SAP Mentor Dagfinn Parnas managed to help broker communications with SAP.  It was my first real experience of how helpful SAP Mentors can be.

You can find the app in the Android marketplace here.

Thoughts on Android

I need to be careful here, since the whole iOS versus Android debate can get overly passionate (and please don't ask me about Blackberry).  What I have here are my own personal thoughts and opinions from a developers perspective, and we all know that the mobile platforms landscape is changing at such a rapid pace that any opinion, whether right or wrong, will be out of date within weeks (as a great example, iOS 5 has been announced in the course of me writing this blog).

What I like about Android:

  • Openness.  Goes without saying.  But here is a practical example.  When deploying the Android app for testing, I can build a project, send the file to a colleague via email and they can install on their device with no problems.  With iOS, there is a complex process of obtaining the target device's unique ID (and trust me people find this very difficult to locate), registering the target device with Apple, building it with a signed certificate (whereby it will only function on devices for which it is signed to work and for a limited time period), then getting the tester to unzip it onto their computer, drag it into iTunes and then sync their device with iTunes.
  • Java.  Did I say Java?  Yes, I love that language.  But that is just my personal preference.  I also think that the SAP community, having a stronger foothold in Java than Objective-C, might find it easier to look into Android development.  SAP folk might find Objective-C a little more challenging, especially having to do things like explicity allocate and then release memory over and over and over again.  Before I alienate my ABAP friends, I should mention as a (former) development lead for an SAP internal team, I instruct my developers to focus on ABAP, not Java. But let's not open up THAT debate. :smile:
  • Intents.  I think this is one of the strongest aspects of Android architecture.  It is the core message system for Android.  You can code your app to broadcast an intent.  It can broadcast for a specific receiver, but it can also broadcast generically.  So as an example, when the app determines the URL for a help page, the below lines of code are used to broadcast to ANY receiver that can receive a text line.  These lines are invoked when you press the 'Share' menu item.  The great thing is that what then pops up on your device is a chooser with the different apps that you use that can consume the text line (eg. gmail, messaging, twitter, facebook).  And this chooser list is naturally tailored to what you have on your device ... so for instance, if you don't have a facebook app on your device, that won't show up as an option.  I think this is pretty neat, and the coding for it is very compact when compared to iOS (whereby I need to code separately for each specific recipient such as Safari, and Email).

// Share URL with other apps on the device

   Intent sharingIntent = new Intent(Intent.ACTION_SEND);

   sharingIntent.setType("text/plain");

   sharingIntent.putExtra(android.content.Intent.EXTRA_SUBJECT, getString(R.string.resultsdetail_sharetitle));

   sharingIntent.putExtra(android.content.Intent.EXTRA_TEXT, mWebView.getUrl());

   startActivity(Intent.createChooser(sharingIntent,getString(R.string.resultsdetail_shareusing)));


What aspects of Android I found challenging:

  • Form factors.  This is not so much a fault of Android, as a function of the success and proliferation of Android across different device manufacturers.  Anyway, there are far more form factors that your app needs to cater for, than when designing for iOS.  In fact, with this in mind, I consciously kept the design of the myHelp app (Android edition) very lean and simple, avoiding fixed positioning of UI elements.  I also tried to maximise the screen real estate for the actual data itself, given some Android devices have quite small screens.
  • Handling of rotation.  For some reason, the default behaviour in Android views is to restart the view logic upon rotation of the device.  So if your view is performing a HTTP request and has returned results, rotating the view initiates the HTTP request all over again.  There are ways to set this right, but I was perplexed at this default behaviour for which you need to do extra work to set right.  It might seem trivial, but it set me back several days with my development.  To have my app crash by default when the device was rotated was a bit deflating.  That said, I would probably be much more adept at avoiding this issue in future.  iOS seems to handle rotations much more readily in my opinion. 

What aspects of Android and iOS I am neutral on:

  • Minimal governance of the marketplace.  I actually treat this as a positive and a negative.  As a developer, I think it's great that I can publish an app to the marketplace and it is instantly available, no sweating on when some governing body approves it or not.  And this is particularly useful when you need to get a critical bug fix out fast.  As a consumer of apps, I'm not so sure (with the exception of the bug fix scenario) ... for instance, with one book that I used to teach myself Android development, there was a tutorial on publishing a simple app that was constructed in an earlier chapter.  I looked in the Android marketplace, and a number of people had followed the book and published this same identical app! (I didn't) ... as a consumer, I'm not sure I would want to see this blatant duplication.
  • Eclipse-based IDE.  Those of us with some history in SAP Java-based development will be more familiar with Eclipse.  If you had asked me 4 months ago which I preferred, I would have said the iOS XCode IDE (partly because of the UI Interface Builder design tools).  But with a more recent update to the Android IDE plug-ins, I'm happy with the Android Eclipse-based IDE (previously, I thought the UI designer for Android was not great).  Interestingly, in the past few months the iOS IDE has changed dramatically as well (for the better).  Such is the pace of innovation in mobile platforms and IDEs is that they release a new version every few months, rather than every few years.  Anyway, both IDEs are good in my opinion.  One limitation of the iOS XCode IDE and SDK is that you can only run it on a Mac.  So for me, to run both IDEs on a single machine necessitates a Mac.

With all of the above, I nonetheless found MANY similarities between iOS and Android development.  In fact I am convinced that I fell into Android development quite smoothly because of my time with iOS development.  With the port of myHelp from iOS to Android, in some cases I simply translated portions of code almost line for line.  In other areas the coding was very different.

So, after this experience, I can say that I have a great appreciation for Android and the Android development SDK.  So much so that I might consider acquiring an Android tablet to go with my iPad one day (especially so I can see Flash presentations on InfoQ).

But really, perhaps the big challenge isn't about Android versus iOS versus Windows Phone 7 etc.  The more interesting debate is the native versus mobile web debate, and in particular the web container approach.  But that probably deserves a separate blog.  For now, I have noticed that SAP / Sybase have moved to incorporate a web container into SUP 2.0

Addressing the Testing Challenge

I mentioned before that I don't actually have an Android device of my own to test with.  And anyone who has worked on native mobile development knows that testing on the device itself (rather than simply using emulators) is essential.  In addition to that, the Android platform presents the challenge of many different combinations of devices, form factors and OS versions, much moreso than with iOS.

So my testing strategy involved the following:

-  Test on the emulator, using several emulator configurations (for different combinations of form factors and OS versions)

-  Testing on a colleagues' devices (thanks to Abhinav Tayal, who possesses both a HTC Desire and a Dell Streak!)

-  Testing in the cloud. 

The last step of testing in the cloud was quite a revelation.  I discovered a service at perfecto mobile which enables you to upload your app via the browser directly onto a physical device in the cloud, and then actually control that device and test your app on it.  Through the browser, you actually see a webcam of the device screen (wrapped by a nice image of the device you are using).  Some screen captures of my testing are below ...

I was impressed with the coverage of this service in relation to handsets, platforms and network providers.  See this link to get an idea.  To be fair, this is not a free service, although they do offer a 1 hour free trial.

Note that I don't have any affiliation with this company, I was simply impressed with their innovative offering.  It is great to see services like this and PhoneGap Build (which I referenced in an earlier blog Extend your SAP jQuery Mobile web app with HTML5 concepts and Native device features - Part 2) springing up in the cloud.  Perhaps SAP/Sybase might gain some inspiration from this.

Other Learnings

  • Developers are used to the usual Log categories of 'd' (for debug), 'i' (for info) and 'e' (for error).  But would you believe Android also has a log category of 'wtf' ? (yes, according to the official Android documentation that stands for What a Terrible Failure).

Useful Links

Here I would like to share some useful links that I harvested in the course of this development ...

Final Thoughts

In a very informative blog 'What I Learned about Mobility at SAPPHIRE Now 2011', SAP Mentor Kevin Benedict quoted John Chen, CEO of Sybase as saying the following ...

"We expect to build only 10% of mobility apps, the ecosystem the rest"

You can already see that there have been efforts to deliver useful and free apps by the SAP community ecosystem for the SAP community.  Some good examples include the following:

SAP Mentors Outreach (Android app by SAP Mentor Thorsten Franz)

SAP Note Viewer (Android app by SAP Mentor Dagfinn Parnas)

SAP Note Viewer (iPhone app by Paul Aschmann, iPad version also available)

My expectation and hope is that SAP will deliver an official app for help.sap.com one day, and I would gladly welcome that.  But in the meantime, I hope the community benefits somewhat from this app, and that others are inspired to also deliver apps to the SAP community. 

I would like to acknowledge Daniel Da Vinci, who gave me the original idea to implement this for the iPhone, SAP Mentor Dagfinn Parnas who helped me find the right contacts at SAP to achieve permission to incorporate SAP's copyrighted content in the app, Sascha Wenninger who provided the language translations in German (currently only in iOS version, but he has agreed to help me with translating the Android version), and SAP Mentor Thorsten Franz who kindly provided his source code for the SAP Mentors Outreach app for reference purposes. THIS is the SAP Community at work!

8 Comments
Labels in this area