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.
  • 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 ...

 

image

 

 

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!

Now that the wraps are off iOS 5, we can start to review what some of the new features and apps will do for the rest of the telecommunications ecosystem.  Since we are a messaging-centric company, among other things, I thought I’d take a few minutes to look at the potential impact of iMessage and what it has the potential to do to SMS and MMS.

 

iMessage

First off, iMessage is a closed IM/messaging service between iOS devices – namely iPADs, iPod Touches,  and iPhones (running iOS 5).  So, in a way this is no different than WhatsApp, Beluga (group messaging) and other similar apps.  Note that it is NOT interoperable with Android, Blackberry, Windows and other smartphone Operating Systems and it does not interoperate with the 5 billion SMS capable devices out there today.

 

Still, in markets where iOS is dominant, you might find some cannibalization of SMS as well as MMS when multiple users with iOS devices begin to use iMessage vs. SMS to text to one another.  iMessage has implications in the Enterprise as well – as there are a variety of new iOS 5 APIs, I would presume, many are around iMessage.  It supports both delivery and read receipts, secure encryption and conversations can be pushed to multiple devices.   iMessage works on both 3G and WiFi networks.

 

Almost 10 years ago, a handful of companies, including InphoMatch (a predecessor to Sybase 365)  pioneered hub-based SMS interoperability.  Now, messaging hubs account for almost 5 billion messages per day – within the United States and globally.  MMS interoperability via messaging hubs, was first launched by InphoMatch (then, becoming Mobile 365) in late 2004.  Today, mobile messaging has become the most ubiquitous non-verbal communications medium in the history of mankind.  Nothing, not IM, not the various smartphone messaging apps have even come close to cannibalizing this service.  iMessage WILL have some impact, in specific markets, but remember; most of the world still uses and will continue to use SMS for a long time to come.

 

Since the iPhone 4 was launched, we do not have an interoperable FaceTime (iPhone’s proprietary video chat), even though it was supposedly built with standard interfaces.  But the video chat ecosystem is very weak, with many other incompatible services.  SMS and MMS have a huge global ecosystem in place – one that even Apple, with all of its rather closed garden approach would do well to interoperate with.  Still, given their history with FaceTime, I would not get my hopes up just yet.

 

Now, don’t count out Android yet, either.  Remember, Android is owned by Google and Google has Google Voice, which includes both Voice and an SMS that is interoperable with the P2P SMS ecosystem. This is why NUVOs are important and should be carefully courted by the existing telecommunications ecosystem.  They are interoperable with everyone else – they use Telephone Numbers as universal addresses and are not limited to a closed system of devices or operating systems.

 

If iMessage does cannibalize SMS for NUVOs and Mobile Network Operators (MNOs), then by how much? Let’s look at the numbers.  In the United States, ComScore just noted that the Apple Smartphone platform moved to 2nd place, ahead of Blackberry for 26% market share of the smartphone market.  ComScore, elsewhere noted that approximately 75 million Americans were using smartphones – so that is 19.5 million iPhones in the USA.  At this point, we are just talking about smartphones – no tablets, or iPod Touches yet.  Our numbers, along with those from Informa Telecom & Media note that Americans send, on average, around 950 to over 1000 messages per subscriber per month. Various statistics have shown that smartphone users are, by far, the heaviest users of SMS.  For our calculation, let’s call this 1050 messages per SMARTphone subscriber, per month.  So the potential impact is approximately 20.475 billion SMS messages per month (or more precisely SMS and MMS messages) that might disappear, replaced by iMessages.

 

CTIA, in their Semi-Annual Wireless Industry Survey, estimated that in 2010, 2.052 trillion SMS messages were sent in the United States.  That’s 171 billion messages per month.  Then our messaging impact could be as high as approximately 12% of the total SMS.   That doesn’t sound quite as bad, does it?

But that’s not the whole story. Apple iPhone users are not going to suddenly stop using SMS.  Because the 12% impact assumes that.  In reality, Apple iPhone users will still use SMS to reach the other 283 million U.S. non-Apple mobile phone users, as well as billions of other people around the world, not using iOS products.  So the real impact is probably at most, closer to 1-3%, if that much, given that these users will continue to send SMS.

 

I used the United States as an example, but the iPhone is now a worldwide device.  I would expect similar impacts in other iPhone/iOS heavy markets.

Today’s iOS and iCloud announcements will further impact the mobile ecosystem.  I’ll have more to say about several of these new features and what they mean to messaging, mobile enterprise and other areas in the coming weeks.

This week I attended the SYBASE (an SAP Company :-)) Summit in Sydney and wanted to share some of the highlights and my insights from the day. As always this represents my own views and opinions and not those of SAP, SYBASE or the company I work for :-).

The theme of the day can be summarized by Manage, Analyse and Mobilse, but with all the hype and focus on Mobility it is easy to forget that SYBASE’s bread a butter has long been data management with their ASE database and Analytics with their IQ product. I won’t focus on these things since they really fall outside of my areas of interest/expertise but the two things I would like to note are:

 

  1. ASE v15.7 (transactional storage) is in the process of being certified to run the SAP Business Suite; and expects to be generally available by the end of this year (2011). I guess this will mean that SAP can sell the database as well as the business suite to customers. How that will affect MaxDB was a little unclear.
  2. IQ (analytical storage) is being integrated with many of the SAP Business Objects tools and products.

 

The keynote was co-presented by Willie Jow (VP Mobility) and Peter Thawley (Sr. Directory CTO Group). Willie focussed on the mobility side and Peter gave a good overview of what is happening in the data management and data analytics side of things. Some key points I noted were:

 

image

  • SYBASE is traditionally an infrastructure company and generally was always selling to the I.T. Department. With the acquisition by SAP they say that they are now selling to at the CxO level. This has opened a lot of new doors and new opportunities.
  • The distribution and replication of data has always been something that SYBASE excelled at and replication will be a linchpin technology that will tie together many components going forward; my understanding is that it is already used to “real-time replicate” data from ERP into HANA.
  • The combination of real-time data analysis (e.g. HANA) and mobility is likely to be one of the next killer applications in the enterprise.
  • The rate of change in the mobile space is staggering; having a strategic mobility platform is one way to protect your investment in mobility against this risk.
  • Companies who look at mobilizing their data as just another User Interface to existing systems are not seeing the big picture and should take the time to consider the opportunity to see mobilizing the enterprise as a paradigm shift in how they use their business systems. Take the “outside-in” rather than the “inside-out” approach.
  • People are passionate about their mobile devices and are very reluctant to be told what device they should use. We will see a big growth in BYO (Bring Your Own) device policies in organizations and this will drive the need for tools and policies to manage corporate and personal information on a single device across a range of different devices.
  • Many of the security challenges faced today in the mobile device landscape have been around since people started using laptops. They are however multiplied by the fact that people are more likely to take their mobile device with them and the devices are more likely to be always connected.
  • Offline capability is a key component to useful mobile applications. Depending on always being able to connect is generally not a good idea.
  • We will see the emergence of the Enterprise App Store, where organizations will be able to invite their people into the store and make their own and 3rdparty applications available for download. They will also be able to suggest public apps to use from the consumer app store or marketplace.
  • SYBASE Unwired Platform 2.0 adds support for HTML5. Support for Android is expected by early July 2011.
  • Not all devices are “Enterprise Ready” – SYBASE has worked extensively with Samsung to make sure that their Android devices are “Enterprise Ready”. The advice was don’t deploy corporate sensitive data onto any device that is not.
  • There are some obvious business cases for mobility (time = money, faster is better), however there are more subtle scenarios; take for example PIM and EMAIL... what is the business case for that? Yet everyone does it even though it is potentially hard to quantify. SYBASE are working with SAP Value Engineering to build the typical business cases and ROI examples for mobilizing the enterprise.
  • You are more likely to notice that you’re missing your phone than your wallet! (Which I guess makes sense since you are probably handling your phone more often than your wallet!)
  • Applications that run on the SYBASE Mobility Platform will come from 3 main sources: SAP (target 50 apps by end of 2011), Partners & Customers.
  • Some interesting things you can do with Afaria:
    • Disable the camera on the phone while inside secure facilities
    • Disable data roaming when travelling to costly destinations
    • Remotely lock and wipe the device as required
  • Samsung estimates that business sales of tablet devices will grow faster than consumer sales in the next 3 years!
  • SIM enabled devices will continue to outnumber non-SIM (Wi-Fi only) devices
  • Organizations are starting to replace laptops with tablets and many are delaying the refresh of laptops and providing tablets instead.
  • Mobile payments are becoming very popular (just not in Australia!). The future in this area is Near Field Communication (NFC) – for an example of how this works see the recent Google Wallet announcement. However you don’t need NFC by any means there are examples of mobile payments in Austria (PayBox) that predominately used SMS and are from 7 years ago.
                                         

