Hacker News Reader

> Anyone complaining about Android fragmentation should ask themselves if they would prefer if every device would go the "Apple way" and make their very own operating systems for their device. Would this really solve fragmentation?

I, for instance, would prefer that the industry adopt six or eight standard screen sizes and stick the fuck with them. Google is in a position where it can mandate that, actually.

There are many excuses one can make in Google's favour, but this does not take away the fact that their development environment is very poor, primarily due to fragmentation (and then there's development tools and documentation, but those have been traditionally been a stumbling point).

Also, it's intelectually rude to try to rest your arguments on words for which you construct your own meaning. That's what salespeople do and it's a marginal improvement (in technique, not in correctness) of the straw man sophism.

> "operating system" is a very generic expression. For most people today an operating system is the software that is installed on the device minus applications that the user installed himself.

"Operating system" is a very clear expression that means exactly one thing.

Fragmentation can mean more things, and this article claims one of them. People who want to write software for the iOS operating system have a small set of screen sizes and resolutions to target. People who want to write software for the Android operating system have a fuckload of incompatible APIs, screen sizes and resolutions to target, which is exactly what fragmentation means. This is especially problematic for small apps: if you need 3 weeks to write the core of your application, and 1 day to tweak each combination of obscure resolution and screen size, strange device, hardware configuration range and API version you can easily end up doubling your development time.

Also, if you actually try your hand at writing an application with a decent UI, you'll find that the "a little" you want to tweak it is "a lot". In my experience, if you try to target a full set of platforms, ranging from small phones to full HD tablets, you actually end up designing 3 UIs from scratch (unless you want at least two of them to feel like someone stretched or compressed the other one to fit a screen it wasn't designed to). This includes entire sections of the UI logic (e.g. redesigning navigation flow), and while there are tools to help you with it (such as Fragments), it doesn't take away the pain.

> "Operating system" is a very clear expression that means exactly one thing.

That's not correct at all. An "Operating System" can mean many things and there's tremendous debate in the OS and Systems community over the definition.

Being part of the "OS and Systems" community, I think I'd know :-).

There are a lot of debates about whether X or Y should be a function of the operating system, but that doesn't justify OP's position. Applications that come with the operating system are not part of the operating system, you know, on account of them being separate applications. Unless I missed the debate on whether grep and emacs are essential parts of Linux or not.

The questions you quote are much like the heap paradox, but that doesn't make the concept of operating system so flexible that you can bend it to mean anything. Also, let's be honest here -- quite a few of those questions are there only because at some point in history, fanboys of one platform wanted to rest their fanboyism on some sort of technical grounds, which is how we ended up with fundamentalist-like questions of the "should the OS provide a GUI" sort.

You should know then!

Here's GNU's definition of a Unix-like, "A Unix-like operating system is a software collection of applications, libraries, and developer tools, plus a program to allocate resources and talk to the hardware, known as a kernel." This is a very heavy idea of an OS and grep and emacs sound like "developer tools" and "applications". Most OS people involved in unix-like OSs would be aghast if you didn't at least include some basic userspace applications like cat and ls.

GNU isn't specific about what needs to be in the collection of things to constitute a unix-like OS, but it looks like that agrees in most respects to bookwormAT, "'operating system' is a very generic expression. For most people today an operating system is the software that is installed on the device minus applications that the user installed himself."

GNU's concept is miles different from very light concepts of an embedded OS's like Femto OS which near as I can tell is pretty much just a kernel and some libraries.

WP on the other hand says, "An operating system (OS) is a collection of software that manages computer hardware resources and provides common services for computer programs." So strictly speaking, by this definition an OS doesn't even need to provide disk access like the old DOSs!

Although of course it later contradicts itself and says "Access to data stored on disks is a central feature of all operating systems." which anybody involved in the OS community knows is not a central feature of "all" operating systems. I've used OSs where useful file system access was provided via userspace applications (a la FUSE).

Palantir takes the position that an OS doesn't need to be interacting or managing the hardware stuff, just providing the ability to run different hosted applications is enough, making things like web browsers operating systems (http://www.palantir.com/2009/11/palantir-like-an-operating-s...)

bookwormATs position is that not only are OSs heavy things, but that "Android" is not just an OS, but a meta-OS description of what an Android OS should be (just like XML is a meta-language for describing XML compatible file formats).

