Zebra have a new free 2015 Global Shopper Study (pdf)
that has some useful information if you are creating retail apps.
On the positive side, shoppers are very interested in WiFi and location-based services. This bodes well for the iBeacon related apps I have recently been working on. On the negative side, only 38 percent of respondents trust retailers to protect their personal data. This emphasises that we should explain what we are doing with their data in app store descriptions and in some cases inside the app.
If you are looking for areas in which to innovate, consumers are increasingly seeking customised offers. They are also eager to have email receipts, receive shopping maps, use WiFi hotspots and receive location based assistance.
The Droidcon NYC 2015 video presentations have become available offering 48 sessions covering a wide range of topics. What I like about this and other Droidcons is that presenters come with no hidden agenda. There’s usually very little promoting of their respective companies or products and instead it’s all about advice gained through experience. It’s also great to compare how others have solved problems that you have experienced yourself.
For me, one such problem is described in the Beautiful Typography on Android (or close enough) session presented by Lisa Wray of Genius. On multiple projects I have had the problem of having to render server sourced, sometimes human created, HTML in Android. As Lisa explains, there are two ways to do this. The first way is to use a WebView and the other is to use a TextView with fromHtml() which converts the HTML to lots of Spanned text.
The problem with TextView.fromHtml() is that the result is often incomplete and lacks the fidelity of the original HTML. Lisa Wray’s presentation shows how to modify the Spanned text created by fromHtml() to make it, as she says, “Beautiful (or close enough)”.
Stepping back, this situation pinpoints something that should probably be avoided at the architecture stage anyway – the app displaying arbitrary HTML from the server. Managing this so that it renders well in an app and across mobile OS platforms can be very difficult. This is because you are trying to mix web and app display paradigms. While HTML might look like being convenient, it’s not usually well suited to consistent display in apps. If you can, it’s better to store and communicate content as text and meta data.
About to publish an app? Already published an app and need to get more installs? There’s a free app store optimisation event, ASO Barcamp 2 coming up in London on 1st October 2015.
If you want to know what to expect from this event or want to start learning now then take a look at the previous event presentations that cover the following topics…
You can book free tickets for the next event via the ASO Barcamp site.
The Mobile Academy blog has lots of tips for startups. For example, last week there was an excellent post on 10 Tips to Market Your App for Little or No Money. It’s great to see some pragmatism and realism in this article. One of the problems with some high level advice and development best practice is that it comes from people in larger well funded companies. It often assumes you have infinite development effort and funding. In the real World of the long tail of tightly funded apps, the harder decisions are often associated with compromises to ideals.
Also take a look at the Mobile Academy post on insights from an audience with Russell Buckley. The first point is “If you haven’t read The Lean Start-up, you should”. I would go so far as to skip this book and read the much more pragmatic and actionable “Running Lean” authored Ash Maurya that’s part of the Lean series by Eric Ries – author of the original book. Ash takes Business Model Generation (mentioned in my Mobile Development Primer) and has developed a Lean Canvas.
The gist of the Lean Canvas is to document your plan, identify the risky areas and create lean experiments to exercise and evolve the plan.
The next Mobile Academy starts 1 October in London, a collaborative course that gives a grounding in mobile business and design.
Flurry has a new press release on how people, in the US at least, are now spending more time in mobile apps than watching TV – and that excludes mobile browsing…
Flurry expect the success of apps to extend to (Apple) TV…
“And just as they did on the iPhone and iPads, consumers will download these apps and spend plenty of time on them, leaving the dozen or so cable channels lost in a sea of apps”
I am not so sure. I don’t think people are spending more time in apps just because they are, well, apps. Mobile devices are personal things while apps on TVs are more of a shared experience with other people in the room. I really can’t see people starting up, for example, Facebook, Twitter, eBay, Amazon or Tinder on their TV where it’s harder to navigate and less private. From a personal perspective, at home we already have set top boxes with apps, fire/chrome sticks with apps, a TV with apps and I can’t say any of the extra 3rd party apps have been used on our TV.
Instead, I think the future lies with smartphone/tablet apps that integrate with the TV. For example, in the UK we have a YouView set top box service that has a great app where you can set up recordings when you are out and about. There are also opportunities for TV program makers and broadcasters to better engage with viewers through apps.
Nielsen has new research that shows large screen Android smartphones (phablets) doubled market share over the last 18 months. Interestingly, phablet users use their phones more…
“Phablet owners are 28% more likely than all Android+ users to report having played online games and 33% more likely to have consumed video content in the past 30 days”
From a development viewpoint, as I mentioned a few months ago, the rise of phablets probably has implications on how we might design apps to make best use of these larger screen sizes.
When I created ActiveVault, one of the thoughts was to also try to protect Java code. However, whatever way I looked at it, it wasn’t possible. You can encrypt code but as soon as you decrypt and load the Java, it becomes visible in two ways:
The first is that, since ART and Android 4.4, it’s not possible to dynamically load (decrypted) Java code without it appearing in storage. Previously, with Dalvik, it was possible to dynamically load extra code to memory. For devices with the ART runtime, an OAT file containing the DEX file has to exist in the file store, in the dalvik-cache directory. This is world readable even on un-rooted, unmodified devices. The technical reason why the file has to be in storage is so that it can be paged out by the OS. There’s DexExtractor available to extract such files on the emulator.
The second, more involved way, that involves tampering with the OS, is via hooked functions. This is where attackers can intercept function calls to do extra things such as read files/data. Utilities such as DexHook and DexHunter (research paper pdf) can intercept the code as it is dynamically loaded.
Yes, there are some code protection utilities or packers that claim to encrypt code or classes. These do what they say, they encrypt code, but they are of not much use if the code is easily readable later on when processed by the OS. There’s no way to fully protect Java code. It can only be obfuscated.
If you are creating an app targeting my home country, the UK, then there has very recently been a surplus of stats. Deloitte have a press release saying Britons collectively check their smartphones 1.1 billion times a day.
More than 32 million smartphones will be shipped in the UK in 2015; one for every other person in Britain. Over a third (36%) of smartphone owners look at their device more than 25 times a day. What’s new? Well, mobile payments are increasing.
Meanwhile, 34sp has a new UK Mobile Usage Study (pdf) based on a survey of 1000 people. 30% of respondents said their mobile phone is the main device they use to access the Internet. 1 in 4 of said their mobile is the main device they use to read the news.
What’s new? 20% say they have argued with friends for being distracted by their mobile phone. 25% admitted to having argued with a partner over checking their phone. It seems that ‘social’ is actually making us less social.