I hope that gives you a good feeling for what was covered (at least in the mobility arena). One last thing I would like to mention is the talk that was given by Glen and Heather Singleman; Husband and Wife world record breaking base jumpers... if you need a bit of inspiration and some “never say die” attitude check them out here www.baseclimb.com . They are absolutely amazing and truly inspiring!

I stumbled at this "Post-PC" concept some time ago in this Egadgeteditorial.

Contemplating on ideas from that editorial for the consumer market and finding another interesting blog for the enterprise market in the IDC: 8 Stats why the Post-PC, Mobile Era is upon Us led me to the gathering of few points for us to think about.

See if any of these titles sound familiar:

  • How will be your new phone?
  • This is new iPhone killer?
  • Tablet, you gonna have one!

Let's agree, we haven’t used the PC that much anymore.

Wish List

Beginning with a current wish list. How many gadgets are waiting to be the next on the line?

Tablets, other tablets, mobile phones, some other “thing” that connects to the internet,  another way to watch Netflix/Hulu and also that cool connected gadget. A computer may even be on the list, but way down at the priority hits.

My computer may be almost two years old, but since it had already received a memory upgrade to 4GB probably I don’t need to worry too much about it. Now my phone, but my phone is getting old he it’s reaching the one year barrier.

It is not just a discussion of durable versus nondurable goods, but a new pace of post-PC era.

When some new feature appears, want the new version.

Apps & Apps

As mobile customers  we are used to have access to an array of applications for every need and App Stores are part of our lives. With the growing number of enterprise application, sooner than we think, we will see MobSS - "Mobile Self Service” - as private enterprise app stores.

To reinforce this tendency SAP’s take on Mobile App Ecosystem is rolling out as we SAP is Building its Mobile App Ecosystem - Fast. How SAP Aims to Lead the Enterprise Mobile App Market - by Eric Lai on ZDNet.

In recent months, how many applications have you bought? Ok, and how many of them where for your mobile? Any for your PC?

You as a Corporate Developer

Want to hear more Post-PC? How many applications have you developed in the last year? How many were mobile driven or have planned mobile versions?

How many platforms have you learned? Let’s be honest you also looked at Objective-C.

Mobile developers today are like late 90’s or early 00’s web developers: inexperienced, ambitious and learning on the job.

Lazy Apps vs. Lazy Users

 

With a mix of user experience and laziness, more and more we expect to  hit one button and reach our goal. Nothing more about the old idea of ​​typing a  command line and wait for an application to load. We want everything  and as soon as possible.

Native applications are more attractive in that way because somewhere in our minds we wait less for a reaction, which gives us momentary well being.

In a post-PC era each "Loading ..." dialog will make us uneasy and nervous. Everything should be faster, responsive and we will grow dependent on real-time.

image
Sorry, nothing will load here...

Actions

Filter Blog

By author:
By date:
By tag: