Nokia’s Lost Opportunities

April 17th, 2014

nokia.gifI came across two things today that reminded me that Nokia lost many opportunities to be successful. The first is an article at digittoday that shows that Nokia had a production ready tablet ready as far back as 2001. The second is a twitter post by VisionMobile’s Andreas Constantinou that shows 15 years of mobile platform history in one chart. However, the chart doesn’t show Nokia’s early (November 2007) ‘Download’ app store that I identified at the time as a lost opportunity. VisionMobile’s chart is slightly misleading in that while the iPhone did appear in 2007, the App Store appeared later in July, 2008.

What can we learn from these Nokia mistakes? While, with hindsight, Nokia’s tablet and early app store might have been technically flawed in some ways, the fundamental ideas were sound. If you have something you are about to abandon, maybe you should think long and hard. Sometimes it is too easy to give up. Can you somehow make your idea more acceptable to users? Might some near-future improvements in related technologies make the idea more acceptable to users?

Related Articles:

Separate Apps

April 16th, 2014

wired.gifWired has a new article with the over dramatic title ‘This Is the End of Facebook as We Know It’ describing how Facebook is separating out the messaging into its Messenger app.

I have previously written about common reasons for separate apps and it appears Facebook are doing this for increased engagement. As I also previously mentioned, the overriding consideration for most companies is cost. It costs a lot more to produce, test, support and distribute multiple apps rather than have everything in one app. Facebook is actually a special case in that the additional cost is insignificant. For the long tail of apps (or companies with smaller budgets), the additional cost usually matters and app creators might be advised to not blindly follow Facebook on this one.

App Marketing and Engagement

April 15th, 2014

theafternoonclub.pngYodel mobile has an ‘Afternoon Club’ for clients where they recently discussed ‘The journey to app engagement’. The main conclusion was the importance of going beyond the download in terms of measurement. Tips included making your app useful, keeping your app updated, capturing data in your app, adding mobile to all your marketing activities and PRing your app.

loyaltybyappcategory_01.png

Here are some further thoughts from my past posts…

Also take a look at insights from a past Mobile Monday London event on Mobile Marketing where the same message was that user retention is as important, if not more important, than user acquisition.

Android NDK Performance

April 14th, 2014

android.gifAndroid apps aren’t just implemented using Java. You can also compile and run c/c++ (NDK) code. This obviously runs faster but how much faster? With newer Dalvik implementations over time, how much faster is c/c++ now?

Learn OpenGL ES has a useful post that compares the speed of a digital signal processing (DSP) filter implemented in Java and c. It shows, in this instance, that Java runs 17.78 times slower than c. However, what’s more interesting is that it’s possible to manually modify the Java code to do things, such as inlining function calls, to get the Java to only 2.87 the speed of c.

The problem with such Java optimisation is that it makes the code significantly less readable. However, I can see the case/opportunity for a Proguard style tool that optimises specifically for speed.

Note that the NDK isn’t just used for improved performance. I have also used it for…

  • Portability - To allow compiling of large open source and particularly proprietary libraries of code not available in Java
  • Increased Memory - To allow access to more memory than is available on the Java heap for example to manipulate whole large images that can’t be loaded into Java
  • Deeper Device Access - Access to particular OEM APIs, for example hardware jpg encoding/decoding, not available from Java

Related Articles:

Google Cloud Roadshow

April 11th, 2014

googlelcoudplatform.pngYesterday afternoon I was at the Google Cloud Roadshow. It was mix of Google trying to sell their cloud services together with much deeper low level programming demos how to use the services, particularly on Android. If the Q&A at the end and my chatting with a few of the attendees are anything to go by, while I personally found the Android parts very interesting, the demos were probably too low level for the audience.

The demos demonstrated how easy it is to create an Android cloud endpoint using Android Studio or via the command line. The command line can also be used to create iOS and Javascript endpoints (libraries). As an aside, it was mentioned that (ADT) support for Eclipse isn’t going away and will be maintained along with Android Studio.

googlecloudendpoints.png 

The demos made the generation and use of an Android endpoint look very easy. However, I suspect that, in the real world, as with alternative solutions, once you have to version endpoints, maintain (CRUD), backup and restore cloud data, things will get a lot trickier. It’s also largely proprietary and later swapping out to use some other backend, when the project is mature and complex, is likely to be difficult and maybe prohibitive. However, what you do get is easy development (initially at least), scalability, claimed resilience and affordability that Google said will continue to decrease in price in line with ongoing decreases in hardware costs. I suppose the question you have to ask is when might you ever want to change backends? Future security or service level concerns perhaps?

Google also explained that they have a new service called Managed VMs (currently in preview). Traditional cloud services require server side developers to choose from a limited set of programming tools, libraries etc. This means developers have to make difficult compromises. They often can’t use particular chosen languages, tools or libraries. At the other end of the scale, traditional on demand VMs allow you to run anything on a (Linux or Windows) server. Google’s Managed VMs are a mix of the two in that you can run Google’s tools/services in your own Google VM(s) together with your own choice of languages, tools and services. Google also manage the OS and Google tool updates.

The Q&A at the end was interesting in that just about every question along the lines "Will Google support xyz in its cloud offering and if so when?" produced the answer "We don’t have anything to say about that at the moment". The problem is that Google is predominantly engineering rather than customer driven. They have no medium or long term roadmap. Things might appear or be dropped at will. Therein lies the problem for the Enterprise trying to use Google services. Companies don’t really know if or when xyz will be supported by Google. In the past, enterprises, especially large ones, have relied on the likes of Microsoft publishing roadmaps through partnership programs. The way Google works means they can’t do this.

I think Google’s Managed VMs is a pragmatic response to this problem. It means Google now have an answer in that if they don’t support what you require then you can mix and match with a Managed VM. However, it doesn’t solve the problem of wasted effort if you go off and ‘do your own thing’ in a Google VM and Google then soon release a similar thing under their own tools.

Looking back over the projects I have worked on over the last few years it’s clear there’s no common way companies implement the server side. The number of different server side architectures used is nearly the same as the number of projects I have worked on. Google cloud endpoints add yet another another architectural possibility. 

Related Articles:

Heartbleed and Mobile

April 10th, 2014

heartbleed.pngI use a lot of online services and it’s interesting to see which ones haven’t been hit by the Heartbleed vulnerability. They tend to be the ones that have an extra layer of security. This includes those that encrypt data before sending via SSL and those where I have enabled two factor authentication.

From a personal viewpoint, it’s a reminder to use two factor auth when it’s available. A quick audit of my used services has caused me to enable GitHub two factor auth today. From a mobile app architect viewpoint it’s a reminder to overlay extra security for apps (banking etc) that require the highest security.

Incidentally, all versions of Android, with the limited exception of Android 4.1.1, are immune to Heartbleed. This is from the client end. Your server side might still be vulnerable. 

Related Articles:

Growth in Mobile Ad Spending

April 9th, 2014

iab2.pngThere’s some research by PwC and the UK IAB that shows over one in four consumers now own a tablet. Mobile ad spend is accelerating and exceeded £1.3bn in 2013 and accounts for a sixth of all digital ad spending.

What might this mean for app developers? More ad spend, specifically on mobile, might be making ad-funded models more financially viable. There might be more scope for tablet apps that promote real products. Perhaps there are affiliate link funded app opportunities? I expect retail loyalty apps, such as the white label solution I created for Movanta might see a resurgence in interest.

Related Articles:

Android First

April 8th, 2014
techcrunch.gifThere’s an article "The fallacy of Android First" on TechCrunch. Emu developed on Android first, hit fragmentation problems and ended up on iOS. When developing an app, I think there are four main factors that affect Android fragmentation…
  • How an app is developed
  • The APIs required
  • The supported Android versions
  • The supported Android devices

These factors can also interact to compound the problems. It seems Emu mainly got tripped up with the APIs required. SMS is an especially tricky area on Android because Google have significantly changed the API over time. Most apps are just ‘information viewers’ and as such don’t hit such large fragmentation problems.

So what can others learn from this? First, I don’t think Emu did enough upfront analysis and research. They might have abandoned Android earlier had they known the difficulties earlier.

My advice to any new project is to get an experienced developer look over what you are about to do and advise if and how to proceed. They can save you a lot of grief. If your chosen developer won’t or can’t advise then move on and find someone who can. Do risky parts first to prove. If the app looks complex, think about a minimal proof of concept app before committing fully. All this advice goes for any app, not just Android or mobile.

Of problems, Emu spoke of…

"…difficulty of finding them, and of understanding them well enough to fix them. We can’t test on every Android device we support, so we get bug reports in the field that we couldn’t anticipate and can’t reproduce. And, plenty of bugs go unreported and, therefore, unnoticed."
 
People underestimate ongoing support and development (on iOS and Android). Nothing stays still. There are always new OS versions and new devices. It’s impossible to test everything. In complex apps, it might also be impossible to fix everything due to difficulties on specific devices. I have seen this on iOS as well as Android.

Android first? It depends. Take a deep look at your product’s technical requirements. Do some analysis and experimentation before jumping in. At the extreme end of the scale some projects are Android Only. Take a look at my fragmentation reduction tips. Additionally, plan for problems - on iOS AND Android. Also, don’t expect to be able to ship and forget.

Related Articles: