Mobile Latency

April 23rd, 2014

wifivslte.pngIlya Grigorik, developer Advocate at Google, has an interesting new post on his blog comparing the latency of WiFi and 4G networks. He concludes that WiFi can deliver low latency for the first hop in the network if the network is idle. 4G requires more coordination between the device and the radio tower but can provide more predictable performance.

He recommends apps don’t trickle data and instead aggregate network requests to both reduce energy use and reduce the overall latency.

I have previously written about chatty APIs, a call for more energy efficient apps and latency.

Related Articles:

Mobile Evolving

April 22nd, 2014

linkedinlogo.gifThree articles over the last few days reminded me how mobile is still growing and changing.

LinkedIn reported their user numbers. They expect to hit their ‘mobile moment’ this year when mobile will account for more than 50 percent of all global traffic. In fact, this has already been achieved in Costa Rica, Malaysia, Singapore, Sweden, United Arab Emirates and the United Kingdom.

Intel reported, in an earnings call, that they expect 80 percent to 90 percent of tablet processors they ship this year to be for Android rather than Windows.

Meanwhile, Android is catching up with iOS in terms of app revenue. This has come about due to the sheer number of Android devices shipped together with the availability of carrier billing in developing countries where fewer people have credit cards.

Related Articles:

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.


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.


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: