Do iOS Apps Crash More Than Android Apps? A Data Dive

[Vehl]

17. pls read the article

Before asking me for answers for questions already amply provided in the article.

oh btw, this study compared the Operating systems and not individual handsets, furthermore its in a % and to top it all it even breaks down the crashes by OS version. One could not ask for a more detailed version.

Satisfaction rate and actual hard facts vary. To conflate the two does not make any sense.

Fragmentation defines Android.

I have to reply to this. For example have you looked at the App code for IOS platforms? it uses archaic programming methods..such as hardcoded values!!(hard-coded arithmetic, like y += 7 and MARGIN - 30. lol ) whereas android provides a much more mature and standardized system wherein the Screen resolution is re sized dynamically based on Individual device specs. Unlike IOS which has a set resolution (or its multiples..so they can multiply by 2)


here is a good writeup

http://news.cnet.com/8301-30685_3-57367867-264/android-screen-chaos-a-feature-not-a-bug/

One of the pesky fragmentation issues Android programmers must worry about is different screen sizes.

With resolution changing from one phone to another, programmers have to figure out exactly how much room they can devote to icons, photos, video game backgrounds, dialog boxes. But, Google argues, paying the price upfront pays programmers back in the long run--and helps them avoid the fixed-resolution difficulties that afflicted Palm.

Indeed, even before the first Android phone hit the market, Google had set on an approach designed to accommodate not just different pixel resolutions, but also pixel densities--the number of pixels per inch. Android framework engineer Diane Hackborn described the company's philosophy in a Google+ post yesterday:

Much of the motivation for this came from experience at Palm/PalmSource. Palm devices traditionally had a 160x160 screen. Later in their life, Sony introduced a 320x320 screen; this worked pretty well by just doubling the coordinates supplied by the application so (unless using new APIs) it still thought it was drawing on a 160x160 screen but the OS would convert those and take advantage of the higher-resolution screen to show sharper text and drawn shapes.

This strategy became problematic in PalmOS later, however, when it wanted to ship QVGA [320x240] screens. These were cheaper to produce since they were used in many other devices; by putting the handwriting area at the bottom of the screen you could still have the expected square area for the app. However their density was halfway between 160x160 an 320x320, giving a scaling factor of 1.5, and here the problems appeared.

Scaling up object dimensions by a 1.5x meant, for example, that "your nice solid lines now get various gray smudges on them depending on how they align with the real screen pixels," she said.

To address Android's challenges with screen sizes and resolution, the operating system uses an idea called the density-independent pixel, variously abbreviated dp or dip.

Android's approach to screen resolution can be baffling, and Android comes with a variety of layout tools. Once you master them, "it's zero-effort-easy to make layouts that automatically resize for portrait/landscape device orientations and varying screen sizes," said Meridian Apps programmer Nick Farina in a blog post.

"If you specify, in your application, a button with a width of 100 pixels, it will look at lot smaller on the 640x480 device than on the 320x480 device. Now, if you specify the width of the button to be 100 dip [density-independent pixels], the button will appear to have exactly the same size on the two devices,"

[IMG][/IMG]

more here
https://plus.google.com/105051985738280261832/posts/AzwMc3pSDUU
https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s