Reply to post:

Sleuths unearth 'Panic Mode' in Android, set off by mashing back button


'No reason why this should happen unless the app is badly coded. Which is kind of the OP's point.'

Sure, in a perfect world with perfectly coded apps and an (absolutely necessary) enforced upgrade cycle everything would be peachy. Now look at managed app ecosystems (where the apps are only approved if they meet strict responsiveness requirements) and see that they're moribund.

This leads to the reality of trying to e.g. run Firefox and being told 'sorry, this program may at some point be unresponsive, so we're not letting you run it'. *That's* going to go down well.

'Why? Phone functionality is an app these days like any other, but is by definition realtime, and should be a foreground task unless otherwise specified (e.g. when you click away from the phonecall)'

The phone call is only a foreground task when the user initiates the phone call, otherwise it's a background task, because it is interrupting the foreground task the user is operating. Obviously a phone call should have a high responsiveness, now extend that to all the other background tasks and argue the point on those.

'It's also possible in a multitasking OS to give a process a minimum priority - so it won't drop the call, but will divert as much CPU as possible to your game if desired.'

"Sorry - I can't run this game. If a phone call (or other background tasks that's not as user response critical) happened in the middle of it, it might not respond fast enough and cause you to lose a life.". Even though 98% of the time, it won't be a problem, the app has to refuse to run.

This is always going to be a balancing act. Phones and Apple products limit what OS can be installed on them, some times because the manufacturer can't be arsed, other times because the hardware is not fast enough to effectively run a typical set of apps. Even then there are limits depending on the app mix.

The end result in a perfect ecosystem is that the device remains responsive, but there are mandatory upgrades and/or loss of functionality (unless the whole ecosystem is held back by supporting someone that refuses to upgrade their 15 year old device). Apps take longer to come out, longer to be upgraded, and cost more. Possibly a good idea, not necessarily appreciated by users.

In a non perfect ecosystem (i.e. reality) the device slowly degrades, as the apps upgrade, and the OS scheduler does its best to keep everything running. Apps stop being supported on their device, but at a slower rate than in the 'perfect ecosystem'. The user eventually gets fed up and upgrades, particularly if they've ignored recommendations and installed later OS versions not designed for their device.

The advantage in the latter case is that the user can hang to their device for an extra year or two before having to spend hundreds of pounds on a New Shiny. It works most of the time, and that's what they actually care about.

It's not just marketing, it's business. To maximise sales, apps have to target the largest reasonably supportable number of devices. Let's say YourApp will run absolutely fine on 70% of devices, not at all on 5%, fine almost always on 20% of devices, and badly on 5% of devices. In a 'perfect ecosystem' that's 25% of sales instantly lost. The 5% of badly running devices you probably don't want to sell to. The 20% - you definitely do, as the only time it has problems is when all apps simultaneously need to run with their highest level of speed and functionality on the device.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021