Posted
by
samzenpus
on Sunday February 05, 2012 @09:08AM
from the best-of-class dept.

First time accepted submitter creativeHavoc writes "Forbes author Tomio Geron takes a look at data accrued by mobile app monitoring startup Crittercism. After looking at normalized data of crashes over the various mobile operating system versions he compares crash rates of apps on the two platforms. He also breaks it down further to look how the top apps compare across the competing mobile operating systems. The results may not be what you expect."

I've decided to opt for a Samsung Galaxy Nexus Android 4.0 device from SaskTel when I eventually get a smart phone (subject to new models coming out from Samsung or HTC and sold by SaskTel), but that's because it's a Java-based system I already have the tools to program, not because I'm concerned about app stability overall.

In fact, the odds are I won't use the thing to run too many apps if what I need is already included: email/web, GPS mapping and routing, and Java applications (including one I'll be working on myself some time in the next year or so.)

In the short term, I'll probably opt for a BASIC voice-and-text flip-phone of some kind, because I can't afford (nor stomach!) spending $600 on a PHONE whose MAIN purpose is to MAKE CALLS when I can get a $70 model that will take care of that primary function just fine for now.

The $600 device's main purpose is NOT to make calls. It's an internet communications device that just happens to make phone calls. The people who insist that basic phones are just fine need to figure out this slight, but important, distinction. Buy an internet device if you want internet, but don't compare it to a phone.

So IOS 4 used cooperative multitasking (http://forums.pcworld.com/index.php?/topic/89287-apple-ios-4-vs-android-multitasking-which-approach-is-better-for-users/page__st__160) while I believe android uses a modern pre-emptive multitasking approach. I know IOS 5 has updated multtasking but it is unclear to me if they have gone to a full pre-emptive multitasking scheme.

iOS has always had a full multi-tasking kernel. It is Unix for crying out loud. I would write more, but obviously you don't care because otherwise you would have typed, "iPhone Kernel Multitasking" into your favorite search engine and found and read any of the top articles that the search engine provides. Go on, try it out, if you care at all, which I doubt........ And really, for "proof" you grabbed post #161 from random post on some article?

In the short term, I'll probably opt for a BASIC voice-and-text flip-phone of some kind, because I can't afford (nor stomach!) spending $600 on a PHONE whose MAIN purpose is to MAKE CALLS when I can get a $70 model that will take care of that primary function just fine for now.

Its a common perspective, but first of all most people (at least in the US) buy their phone subsidized with a contract renewal, so the price for even a top-tier phone is $200-$300. Second, for me personally after using smartphones for a few years, I view it as the most significant personal (non-work) computing device I use daily. I definitely use it more than my home PC and tablet combined, and can therefore justify spending top dollar on a quality "phone". I won't make assumptions about you, but I know many people who found, when they get a smartphone, that its main purpose is NOT to make calls.

It is they, who in collusion, raised the price of buying a phone to astronomical levels. Remember when the highest price for an unlocked phone was usually $200? What phone broke that trend? Iphone.

It ended up making the carriers a ton of money even though the consumer gets screwed.

And of course other vendors jumped on the chance to offer similar products for a lower price, right ? There are vendors out there getting killed and yet they don't offer smartphones for significantly lower prices in order to scoop up marketshare. That seems to indicate they can't undercut current prices.

I don't think this has as much to do with Android and iOS as it does with the state of software quality in general. The current state of software quality is abysmal, since the shift to scripting languages and web apps as the primary platform about ten years, the science and art of writing robust and reliable software for OO, event driven, asynchronous platforms like iOS or Android has become an almost lost skill. Unfortunately failure modes for these platforms are more dramatic than for web apps, in that you'll likely get a crash rather than 'error on page' message. The situation has been further exacerbated by management's insistence an always hiring the lowest quality developers they can find, outsourcing, H1 B's etc. If you use low quality and inexperienced devs, you'll likely get an unstable and and unreliable application on these types of platforms. This should be a wake up call to the industry in general in that we need to focus and engineering, quality and reliability, and not just minimizing cost.

Actually I miss my old BB as it was a good phone and gave me email. It may be a smart phone, but it never had the apps that the Google and Apple offerings have.I haven't used a BB in a couple of years now so I have no idea what they are like now. I will be checking them out though on my next phone purchase as I do not want another Android or Apple phone.

Perhaps age has something to do with it, but I really need the phone functionality to do my job. It seems that every time I need to make a phone call with my Google phone, I have no battery left. They just don't keep a charge for any length of time and woe to you if you actually want to run apps on it. At any point in time, if I take a glance around the office, I will see virtually all of my colleagues at their desks with their phones permanently plugged into an outlet.

I find myself wondering how many of the Razr owners also carried a iPod. and that when the iPhone launched, they replaced two devices with one. I suspect iTunes would make such a transition mostly painless, sync the iPod one last time, then sync the iPhone and be on your way.

The article did not clarify if they removed the "Low Memory" and "Active Assertions Beyond Permitted Time" entries from the crash log.

When iOS has memory demands it will kill suspended background processes and this shows up in the crash logs with a low memory reason. When a background process is running (not suspended) to complete some task (like downloading/uploading data, etc) and it exceeds the allowed execution time, iOS will kill it with an assertions beyond permitted time reason.

Neither of these are actual "crashes" as you might think of them and in fact users are often completely unaware the app was killed because when you switch back to the app it just reloads its state where it left off (and well-written apps actually restore your position in the UI).

If these two items weren't excluded then the results for iOS are worthless.

The article also pointed out that iOS 5 is new and there are likely to be crashes generated due to apps not being updated yet and that Android is likely to have a similar problem as ICS actually starts rolling out (or people buy new devices when they are stuck with a non-upgradable device).

Bad apps crash -- sure. But *worse* apps may appear to keep working while storing up later trouble for the user.

Whenever I see a list of software fault types with "crash bug" at the apex, I cringe. When I led a software team, I had to de-program developers who were trained that crashing is the worst possible thing an app can do. It isn't. There are many worse ones, such as leading a user to trust false data, exposing sensitive information, and losing or corrupting a user's work. The worse thing about a crash in the absence of data loss or long recovery time is that it undermines user confidence. It's often possible for a well-architected app to crash (due to programming faults of course) with no serious implications for the user.

Crashing per se isn't a problem. It's a *symptom*. This is important! I've caught developers "fixing crash bugs" without addressing the real problems: failure to program defensively around unexpected conditions like bad input or inability to secure resources like memory or file references. I've seen super-general exception handlers buried way down on the stack which catch every possible exception and quietly attempt to restore the semblance of operation, even though they can't possibly know whether the application is in a consistent state, or whether it is holding orphaned resources. Programmers do this because they've been inculcated with the false notion that crashes per se are terrible things. This leads to hiding the symptoms errors rather than fixing the errors themselves. Hiding the cause of a crash increases the probability of faulty information, loss of data, and shipping a release with serious defects.

So don't treat crashing as a problem, but as an alert signal. A crash in itself is benign, an honest recognition of failure if you will.

The Skype app crashes all the time, and it's almost always iOS's fault. If you go through the diagnostic logs, you'll see that almost every time that Skype "crashed" it's because it's either using "too much memory" or because it "didn't respond fast enough."

I wouldn't call that iOS' "fault". Mobile devices have very limited resources. This isn't like a desktop machine where you've got several gigabytes of memory to play with. If an application is badly behaved and it uses too much memory, that has an effect on the rest of the system. There's only so much memory to go around. Also, if using lots of memory becomes normalised, there's pressure to add more memory to newer models, which will result in lower battery life.

I'm an app developer, and if I ever see that one of my projects is killed for not responding fast enough, I know that there's something very, very wrong somewhere. Usually it's a sign that a junior developer decided to do something processor or network intensive synchronously on the main thread, which is a big mistake. You do what is necessary to get an interface up, and you push everything expensive into the background and update the UI when it finishes. There's no excuse for an application not responding quickly enough, it's easy to do.

If you really think Skype is not at fault, how do you explain the fact that it crashes all the time on other platforms as well?