I have been looking into Android O and I have to say I am disappointed with the introduction of background limits. This post explains what this means for product owners, developers and the end-user experience.
Many apps, for example those that fetch data in background or scan for Bluetooth devices, do these things so that when the user gets to a particular screen, the data is already there. The most common way of doing this is using services. From Android O, services won’t be able to be run reliably in background unless they are foreground services – these are the sort that you might have seen, that have an icon permanently in the notifications bar. Google recommends services such as these be replaced by use of JobScheduler jobs.
Existing apps built against earlier Android versions aren’t affected. They will continue to be able to use background services. As with the previous permissions debacle, when updating apps (or even creating new ones), developers can avoid building against Android O. However, ‘you can run but you can’t hide‘. You will eventually need new features provided by Android O or later and have to consider what to do.
The long tail of apps, not created by large companies, don’t get updated and those that do minimise effort/cost. Developers wanting to build old apps against Android O will end up either a) promoting services to foreground causing lots of icons to become visible in the notifications bar or b) ignoring the problem or c) using JobScheduler. I suspect, due to limited development effort, most will pick a) or b). The affect of b) can already be seen in Android’ Doze mode that causes no messages to be seen when you pick up the phone and then tens of seconds later everything comes in. Expect more of this kind of ‘stuttering’ performance.
As with the introduction of the need for permissions dialogs, Google continue to make development more complex and costly while also compromising the user experience. I have to question whether Android dev team has it’s priorities right. What’s the obsession with crippling app background capability? This is one of the areas where Android is (currently) much more capable than iOS.
In real use, it has been my experience that devices with lots of apps with lots of services don’t tend to flatten the battery. It’s using the phone, causing the power-hungry screen to be turned on, that mainly flattens the battery. There will always be a mix of old (pre ‘O’) and new (‘O’ +) apps on the device so Google won’t be stopping all background activity, so what’s to be gained by all this extra complexity?
There’s a growing number of organisations thinking that cloud computing and the intermediate communications systems won’t eventually be able to cope with the extremely large number of IoT devices.
Computing near the IoT devices themselves, called Edge or Fog computing, will allow data to be filtered such that only pertinent data ends up in the cloud. It will also allow data to be cached when it can’t be sent yet. Also, there are classes of IoT ‘things’ that need local processing to remove the latency of otherwise using communications/cloud computing and thus provide more immediate alerts and information.
Edge devices can be the IoT devices themselves or low end devices such as Dell’s Edge gateway. They can also be intermediate gateway devices such as the Intel Edison.
An interesting prospect and opportunity for mobile developers is the use of smartphones as edge devices or even devices based on AndroidThings.
Too many companies view app development as a one off activity that can be outsourced (external or internal within the company) and then, once complete, not require the developer any more. However, most non trivial apps need ongoing support of some kind.
Things break. New phones are released and new versions of operating systems cause things to break or misbehave. People, perhaps working on things that the app connects with, change things that cause the app to need to be updated.
Things need investigating. Often there’s a need for 2nd line support to work out what’s happened – even if it’s ‘user error’ and not a fault of the app.
Things need improving. Almost every non trivial app I have worked on has undergone small changes after users have fed back how it can be improved.
Review criteria evolves. What passed Apple’s tight scrutiny a year ago might not pass now. Changing your app in any way might cause it to have to be further updated to meet tighter new criteria.
Factor in time and cost to update your app after it has been initially released. Talk to your app developer before this happens so you have some arrangements in place.
Things go in and out of fashion and so it is with smartphones. In my early mobile career, the perceived (phone hardware) industry wisdom was that noone would ever want a phone without a physical number keypad. They said people need haptic feedback. They said none would type on a screen that has lots of oil and smudges on it having been placed next to the face. The iPhone proved they were wrong.
However, things have gone too far. While you can still get some phones with numeric keyboards, full keyboards for use by writers, bloggers or just ‘workers’ don’t exist any more. We have much better hardware, connectivity and apps since the early PDA days and now is arguably the time when full smartphone keyboards might be more useful.
Planet Computers have spotted the gap in the market. They have the Gemini PDA Android and Linux keyboard mobile device on Indiegogo. It was funded in just 2 days.
The Gemini is engineered by Martin Riddiford who helped develop Psion PDAs. You can read more about his latest design choices on medium.
This is one of the few crowdfunded things I have ever backed. It’s a compelling concept combining an old form factor but bringing it up to date with new ideas, hardware and software. However, note that none of the photos or videos show it actually working. It will be a large effort to make this thing real and more importantly glitch-free. Doing this for $000,000s rather than $0000,000s will be a challenge. The glitch-free part is important if the product is to have a good reputation and hence a future beyond the initial production. On the plus side, the team is experienced and has no legacy company baggage to slow them down. It will be an interesting journey.
IDC has a new press release Smartphone Volumes Expected to Rebound in 2017 with a Five-Year Growth Rate of 3.8%, Driving Annual Shipments to 1.53 Billion by 2021.
“IDC doesn’t expect much change throughout the forecast with Android accounting for roughly 85% of smartphone shipments and Apple making up the rest.”
Despite the growth rates being low, remember these are growth rates, not shipments. A very large number of new smartphones are now being shipped every year.
What does this mean for mobile development? Dual Android/iOS app implementations will continue to be common. However, there’s a thought provoking press release at Mobile World Live (the press arm of the GSMA), where it’s suggested that consumers are tired of apps and bots might rule. I think the key word here is ‘consumers’ in that there’s currently too much emphasis on mobile and retail marketing. People are tired of retail marketing apps. Instead they want apps that do real stuff. Bots are part of this in that they can be used to more easily get things done. In the future, getting things done will increasingly involve VR, IoT, big data as well as bots. All these will need apps to implement the UI/visualisation parts. Mobile will become more of a tool rather than a retail marketing conduit.
Gartner has new press release on smartphone sales. While Gartner concentrates on the battle between Apple and Samsung, the more interesting part for mobile developers is at the bottom of the press release where Android has extended its lead over iOS by 3.2%:
Android now has 81.7 market share. However, Google isn’t standing still and seems to be experimenting with replacing the kernel under Android and Chrome.
Being at the receiving end of enquiries for iOS and Android development has made me realise how many people and companies don’t really know what they are getting into. Some haven’t a clue, not even a hunch, how much effort is involved. Most see a set of screens as something simple. They don’t realise the complexity of what goes on underneath and the consequent communication with other systems and platforms. They don’t realise there are ‘quick and dirty’ ways of doing things and slower and more future proof ways of implementing things, both of which are valid depending on the business context. They don’t think about edge error scenarios, user experience, measuring through analytics and other things like localisation and even the complexities of time. In some cases, there’s no thought as to whether the project is technically feasible.
Ordinarily, this isn’t a problem because many of these things are taken care of by the developer. However, these types of people/companies also tend to not know how to choose a developer. All they think about is cost or daily rates. which gravitates them to developers who don’t know or don’t take care in what they are doing. Not knowing what factors are important and wanting implementation at the lowest cost is obviously a recipe for a failed project.
Google is Integrating Progressive Web Apps more deeply into Android. This will make web apps 1st class Android citizens in that they will be able to be shown in the app drawer and receive incoming intents.
If you are a long time reader of this site, you will know I am not a great fan of hybrid web apps masquerading as ‘native’ apps. They are usually less secure, have significantly less technical capability, have UI performance problems and don’t tend to use the Android OS look and feel. Allowing web apps into the app drawer is a backward step in my opinion.