So if GNU's definition is correct (and lots of people subscribe to GNU's position), bookwormATs position, "'operating system' is a very generic expression. For most people today an operating system is the software that is installed on the device minus applications that the user installed himself." is correct.

This is the first i've ever heard of a debate, wiki seems pretty clear about what an OS is: https://en.wikipedia.org/wiki/Operating_system

Some questions to consider:

Is it an OS's job to...

-provide a Graphical Interface?

-provide any interface?

-handle a hardware abstraction layer?

-handle font rendering?

-composite graphical displays?

-provide an abstract virtual machine environment across different processor types?

-handle user accounts? What about systems that aren't multi-user?

-does an OS need to handle virtual memory to be an OS? what if all memory management (virtual or otherwise) is handled by a dedicated support chip instead?

Some more:

-does the simple timing code on a $1 digital watch count as an OS?

-does a system that, when turned on, goes automatically to a memory address for more instructions, and those instructions are only the instructions for a user program count as having an OS (lots and lots of computers past and present are like this)?

-does an OS provide software beyond just the Kernel? e.g. Start with a modern linux distro and start removing packages, at what point is it no longer an OS? (GNU would like you to think it's an OS only when you have GNU userspace tools, X etc. on it. )

-is an OS just a space to host and run programs? Does that make the JVM an OS? How about a browser? How about MS-Excel and Macros?

-the OS I'm using right now ships with a paint program, a calculator a browser and a text editor, must an OS have those things?

-how about a system with a complex BIOS that happens to have USB, Ethernet support and a web browser? Is the boot code now an OS? When does bootcode become an OS if this isn't it?

-should an OS handle all available hardware on a system or just some subset?

-what is the first OS in history?

etc. etc. etc.

At some point, somewhere between boot loader and a fully loaded gaming system there exists this thing called an OS. It seems to be more than just a kernel, unless it's an embedded system with basically just a kernel (unless the system is so small and dedicated it just runs code directly without an OS layer (unless you count the code that's running and doing its own resource management an OS since by definition an OS does resource management)), or it seems to be resource management code that also happens to have nice font rendering and a full networking stack. The debate goes much deeper and has gone on for decades.

The Wikipedia article answers most if not all of your questions.

no it doesn't, it even contradicts itself

https://news.ycombinator.com/item?id=6133513

> I, for instance, would prefer that the industry adopt six or eight standard screen sizes and stick the fuck with them. Google is in a position where it can mandate that, actually.

I'd rather think of devices having different size displays, different shape displays, multiple displays or even no display.

Theses things can change rather rapidly! I quite like the idea of skinning incrementally, start with a CLI (or even something more minimal - like the button and beep input/output interface) and go up from there.

There are tradeoffs in every approach and there are steps Google could have taken to make the situation better without mimicking the controlled experience and uniformity of iOS. Unfortunately at this point this is pretty much how it's going to be.

So yeah, it's a "pick your poison" kind of world and theres no easy way out. You deal with it and hope for the best. But that doesn't mean it's not worth pointing it out or that is not a problem for the Android ecosystem in the long run.

> iOS and Windows are fragmenting the market for me. They are not compatible with Android...

By that same logic Android is fragmenting it too.

> When speaking in iOS terms, you can say that 90% of all Android devices get updated once per months or so, when another update for Gmail, Google Voice Search or GCM arrived.

No, as a developer having users in different versions of Android affects the things your app can do. What APIs does it have access to and how. I don't care if the user thinks he's updated because their gmail app looks new. I care that my app needs more hours of coding to make sure it does the same on Android 2.3 than on 4.1.

> ... You can make your app run Holo no matter what Android version is installed on your customer's device.

There are some iOS developers that follow this same route. A lot of services / functions in iOS are not mandatory, you can use your own versions of it if you want to devote the time and skill to rewrite them. Loren Brichter comes to mind as a good example of this. Developers use the Apple route because it's easy and takes out a lot of the workload.

"By that same logic Android is fragmenting it too."

How? Android is an open cross platform technology for building operating systems that are app-compatible with each other. How is that fragmenting?

"No, as a developer having users in different versions of Android affects the things your app can do."

