Any mobile GUI developer who doesn't realise that a UI designed for specific screen size will be better than a fluid design isn't a good mobile developer.
At the worst are those idiots that thing the same design, resized, will do for both phones and tablets.
Fluid design is a partial fix for the problem of unknown sizes. When sizes are non unknown, the problem doesn't exist in the first place.
To an iOS developer who hard-codes screen resolutions and aspect ratios like a Guttenberg-press typesetter would at the end of the 15th century, dealing with screens of different resolutions, different aspect ratios, and different sizes like Android does would seem like an insurmountable task to him/her, but that's one of the easiest problems to deal with once you start understanding the Android fundamentals and once you start writing your application the Android way
Mobile apps designed for specific resolutions are always superior to ones that auto-resize themselves.
That, and more significantly the iPad / iPhone difference has caused me far more headaches than Android's zoo of screen sizes.
Android was designed from the ground up for arbitrary screen dimensions
If you're autosizing the same app for a phone and a tablet, your app has a shit UI. If you've put code in there to do different things on the two device types, then that's the same as what you do on iOS.
iOS couldn't even deal with it effectively until iOS 6.0.
Balls. Auto Layout is a convenience, it doesn't mean you can do anything that you could already do.
And which 'missing' APIs specifically is there going to be a problem with for apps?
What's with putting missing in quotes. Are you denying that it's only a partial solution?
Of course it isn't, but it resolves the developer issues.
Clearly it doesn't as real mobile developers (as opposed to the Android fanboys posting here) are complaining of the problems of fragmentation on the platform. And many are avoiding Android as a result.
Fragmentation doesn't even mean having multiple versions in the wild at the same time... that is normal.
I tend to agree. Though most people think the opposite.
And it is fairly easy to support all devices that have the features you want, by using the older techniques for functions that don't require newer features.
Case by case it might be easy. The sum total of all the differences is not easy at all. And the real hassle comes when you get bug reports and you're not sure if it's specific to certain phones/OS versions. Then you have to find one to test with. Good luck with that with the variety of Android devices.
Anyway, devices with different features certainly is fragmentation.
Another thing that isn't "fragmentation" is devices having different screen sizes. Just like having different video cards doesn't mean your desktop OS is fragmented.
Oh dear. The UI paradigm is quite different. Mobile device software excels when it's been designed for a particular screen size. Desktop apps have huge amounts of space by comparison and are designed for the user to choose the size for the particular task in hand.
Mobile devices with different screen sizes certainly is fragmentation.
As far as I can tell as an app developer, there is 0% fragmentation. And lots of bloggers who don't know what it is.
By the statement that there is 0% fragmentation in the Android market, you prove that you are the one that doesn't know what it means.
Because it's a band-aid that gives support for a limited number of new APIs on older OSs. It's not a magic shim that transforms an old OS into a new one.
iOS is fragmented, just like Android, because as a developer you can't rely on every device running iOSx to support every feature.
Fragmentation is a scalar value not a bool. iOS has a little fragmentation, Android has a vast amount of it.
And even that understates the difference. On iOS, there's a handful of product lines, all well known by developers, which only improve with time. With Android the numbers of different devices, and the differences between them arbitrary, are so vast it's essentially unknowable.
That you think them the same makes you either dishonest or not a mobile developer.
Porting an app from one Android phone to another might be trivial. Porting from one Android version to another might be trivial. Supporting the vast fragmentation of Android OS/Phone combinations is far from trivial, it's a fucking nightmare.
Chalk and cheese. When talking about 2010 Android phones that can't run the latest Android version, we're talking about Android phones actually RELEASED in 2010. Not ones from earlier years that happened to still be on sale in 2010.
Apple released the iPhone 4 in 2010. Which means that the 3GS was still the current phone in the early part of the year. But just because the 3G was still on sale doesn't make it a 2010 phone.
The support library is a sticking plaster over the fragmentation problem. It gives some functionality of recent OS versions to devices stuck on old OS versions. It doesn't give you all the APIs of the new version. It's not magic pixie dust.
Which market? There's more Android phones sold, but commercial apps? Few Android users will buy apps, meaning that adware the predominent model. And few make that work.
iOS makes far more money for developers than Android. That's why it's typically the first and often the only platform that serious developers target.
If you target all the wonderful features of iOS6 you still need to support older hardware that doesn't run some of it.
If you're targeting iOS 6 you're targeting iOS 6. There's no missing API. Supporting the few differences in hardware is part of the API and well documented.
Fragmentation is about more than just the OS version. Available hardware varies, CPU/GPU speed varies, screen resolution varies, camera resolution varies etc.
There's 2 reasons why this is a problem for Android and not for iOS.
1) On Android the differences, and combinations of differences across all the devices are vast and essentially unknown to a developer. On iOS the variations are small and entirely known.
2) On iOS within the handful of product lines, features only ever stay the same or improve. Evolution, not fragmentation. With Android it's a fragmented crapshoot.
Frankly. if you don't appreciate there's an enormous gulf between dealing with the few varieties of iOS device and the vast fragmentation of Android, then you are not a mobile developer.
Of course not. They are supplied by 3rd parties. And Apple then becomes responsible for them when they include them in Macs.
However, this story concerns batteries that were never preinstalled in Macs, or were in any way supplied or authorized by Apple. This is simply a case of Best Buy buying some cheap 3rd party replacement batteries, then finding out later why they were cheap.
Slashdot Mirror
HTML might work on a vast range of device/window widths, but does it work well on all of them? Typically no.
Any mobile GUI developer who doesn't realise that a UI designed for specific screen size will be better than a fluid design isn't a good mobile developer.
At the worst are those idiots that thing the same design, resized, will do for both phones and tablets.
Fluid design is a partial fix for the problem of unknown sizes. When sizes are non unknown, the problem doesn't exist in the first place.
To an iOS developer who hard-codes screen resolutions and aspect ratios like a Guttenberg-press typesetter would at the end of the 15th century, dealing with screens of different resolutions, different aspect ratios, and different sizes like Android does would seem like an insurmountable task to him/her, but that's one of the easiest problems to deal with once you start understanding the Android fundamentals and once you start writing your application the Android way
Mobile apps designed for specific resolutions are always superior to ones that auto-resize themselves.
That, and more significantly the iPad / iPhone difference has caused me far more headaches than Android's zoo of screen sizes.
Android was designed from the ground up for arbitrary screen dimensions
If you're autosizing the same app for a phone and a tablet, your app has a shit UI. If you've put code in there to do different things on the two device types, then that's the same as what you do on iOS.
iOS couldn't even deal with it effectively until iOS 6.0.
Balls. Auto Layout is a convenience, it doesn't mean you can do anything that you could already do.
You're spamming now. But at least this one was good for a laugh:
I don't believe this is available on iOS.
iOS doesn't need such a band-aid. It doesn't suffer from the problem in the first place.
Guess what? iOS developers only care about users that connect to the app store.
Similarly Googles horribly fragmented figures come from Google Play. Which is almost as significant for Android developers.
If you were to measure ALL Android devices, Android would look even more fragmented.
Is it missing APIs or not?
And which 'missing' APIs specifically is there going to be a problem with for apps?
What's with putting missing in quotes. Are you denying that it's only a partial solution?
Of course it isn't, but it resolves the developer issues.
Clearly it doesn't as real mobile developers (as opposed to the Android fanboys posting here) are complaining of the problems of fragmentation on the platform. And many are avoiding Android as a result.
42% Samsung is not "The vast majority of Android phones".
http://www.businessinsider.com/samsung-android-market-share-2013-2
You might get updates for your phone via UK carriers, that doesn't mean that most UK Android users are, let alone people in other non-US countries.
And the fact that despite that you still choose to use CyanogenMod just underlines how much the stock versions of Android that most users have suck.
Fragmentation doesn't even mean having multiple versions in the wild at the same time... that is normal.
I tend to agree. Though most people think the opposite.
And it is fairly easy to support all devices that have the features you want, by using the older techniques for functions that don't require newer features.
Case by case it might be easy. The sum total of all the differences is not easy at all. And the real hassle comes when you get bug reports and you're not sure if it's specific to certain phones/OS versions. Then you have to find one to test with. Good luck with that with the variety of Android devices.
Anyway, devices with different features certainly is fragmentation.
Another thing that isn't "fragmentation" is devices having different screen sizes. Just like having different video cards doesn't mean your desktop OS is fragmented.
Oh dear. The UI paradigm is quite different. Mobile device software excels when it's been designed for a particular screen size. Desktop apps have huge amounts of space by comparison and are designed for the user to choose the size for the particular task in hand.
Mobile devices with different screen sizes certainly is fragmentation.
As far as I can tell as an app developer, there is 0% fragmentation. And lots of bloggers who don't know what it is.
By the statement that there is 0% fragmentation in the Android market, you prove that you are the one that doesn't know what it means.
And for developers it's a fraction of the money making opportunity of iOS. Which is the thing that matters.
Because it's a band-aid that gives support for a limited number of new APIs on older OSs. It's not a magic shim that transforms an old OS into a new one.
iOS is fragmented, just like Android, because as a developer you can't rely on every device running iOSx to support every feature.
Fragmentation is a scalar value not a bool. iOS has a little fragmentation, Android has a vast amount of it.
And even that understates the difference. On iOS, there's a handful of product lines, all well known by developers, which only improve with time. With Android the numbers of different devices, and the differences between them arbitrary, are so vast it's essentially unknowable.
That you think them the same makes you either dishonest or not a mobile developer.
Your iPod Touch is 5 years old.
Porting an app from one Android phone to another might be trivial. Porting from one Android version to another might be trivial. Supporting the vast fragmentation of Android OS/Phone combinations is far from trivial, it's a fucking nightmare.
Chalk and cheese. When talking about 2010 Android phones that can't run the latest Android version, we're talking about Android phones actually RELEASED in 2010. Not ones from earlier years that happened to still be on sale in 2010.
Apple released the iPhone 4 in 2010. Which means that the 3GS was still the current phone in the early part of the year. But just because the 3G was still on sale doesn't make it a 2010 phone.
All 2010 iPhones run the latest OS.
if you're going the unlocking and rooting route, a lot. So how many 2010 apple phones can run the latest OS?
All of them.
The support library is a sticking plaster over the fragmentation problem. It gives some functionality of recent OS versions to devices stuck on old OS versions. It doesn't give you all the APIs of the new version. It's not magic pixie dust.
Which market? There's more Android phones sold, but commercial apps? Few Android users will buy apps, meaning that adware the predominent model. And few make that work.
iOS makes far more money for developers than Android. That's why it's typically the first and often the only platform that serious developers target.
If you target all the wonderful features of iOS6 you still need to support older hardware that doesn't run some of it.
If you're targeting iOS 6 you're targeting iOS 6. There's no missing API. Supporting the few differences in hardware is part of the API and well documented.
Fragmentation is about more than just the OS version. Available hardware varies, CPU/GPU speed varies, screen resolution varies, camera resolution varies etc.
There's 2 reasons why this is a problem for Android and not for iOS.
1) On Android the differences, and combinations of differences across all the devices are vast and essentially unknown to a developer. On iOS the variations are small and entirely known.
2) On iOS within the handful of product lines, features only ever stay the same or improve. Evolution, not fragmentation. With Android it's a fragmented crapshoot.
Frankly. if you don't appreciate there's an enormous gulf between dealing with the few varieties of iOS device and the vast fragmentation of Android, then you are not a mobile developer.
Most Apps built for iOS5 are often a few recompiles away from running on iOS6.
Most apps build for iOS 5 will run on iOS6 without any recompiles.
It's the same with targeting Android 4.0.x as the baseline. You will hit 75% of the Android market.
First of all 75% is not nearly the same as 93%.
But in any case your claim for 4.0.x is wrong. You have to go back to Gingerbread 2.3.x to get up to 75%. Version 4.0.x is below 50%.
http://en.wikipedia.org/wiki/File:Android-dist-by-dessert.png
Of course not. They are supplied by 3rd parties. And Apple then becomes responsible for them when they include them in Macs.
However, this story concerns batteries that were never preinstalled in Macs, or were in any way supplied or authorized by Apple. This is simply a case of Best Buy buying some cheap 3rd party replacement batteries, then finding out later why they were cheap.
They are not responsible for 3rd party batteries that Best Buy bought and resold.
So Best Buy are responsible for this. They ordered the batteries from a third party. Apple is not connected in any way, nor responsible.