As a developer, layout and screen size is not the main problem with Android. To be honest, Android isn't even the problem. It's hardware that Android is built on that is the problem. If a handset is broken down into all of it's sensors [Speaker, Camera, Light Sensor, Microphone, Compass, Accelerometer, Clock, NFC, GPS, Screen, BLE, Wifi, Altimeter, Speedometer, CPU] that's where the fragmentation problem is. It's hard to say which devices contain certain sensors (CPU, Screen, Camera, Mic, and Speakers are pretty standard). Of the devices that have most of those sensors, it's hard to say say which devices have those sensors working correctly.
I attended a Facebook/Parse hackathon where FB detailed issues about a certain bug in specific CPU's with respect to a C++ based photo processing library. Certain Android phones would randomly crash. There is also the infamous compass video [1] where multiple devices all with different hardware report different readings. As a developer, the Android Emulator makes me think I'm going to have a consistent user experience, but based on hardware, I may not.
In my personal experience, I built this game (http://joeblau.com/orb./) which runs on iOS and Android and I noticed a crazy bug where it would only crash on S4's from Sprint, not from Verizon or AT&T. I re-worked some code to get the application working eventually, but the fact that something would only break on a specific carrier's version of the hardware was crazy to me. The problem is not Android; Android as an OS is actually very good. The problem is HTC, Samsung, Motorola and all of the other hardware manufacturers that build the handsets. Thankfully Google is doing what it can to address the hardware issue by announcing their Android One program, but that hurts other hardware competitors.
This was addressed at the Linux Plumbers Conference and the Linux kernel mailing list a few years ago. The problem is not just hardware manufacturers trying to differentiate themselves, but carriers fucking around with software loads trying to differentiate themselves. On the hardware side at least, this resulted in virtually a brand new port to every new SBC that came out, even though they were almost all ARM.
It used to be you could run Linux on MIPS, SPARC, Alpha, PowerPC, Intel, etc, and not be able to tell the difference from an end user perspective. Then everyone got dollar signs in their eyes, and Google managed to fudge the whole "open" thing so that people were okay with binary drivers (I also blame Ubuntu for acceptance of this), and now you see the mess it's resulted in.
Don't get me wrong, I'll take the Android bazaar with its wide variety of choice every day (and twice on Sunday) over the one-size-fits-all-we'll-tell-you-what-you-need style of iOS, but the insanity with differentiating things via closed methods needs to stop. And the Android/Linux developers are aware of the problem and dealing with it the best they can; the problem is all the handset manufacturers and carriers fucking things up.
Thank you for calling out Ubuntu (a wolf in sheep's clothing in many ways, despite the significant role Ubuntu has played in bringing great people to the Linux community and the fact that they do a lot of good too) and fronting open-source drivers. HN seems mostly ignorant of how critical free drivers are while it continues to flock around diatribes against far-downstream effects of relying on closed blobs. User freedom stems fundamentally from the ability to make use of the components in devices they own. For the uninitiated: that's exactly what drivers do.
Free drivers are the way to go, but pushing proprietary drivers was never really Ubuntu's fault. It has been a lack of development of free software drivers because of non-cooperation by hardware vendors. But the community has stepped up with better support for historically unsupported things like accelerated video. If you install 14.04, it does not recommend proprietary drivers except in cases where there is still a lack of options.
I'm not saying Canonical is entirely innocent, but they do employ a lot of fervent free software advocates and developers. What we need to fix the situation is more pressure on hardware vendors to release specifications and free software. Perhaps if Ubuntu Touch takes off, Canonical will be in a better position to provide that pressure.
What we need to fix the situation is more pressure on hardware vendors to release specifications and free software.
Very much this. Even with the vast power that kernel developers wield, even with offers to write (for free!) and integrate drivers into mainline[1], the biggest pull is still consumers. Push your hardware vendors to (at a minimum) release specs; it's the right thing to do.
[1] - For seven freaking years this offer has stood: http://article.gmane.org/gmane.linux.kernel/487536
And yet we still have retarded fucking hardware companies who won't release specs. Fuck 'em - don't buy from them.
> I noticed a crazy bug where it would only crash on S4's from Sprint, not from Verizon or AT&T. I re-worked some code to get the application working eventually, but the fact that something would only break on a specific carrier's version of the hardware was crazy to me.
I was looking into this a few days ago (for a much more off-the-wall reason I won't go into) and it turns out that Samsung actually will ship devices under the same brand (such as "Galaxy S5") that use entirely unrelated SoCs depending on the radios the device is intending to support: some devices use Qualcomm's Snapdragon, and some use Samsung's own Exynos, so there are tons of possibilities open for these kinds of "Sprint-specific" issues :(.
The problem with Android is that the API offers no guarantee that your call will work correctly on all devices. This is especially true for anything related to sensors like the camera. It is up to the manufacturers and carriers to honor that contract and they simply don't do a good job of it.
Android fragmentation is real, but screen sizes are not part of the issue. The whole system is built around the idea of supporting different screen sizes, and provides you with the tools you need to handle them.
The real fragmentation is in hardware support (don't get me started on OpenGL-ES drivers) and manufacturers that modify the OS in crazy ways. It's quite frustrating to receive crash reports with stack traces showing a crash originating in some manufacturers custom code, with no way of knowing what went wrong.
My favorite Android app is Moves. Moves does not work on Samsung Galaxy Note II, thanks to one of many tweaks Samsung has done to Android. This phone is one of the most popular Android phones in the world and it's running a very recent version of Android. I find this completely unacceptable.
A lot of games and certain apps also list "compatible devices" in their Play Store description area. Some developers even warn users not to pay for and download the app if their phone is not supported.
This is true but mostly an issue for games. With multiple OEMs and multiple sources of GPUs and drivers - significantly more than for PCs, the only solution is for driver quality to improve. History suggests not holding one's breath.
For the wild west of Android html5 hybrid development, fragmentation is a huge problem. Different manufacturers roll different implementations that behave differently. Javascript event propagation varied and broke my app on my last HTML5 project. Luckily, the chrome view will be the default webview from KitKat onwards, but it will take at least two years for 4.4+ to become ubiquitous.
I think iOS' HTML5 issues (webview throttling) are self induced though. Apple has a vested interest in developers learning, and being locked into their proprietary ecosystem.
A bunch of devs building slick HTML5 apps would go against this.
At the same time, Apple is strongly pushing developers to not use pixel perfect layouts anymore that are dependent on particular screen sizes, and to use auto layout everywhere. If you follow Apple's iOS 8 guidance, you really shouldn't have any problem dealing with even the original graph of "terrible" fragmentation.
Which prompts the question whether it was really that bad after all, or just a gut reaction to something that was different.
No, on those early devices, which were at least an order of magnitude slower than current devices, pixel-perfect layout was the only way to achieve fluid animations. It's not an accident that iOS devices were so much better at animations compared to Android devices in the early days, despite not necessarily having the best hardware.
But this is no longer true, or at least true to a much lesser extent. With current hardware you can achieve 60fps reliably even with a layout engine running constraint evaluations for every frame. It makes sense to make it easier to target variable screen geometries now, which was not the case 7 years ago.
> It's not an accident that iOS devices were so much better at animations compared to Android devices in the early days, despite not necessarily having the best hardware.
Pixel perfect layouts had NOTHING to do with that performance gap, and iOS devices have far and away the best GPUs of each generation. iOS devices consistenly push fewer pixels (lower resolution screens) with faster GPUs than Android does.
The only reason people think Android devices are such power houses is because everyone still just looks at the CPU core count and clock speed. Which has almost no impact on scrolling and animation performance.
EDIT: For example compare the Galaxy Nexus to the iPhone 4S. Both shipped Nov 2011, both use PowerVR GPUs. The GN is rendering 920k pixels, the 4S is only 615k pixels! The GN is making due with the SGX540 at 307MHz, whereas the 4S has the SGX543MP2 at 266mhz or so - literally double the GPU power of the GN, and for a lower resolution screen.
No, dynamic layout is a big factor, which is the reason why Google added new APIs for apps to tell the OS not to re-evaluate layout.
In every year's Google I/O there's at least one session on Android performance, and in every session there was always some technique on how to prevent layout calculation during animation.
So I'm just a old town country ios programmer for fun, so please correct me if I'm wrong. But wasn't the original issue that there wasn't a great way to deal with the multiple layouts/issues on the early 2.3 and below android models?
ios8 makes it plainly obvious that "something" is coming that will throw out the "the size of the screen shall be 5 and 5 shall be the size of counting, not 3 nor 4 but 5" paradigm. That or multitasking similar to windows 8 maybe.
But this shouldn't be all that crazy hard, we had how many years to deal with 800x600/1024x768/etc...
The core infrastructure for variable screen sizes and densities was introduced in Android 1.6 Donut (September 2009). There have been improvements with newer versions (e.g. more sizes and densities), but that's straightforward to deal with.
The other big improvement was the Fragments API that came with Android 3.0 Honeycomb (February 2011), but that came with a compatibility library that worked all the way back to Donut. And it was more about decomposing your UI into components that could be arranged differently for phones and tablets, not about adjusting a single UI within a device class.
Nope, there have been no substantive changes to the way one handles these layouts since android 1.0, with the exception of some additional targeting for LTR and changes to the way you address physically larger or smaller screens (as opposed to screens with fewer or more pixels).
They split phone sizes (2-10") into four generalized sizes (small, normal, large, xlarge). Then they split screen density into generalized densities (ldpi, mdpi, hdpi, xhdpi) based on 3:4:6:8 ratios. The example on the page lists 5 different layout XML files (the 4 previously mentioned + extra large landscape orientation) for different sizes, and three folders for image assets in different densities.
But, there are tablet layouts for Android 3.2+, which use a completely different system based on size qualifiers where you can provide minimum/maximum pixel sizes for layouts.
The logic for iOS seems super simple in comparison.
With a few Android projects under your belt, you have probably internalized how everything works, and which parts are fringe cases you can ignore. But if you're new to this (or a journalist/analyst with limited technical depth), it seems like an absolute mess. Simply rewriting this documentation and providing better tutorials and resources could go very far to clarify the situation.
Generalised sizes are a deprecated way of handling screen sizes on Android, from version 3.2 onward we use far more traditional dividers such as minimum width. For many developers it's viable to support only 4+, which lets you avoid a lot of the trickiness.
Also, even if you are supporting 2.x, you don't HAVE to have a separate layout file for each generalized size. If you make a flexible layout that works on all sizes, you can just declare it once (and doing so is not difficult in most cases).
I totally agree the documentation needs work. Some areas have not been updated in a very long time.
To be fair, the belief is a little more that anything wider than 1024 is typically too wide. Find me a site that lets text run for even that long. Typically you box things in much more heavily.
Comfortable reading widths should use font-relative measurements, not pixel measurements. The various studies about readability talk about words per line, which depends on font-relative width. For instance, you might set a line width in em or ex.
On a 1080p or even 2160p TV, the text should absolutely go all the way across, using a large font readable from across a room. On a high-resolution tablet, the font should still likely go all the way across the screen in portrait mode, and most of the way across in landscape mode, even though either one likely has more than 1024 pixels. On a phone, the font likely should go all the way across the screen in either portrait or landscape mode.
Right, this is definitely the more correct way. I'm just saying that, by and large, many designers were not doing anything bad if they set a width for their design at 1024. It isn't that they were wrong or right. They were just using a simplification that largely worked.
That should really be the decision of the browser user, but sadly years of poor training has led far too many people to just maximize every window, no matter how big their screen is.
Poor training? Or could it, perhaps, be a conscious desire to be at least semi-modal? Unless I have physically separate screens, I much prefer to have a single, maximized application going on onscreen almost all of the time. That doesn't mean I want only one application running, but that I generally only want one occupying my attention at any given moment. (The very existence of "distraction-free writing" applications makes me believe I'm not alone here.)
Name it, I've used it. I prefer full-screen, one-task-at-a-time if I can have it, no matter what you may like. Neither side is wrong (or doing it wrong). I just don't want the stuff I'm not using right now to be there. Period.
Well, you're wrong in that you seem to think I was trying to convince you of something. I was just curious as to your setup, since my habits run similar.
Personally, I use ratpoison, typically with one window full-screen.
Many, many years (just about 30 of them, in fact) of people telling me I really, really want tiled or overlapping windows despite my protestations have conditioned me to expect it.
To an extent. Sites like bostonglobe (and google plus) take it to give more columns the wider you are.
This is no different than how newspapers are done. Just because you have a giant piece of paper doesn't mean you should let the text flow completely across it.
"That’s the beauty of Android’s massive market share, we can ignore all the people with phones running Android 2.3, those with odd and rare screen sizes, and target only 4.0 and above"
Well duh. If you ignore all the things that give you trouble/fragmentation you automagically get a trouble-free/fragmentation-free environment. Silly
I think he is trying to say that because there are so many Android devices out there, you can afford to ignore the troublesome ones and still have a huge market to cater to.
You have to ask, though, if those with the old, weird and outdated devices are the users you want to target at the cost of doing more productive development for users with more recent and capable devices who obviously can afford and/or care more about their mobile experience.
Screen fragmentation was a large problem even before Android. When I was first learning to program, one of the platforms I initially targeted was Windows Mobile, version 6.0. On this platform fragmentation was limited because there were only so many devices developed for Windows Mobile (although screen resolutions were generally different for QVGA vs non-QVGA screens, and smartphones with keyboards had smaller resolutions). Nevertheless, fragmentation was still a problem.
Without an api adequate for handling different screen sizes and resolutions, it was hard to develop an application for one device then port it to other devices. I use the term "port" because usually this was actual porting; in some cases it would have been better to have a separate binary for each target device than to have a single binary for all devices.
I think the reason Windows Mobile developers were so rare compared to developers for emerging platforms like iOS and Android despite Windows Mobile having been around longer is that the alternatives learned from WM's poor example to create better apis. When I switched from Windows Mobile to playing around with Android 2.1, there was so much more I could do with layouts and the simulator in the IDE to target more devices. Newer versions of iOS, Android 4, Windows Phone, and others have all been improved in this regards even more, to the point that I now think of screen fragmentation as something of a non-issue when I tinker with mobile apps.
One thing that the op doesn't address is that the top 10 devices they have selected account for only a fraction of android market. I think there is an implicit assumption that if you cover the top 10 device models you can consider that a proxy for the overall android market but the original fragmentation report shows that to even cover 50% of the market you need to consider around 60-70 device models.
i think his larger point is that it's not screen size that causes layout fragmentation, it's screen aspect ratio, which is (basically definitionally) more consistent across devices.
I'm developing my first Android application and am beginning to work on the interface in earnest.
Can anyone recommend some good tutorials or guides for producing elegant layouts that respond well to different screen sizes? I understand the basic mechanics and laid out in the dev guides, but I'm a bit lots when it comes to putting it all together elegantly.
This post pulls a neat trick: the diagram they criticise is all android devices while their diagram is only phones. And suddenly:
> The above diagram and analysis also only take into account phones, not tablets, _where designing for physical screen size becomes more important than resolution._
my main issue with Android fragmentation is trying to support HTML5 Apps with PhoneGap/Cordova and various JS toolkits (Sencha Touch, JQueryMobile, Dojo).
Each version(4.0, 4.1, 4.2, 4.3) has a slightly different version of the default browser and WebViewUI component(and don't get me started on Samsung devices which have their own issues regarding the default browser) with it's own quirks and rendering issues.
They kinda fixed that in KitKat 4.4, using Chromium 30 as the basis of the WebViewUI component, but KitKat deployments in the wild are in the single digits.
Hmm, the whole write-up doesn't really disprove the screen fragmentation issue. Mostly downplays it. That there are layout tools to help you cater for multiple screens for example, doesn't mean they do that work for you. Or that the "slight variation in width" he mentions should not also be taken care of.
(Which is just part of the whole problem -- there's also the hardware features and OS version issues which are even more important).
> Or that the "slight variation in width" he mentions should not also be taken care of.
What exactly is the issue with this? Just like with any other sane widget toolkit designed since the 80's for varying screen or window sizes, Android's layouts and widgets work perfectly fluid to occupy more or less space. One layout works just as well on a 4-inch phone as it does on a 5.5-inch phone, and it will naturally fit more content on the bigger screen.
The only problem is with tablet screens where blowing up a user interface designed for a small phone screen technically works but is pretty terrible to use. This is no different from another unnamed mobile platform where you also need to design a separate tablet layout.
>What exactly is the issue with this? Just like with any other sane widget toolkit designed since the 80's for varying screen or window sizes, Android's layouts and widgets work perfectly fluid to occupy more or less space.
It becomes an issue if you're not a sloppy kind of designer/programmer, who just lets the widget flow to occupy more available space. It's not like design only use things like a text entry boxes or a web-views (widgets that just letting them get more space is usually fine and natural).
Second, it becomes an issue for every app where you want to have a custom interface -- so the built-in Android widget and layout are of no use to you. This holds for most games, customly designed apps, etc.
It becomes an issue if you're not a sloppy kind of
designer/programmer, who just lets the widget flow to
occupy more available space.
So it's sloppy to build your UI in the exact way it was intended to be built? Not hard-coding every widget sizes is somehow... sloppy? Because the impression I get is that if you can make your app handle different screen sizes appropriately without having to meticulously hand code for every resolution, you're coming out way ahead of the game. That way you present a nice, consistent UX across all devices, and don't have to scramble every time a new resolution or device size comes out.
It's also possible to do this with custom interfaces - a little extra attention to your layout engine will net huge benefits in terms of time saved in designing layouts for each of the possible resolutions.
Hardware variations, vendor customizations, capabilities variance - these are real issues. Building a UI that flows well across most resolutions and sizes? Not so much.
> It becomes an issue if you're not a sloppy kind of designer/programmer, who just lets the widget flow to occupy more available space.
What? In most cases, that is exactly the right thing to do. Your content should be the center of the app in the first place.
> It's not like design only use things like a text entry boxes or a web-views (widgets that just letting them get more space is usually fine and natural).
Why don't you name some actual, concrete examples instead of making vague statements like this? Where do you think that this is an issue?
> Second, it becomes an issue for every app where you want to have a custom interface -- so the built-in Android widget and layout are of no use to you. This holds for most games, customly designed apps, etc.
What does a "customly designed app" even mean? There are countless examples of Android applications designed beyond the norm (http://androidniceties.tumblr.com/) and they don't seem to have any problem doing so - and guess what: they're using the Android frameworks just like everybody else.
And just like application developers, game developers have been working with a myriad of different screen resolutions for ages now. The only people having a problem with this are those exclusively developing for a certain fruit device that has shot itself in the foot by not designing for varying resolutions in the first place.
There are two main parameters in screen geometry: Size and density. You can deal with the major size differences across tablets and handsets with Fragment objects and two or three different layouts per Activity, keyed to screen size, and two or three sets of assets, keyed to density. So at most you have 9 combinations, usually 6 or fewer, to test. This will cover 90%+ of non-game cases. Portability for OpenGL games is a whole other universe.
Also: Use RelativeLayout. Get your designer to design directly in the layout editor, and test them on screens he finds important and representative. That way he won't specify designs that can't be implemented.
Well, we can't have only two phone manufacturers with their own OS, Apple with maybe 3 different aspect ratios and Google with another two or three. Everybody wants its share of the cake so we'll inevitably end up with many different screens and OS, basically how it has been until 2007. I prefer to have designers and developers clever enough to adapt to variable aspect ratios on two OS than an ecosystem fragmented into a zillion of technologies. I think we've been lucky.
So if you ignore all the weird screen sizes it is only fragmented into 4 different sizes? And you still have to create layouts for each of those sizes? I wouldn't say the point was very strongly made.
I can confirm this, at least for games. For the last game I made, I had to have all assets in 4 sizes, which makes it look nice in all resolutions ranging from 800x450 to Nexus10 2560x1600. I maintain the aspect ratio and have background that is larger (both wider and taller) than "playing field", so that I can fill up that space on devices with different aspect ratio. What article fails to mention that all Android devices have aspect ratio between 4:3 and 16:9, and you should design around that.
The background image looks like this (not my game):
No, if you ignore a tiny segment of the market the changes in screen sizes are tiny. And you have been able to create scalable views (and really have only had the option of doing so) since day one, so mostly you just create a single layout.
The tools on Android are very similar to the ones on the web - they are designed to scale and stretch because they need to.
You could build one layout using relative positioning and have it scale to each of those easily. If you want different layouts for different devices, this is an option, but by default things won't break unless you're explicitly positioning things absolutely instead of relatively.
Don't think there's any fragmentation problems on Android OS?
Just try creating a mobile website that supports common "modern" devices. Have fun trying to wrap your brain around all the idiosyncrasies across various versions and browser implementations (Android Stock vs Chrome etc) that will endlessly dirty your code if you want the site to look at all correct in a majority of Android devices.
The Android emulator is pretty nice... once you figure out how to set it up for whatever device you're trying to test. It's a ridiculous resource hog though by default (there are ways to mitigate this if you're on an Intel chip). Say what you will about simulation vs. emulation but the iOS Simulator is a dream to work with (again, for web development) and I've never had it mislead me even though it isn't truly emulated. But then you realize there is no way to install the Chrome browser unless you are hooked up to the Android Marketplace (even if you're on the latest version of OS). The best you can get is Chromium, which is a pain to install and doesn't work on some AVDs.
All that ranting aside, I've never had a problem with screen sizes, even when working on responsive stuff. But, yeah, Android is basically the Internet Explorer of the mobile space. You'll keep hearing "oh the next version will fix that!" and it may... but you'll be stuck supporting the versions that are broken for years to come.
Oh thanks for breaking it down for me. When it comes to web development, for all intents and purposes, they can be thought of as one in the same since the browser version issued with a device is tied to OS version[1]. Of course some users will upgrade OS and/or browser, independently in some cases, which complicates things further.
In that link he mentions it but it bears a little breaking down. His chart is showing the versions of the rendering engine that is used to back a WebView. It isn't for the browser included with the phone. Google has requirements how WebViews are implemented but the requirements for the default browser are pretty light. Even if the user doesn't swap out their browser you don't know what you might get. See section 3.4 of the CDD for the requirements.
I attended a Facebook/Parse hackathon where FB detailed issues about a certain bug in specific CPU's with respect to a C++ based photo processing library. Certain Android phones would randomly crash. There is also the infamous compass video [1] where multiple devices all with different hardware report different readings. As a developer, the Android Emulator makes me think I'm going to have a consistent user experience, but based on hardware, I may not.
In my personal experience, I built this game (http://joeblau.com/orb./) which runs on iOS and Android and I noticed a crazy bug where it would only crash on S4's from Sprint, not from Verizon or AT&T. I re-worked some code to get the application working eventually, but the fact that something would only break on a specific carrier's version of the hardware was crazy to me. The problem is not Android; Android as an OS is actually very good. The problem is HTC, Samsung, Motorola and all of the other hardware manufacturers that build the handsets. Thankfully Google is doing what it can to address the hardware issue by announcing their Android One program, but that hurts other hardware competitors.
[1] - https://vine.co/v/MgWLMmmwUQQ