This is correct, but not in the sense that an older version of an operating system (in the iOS sense of the word) would. New developer features of ios7 are a new user interface, better location services, background push notifications etc. All of these things are available on android-based systems as well, but none of these things depend on the Android version.

I admit that there are also APIs that are part of Android, and therefore only available in newer versions. And so an OS that is based on Android 4.0 can not run every app that is made for an OS based on Android 4.3.

But if you need to target all 800 devices that your customers use in the end, the iPhone turns out to be much different from an Android 4.0 device than Android 4.3. And that's the point: You need to develop for all these devices anyway. So think about effort per device, not effort per platform.

> How? Android is an open cross platform technology for building operating systems that are app-compatible with each other. How is that fragmenting?

Situation: there are two operating systems, A and B. Someone who wants to target all the devices on the market has to write two apps, one for A, one for B. This is fragmentation.

Introducing a third operating system, C, means that someone who wants to target all the devices on the market now has to write three apps: one for A, one for B, one for C. This is, arguably, more fragmentation, since you have more apps to write.

Does it really matter what A, B and C are actually called? Android is the latest entry to the mobile operating systems market (save for ghosts like WebOS). If anything, it was one of the driving factors of fragmentation.

> But if you need to target all 800 devices that your customers use in the end, the iPhone turns out to be much different from an Android 4.0 device than Android 4.3.

How? IIRC, there's nothing stopping you from developing with an older API if you want, just like on Android. Sure, you can't use the new and fancy features, just like you can't use them on Android, either...

"How?"

If you're going to say introducing a new OS is fragmenting the market than Android fits that definition as well as any other. If you're going to claim Android gets a free pass because Calvinball well we might as well close the thread.

please re-read my post. My point is that Android is not a new operating system in the sense the word is used today. It is a foundation on which you build operating systems that are compatible to another. Apple could build iOS on top of Android, but you cannot build Android on top of iOS.

Since Android was first released in 2008, Many vendors have replaced their incompatible OS with another one based on Android.

ask themselves if they would prefer if every device would go the "Apple way" and make their very own operating systems for their device.

That's not a question it's a straw man. The real question is whether Android would have been better served by Google withholding their closed source services unless devices met some additional standards on dimensions and software updates.

I make one and then adapt a little if necessary.

This is disingenuous. The whole point of people complaining about Android fragmentation is that you don't adapt a little. You adapt relatively a lot vs iOS which is a bigger market in dollars.

"you don't adapt a little."

Adapt from one of two not android based systems to another, for example from iOS to Windows Phone.

Now adapt from one android-based OS to another, e.g. from the Galaxy S "Nature OS" to HTC Sense.

Compared to the former, the latter only needs to adapt a little.

Android did not make users buy multiple devices. Android did not make users buy into different operating systems. Android just makes different operating systems compatible to another.

> Now adapt from one android-based OS to another, e.g. from the Galaxy S "Nature OS" to HTC Sense.

No, no. Play fair: adapt from Samsung Galaxy 580 to the Asus Transformer Pad TF300TL, ensuring that your interface actually looks OK on both of these and on every device in-between -- that includes the Xperia V, the Asus PadFone and the HTC One X.

And no cheating here -- when a customer complains that the application "looks funny" on his phone, don't forget to factor in the price of buying the damn thing.

Have you actually written a real Android application? Maintaining a list of differences between devices (and the hacks you need to make just to make a program written for the same fsckin platform work on all those devices) is a part-time job in itself.

I have written Android applications before, and I still believe that adapting from Samsung Galaxy 580 to the Asus Transformer Pad TF300TL is significantly less work than adapting from iPhone to Transformer Pad TF300TL.

re: "compatible to another" - this is definitely not always the case. it certainly may be the intention, but is not always the case.

Random example: http://comments.gmane.org/gmane.comp.handhelds.phonegap/3631...

I work for a very popular cross platform mobile application (ios, blackberry, android), and we have dozens and dozens of test devices, a qa department just dedicated to finding differences between devices, and let me tell you that most of the time, special tweaks are required for android that are not required for ios. Surely this is hugely due to the fact that there is less variety in the ios world, but you simply wont find that "manufacturer xyz decided to implement this differently so now the developer must account for that".

