Interesting app design reality
- Thread starter Seadog
- Start date
Skull One
iPF Novice
That is the understatement of this century in my opinion.
If you are doing NO screen I/O, then Android is hands down easier for developer to use. Java is simply faster to code in than Objective-C (unless you have years of experience). But the second you have to deal with the screen that is when Android becomes a nightmare. Let me layout the differences so you get an idea what Android developers have to worry about.
Under iOS you have two target coordinate systems to code against.
1) 480 x 320
2) 1024 x 768
Notice I didn't show Retina? That is screen resolution and a different animal than coordinate system.
So lets list them next: 480 x 320, 960 x 640, 1024 x 768 and 2048 x 1536.
This produces four "screen densities". 163 PPI (Pixels Per Inch) and 326 PPI for the iPhones. 133 PPI and 266 PPI for the iPads.
That's it. Predictable and easy for the developer to handle. BTW to activate Retina graphics developers simply have to place graphics into proper resource area of XCode and add @2x to the end of the file name before .png. iOS automatically selects from the four sets of graphics which one to use for the iOS device you are on. Apple REALLY thought this thru.
Under Android you have to deal with 14 coordinate systems (and this list can change with the introduction of a new device):
1) 240 × 320
2) 320 x 480
3) 340 x 480
4) 360 x 640
5) 480 x 640
6) 480 x 800
7) 480 x 854
8) 540 x 960
9) 640 x 960
10) 800 x 600
11) 1024 x 600
12) 1024 x 768
13) 1280 x 720
14) 1280 x 800
Now how the heck is a developer supposed to deal with this? Well them tried to make it easy. Each one of those coordinate systems falls into one of four screen size (3 to 10+ inches) and one of four screen densities (Pixel Per Inch). And remember they make a 5" display with 1280 x 720 and a 10" display with 1280 x 720. That means your PPI difference is HUGE and requires major differences for text display.
Android allows you to code against one of four systems. Pure coordinate (good luck with that), screen resolution groups (small, normal, large, xlarge), screen density (ldpi, mdpi, hdpi, xhdpi) and finally density independent pixels. Lets discuss the one that is used the most.
Screen density allows you to use an XML screen layout to approximate where you want to position your screen assets (text, buttons, graphics) and the device has the necessary math to convert your code to its screen. That means an application will "approximately" look the same across all devices. Yes, some of those devices will have "blank areas" because the screen resolution simply doesn't work out math wise. And now a quick mention about Density Independent Pixels. It is basically a mathematical way to help resolve Screen Density (the four l, m, h, xh DPIs) divided by the true display density. This gives you the proper offsets for the target display.
BTW, if a manufacture doesn't put in the proper information for Android to use for all of the screen calculations, it doesn't matter how much work the developer does, the screen just isn't going to look right. This happened a lot when the first tablets were introduced.
So now you know the back story of why Android is a nightmare and why Apple got it right
If you are doing NO screen I/O, then Android is hands down easier for developer to use. Java is simply faster to code in than Objective-C (unless you have years of experience). But the second you have to deal with the screen that is when Android becomes a nightmare. Let me layout the differences so you get an idea what Android developers have to worry about.
Under iOS you have two target coordinate systems to code against.
1) 480 x 320
2) 1024 x 768
Notice I didn't show Retina? That is screen resolution and a different animal than coordinate system.
So lets list them next: 480 x 320, 960 x 640, 1024 x 768 and 2048 x 1536.
This produces four "screen densities". 163 PPI (Pixels Per Inch) and 326 PPI for the iPhones. 133 PPI and 266 PPI for the iPads.
That's it. Predictable and easy for the developer to handle. BTW to activate Retina graphics developers simply have to place graphics into proper resource area of XCode and add @2x to the end of the file name before .png. iOS automatically selects from the four sets of graphics which one to use for the iOS device you are on. Apple REALLY thought this thru.
Under Android you have to deal with 14 coordinate systems (and this list can change with the introduction of a new device):
1) 240 × 320
2) 320 x 480
3) 340 x 480
4) 360 x 640
5) 480 x 640
6) 480 x 800
7) 480 x 854
8) 540 x 960
9) 640 x 960
10) 800 x 600
11) 1024 x 600
12) 1024 x 768
13) 1280 x 720
14) 1280 x 800
Now how the heck is a developer supposed to deal with this? Well them tried to make it easy. Each one of those coordinate systems falls into one of four screen size (3 to 10+ inches) and one of four screen densities (Pixel Per Inch). And remember they make a 5" display with 1280 x 720 and a 10" display with 1280 x 720. That means your PPI difference is HUGE and requires major differences for text display.
Android allows you to code against one of four systems. Pure coordinate (good luck with that), screen resolution groups (small, normal, large, xlarge), screen density (ldpi, mdpi, hdpi, xhdpi) and finally density independent pixels. Lets discuss the one that is used the most.
Screen density allows you to use an XML screen layout to approximate where you want to position your screen assets (text, buttons, graphics) and the device has the necessary math to convert your code to its screen. That means an application will "approximately" look the same across all devices. Yes, some of those devices will have "blank areas" because the screen resolution simply doesn't work out math wise. And now a quick mention about Density Independent Pixels. It is basically a mathematical way to help resolve Screen Density (the four l, m, h, xh DPIs) divided by the true display density. This gives you the proper offsets for the target display.
BTW, if a manufacture doesn't put in the proper information for Android to use for all of the screen calculations, it doesn't matter how much work the developer does, the screen just isn't going to look right. This happened a lot when the first tablets were introduced.
So now you know the back story of why Android is a nightmare and why Apple got it right
Last edited:
MattIM
iPF Novice
Wow! Thank you SkullOne for your commentary on screen issues facing developers. This is discussing just one aspect of the iPad, albeit, one of the more important ones. But on top of that, or rather under that, Apple only has one iOS to deal with.
I read in another thread that Android has several iterations of operating system that is not compatible across all manufacturers, for example, the Android OS used by Motorola Xoom, is not compatible with what Samsung uses for its tablet and not compatible for what Asus uses for its tablet. Developers would have to write their app for each of the manufacturers providing tablets. That is a lot of work. It also explains why there is not one Android Appstore and why Android owners don't have the number of apps available.
I read in another thread that Android has several iterations of operating system that is not compatible across all manufacturers, for example, the Android OS used by Motorola Xoom, is not compatible with what Samsung uses for its tablet and not compatible for what Asus uses for its tablet. Developers would have to write their app for each of the manufacturers providing tablets. That is a lot of work. It also explains why there is not one Android Appstore and why Android owners don't have the number of apps available.
Skull One
iPF Novice
Currently you have Android 1.6, 2.0, 2.1, 2.2, 2.3, 3.x, 4.x in general use. The majority of users are on 2.3 and are being migrated to 4.x very slowly. But if your device was built before say Nov 2010, I doubt you will see an upgrade. Which is a real shame since Android 4 fixes a lot of issues.
As far as the Xoom went, it was one of the few tablets that was on Android 3. And that is where a LOT of problems came up. Google normally releases the Android code to the public. But Android 3 was never released. Mainly because it was garbage and Google knew it. Because of that, there are some issues with certain applications running on the Xoom. The good news for Xoom users is they can get the Android 4 update and fix all those problems.
As far as the Xoom went, it was one of the few tablets that was on Android 3. And that is where a LOT of problems came up. Google normally releases the Android code to the public. But Android 3 was never released. Mainly because it was garbage and Google knew it. Because of that, there are some issues with certain applications running on the Xoom. The good news for Xoom users is they can get the Android 4 update and fix all those problems.
seneca18
iPF Noob
Also, not sure if it impacts developers but there are only a few android phones running pure android (Nexus line for example). All of my HTC phones had HTC sense UI installed.
thomaswoodlick
iPF Noob
Two years ago, the elegant iPhone has housed some of the most poorly designed applications that you can't imagine. The hype surrounding iPhone has prompted many designers across the globe to try their skills with the new mobile medium. Its results are literally thousands of various iPhone-applications that are often hardly usable and counter-intuitive. One of my friend has also made an app for iphone/ipad named as "The fat finger" that you can check at Fat Finger Keyboard | Keyboard for Fat Fingers | Touch Text App. This is also an interesting app and design for reality.
Skull One
iPF Novice
I couldn't agree more. Which is why Apple created a document for application design that must be signed off on now if you become a iOS developer. It contains a lot of dos and don'ts concerning GUI usage and flow control. While it hasn't cleared the issue up 100%, it has brought a much better standard of apps in the last year.
Most reactions
-
441 -
342 -
208 -
196 -
133 -
110 -
66 -
20 -
11 -
7 -
6 -
4 -
2 -
K
1
Similar threads