Finally, in your analogy of adapting from Android->Android, is similar to adapting from say ios5->ios6. Having been through this several times now, I can tell you with confidence that the initial time of adapting is very similar with equally skilled developers, but the delta of "code complete" to "ready to ship" is much larger on android, due to all of the testing, double-checking, and edge cases. So in summary I would say that you do "adapt a little" with ios, but you end up adapting a lot more than a little for android, if you want to support more than a couple phones, in my opinion.

I've found that ios is a lot worse regarding fragmentation than Android. While Android requires a bit more legwork at the beginning, once you have written the app it will generally keep working on most devices. There aren't too many changes in new Android versions that break things.

iOS however is a horrendous mess. Every year or two they overhaul their layout system (contentScalingFactor, then auto-layout, and other things). Also, each time a new version of iOS comes out you need to work around various bugs/changes and you end up tweaking/hacking your code to get it working on all devices. I've just spent an entire day getting one of our apps working on the ipad in iOS 7, and another half day getting it working on iphone. It will require another day or two to get everything working perfectly, and then I'll have to recreate all the new icons, launch images, screenshots, etc.

Yeah, that's nice. Meanwhile, the next tablet I (unwillingly) buy will be Apple-branded because that's the only viable platform for audio and music, since latency on Android is up to 50x worse.

I own a bunch of android devices, I stuck it out through three major OS updates in hopes that things would improve. I still like my Android devices but 90% of third party apps are single-purpose tools of very limited scope. There's a reason the good stuff is on iOS, and I hate to admit this as I have a bias against Apple for their walled garden and general anti-hacker/tweaker approach.

offtopic?

It's disingenuous to talk about 100 different software systems powering things. Maybe there are 100, but 97 of them don't matter. Lots of desktop OS's too, but pretty sure most people are only targeting windows, mac, and linux. Nothing else comes close to 1% of the market.

The problem isn't that I can't make an app for all the Android devices. The problem is that I can't make it as good as I'd want for all intents and purposes. Developing for iPhone, I can easily hit 95-99% of the market without making any sacrifices at all. It will look good and it will work on every phone, all while allowing me to use the latest features and API's. With Android, the app WILL NOT look as good as the iPhone version on some of the phones. 34% of the market is using something released over 2 years ago, and several major version ago.

I actually like Android, and developing for it isn't the worst thing in the world. But to say it isn't fragmented and doesn't create headaches for developers is absurd. It absolutely adds to fragmentation, and parts of it are a real pain.

"Maybe there are 100, but 97 of them don't matter."

Please reread my post. I'm referring to the software on the Galaxy S, the HTC One etc. as independent operating systems. These OSes matter. It's what people use today on their computers.

Android is not an operating system in the sense that Windows or iOS is. It's a platform on which you build such an OS.

>> "Anyone complaining about Android fragmentation should ask themselves if they would prefer if every device would go the "Apple way" and make their very own operating systems for their device. Would this really solve fragmentation?"

Not true at all. They could standardise on a few screen sizes and minimum hardware requirements and the problem would be solved.

Who is "they"? If Android would only support 6 different screen sizes, then the companies building devices that do not fit into this market would not stop making devices. They would just build their OS not on Android. As a developer you would still need to support these devices. The only difference is that you not have to write more code.

And it's not that screen sizes are the problem when people talk about fragmentation. Any proper made Android app scales easily on all kind of screen sizes.

In web development (I don't know how well this applies to native app development) the way to get around 90% of these worries is feature detection. If touch screen, do such-and-such. If X pixels wide, do such-and-such.

Pixels (CSS, not physical) are especially interesting because they're an angular unit of measure based on the user's expected distance from the screen. Once you start building off that foundation, many device fragmentation woes go away.

That said, there are a handful of places where we logic-branch based on API version by reading the UA string. These are usually due to features that report working, but fail miserably.

Android has the same thing, but it makes much more sense - Android has 3 length units: density independent pixels, scale independent pixels (which are used for fonts, so the user can have a 'huge font' option), and screen pixels. So you can size things in dp, and they will look a similar size on things with different densities. This was built into android from the beginning.

I'd love to have screen pixels in CSS for doing hairlines. I hate when something that should be a hairline comes out fuzzy or lumpy.

It will be interesting to see if Firefox OS, Ubuntu mobile, and Sailfish OS will fragment the same way Android does. Albeit with much smaller data sets, of course.