Might makes right?
Yesterday at Google IO the company unveiled some pretty nifty new features, API's and even some new tooling for developers. But generally speaking the new tooling was all around new functionality. And so little, if anything, was done to improve the development environment for Android developers.
Microsoft improves its already fantastic Visual Studio IDE on a regular basis.
Apple improves their development suite (if at a slower pace). And even goes so far as to toss in new programming languages in an attempt to resolve things for its developers.
Google on the other hand doesn't seem to care how terrible their suite of tools is. And they don't really need to. They have the monopoly on mobile devices. People will target Android, whether they use Google's tools or not (those in the "or not" camp are typically using cross platform tools/tech).
Oddly, my favourite part of the conference was the part around Appurify. This is a great service, but ultimately one which shouldn't be needed. And Android is truly the only platform out of the top 3 (or even top 4) where such a service would ever be necessary. Apple's hardware is WAY too constrained for such a service to be justified. Windows Phone hardware is more limiting, but the platform is also much more heavily structured.
On the other hand, I wouldn't be surprised to find a toaster that run Android.
But hardware fragmentation, and even OS fragmentation aren't really the problem.
Even where a software runs on a device that should be supported by Android and leverages only valid API's for that device it can still behave differently than it does on another device that meets that same criteria. And while I cannot promise the opposite is globally true across iOS and Windows Phone devices, the reported occurrences are far lower. To the point where I've only ever heard of such occurrences on faulty devices.
And that is just the runtime. A bad runtime can bite even developers who write good code. A good runtime runs reasonably consistently across supported devices. I'm sure Google is putting in effort here on an ongoing basis. But, at least for older devices or devices which aren't officially updated to the latest software (which is appears to be a large percentage of devices) those efforts don't really end up helping.
But, probably the bigger problem is that modern applications are fairly complex. They have user interfaces and need to respond to touch commands which are difficult to interpret some times. They may need to respond to virtual keyboards and gestures. They may need to read input from a variety of sensors including gyroscopes and accelerometers. They need to deal with potential connectivity issues from potentially multiple sources (cellular data vs. WiFi). They may be sensitive to changes in transfer speeds (move from an area with LTE coverage to an area with only 3G coverage to an area with none).
Even a simple mobile app is often not a simple mobile app. And this is the reason that your development tools are such a big deal for developers. You need emulators that function and function like a normal device. You need the ability take your testing from an emulator and to a real device and then debug remotely as well. This was probably this biggest gripe I experienced and heard from others as well. The emulators are a pain in the butt to setup and, once setup, often fail to even load. And since I've never seen a functional Android phone fail to boot, the problem is with the tools.
Honestly, what they need the emulator to do is supply profiles that match known devices. I would say, take one or two flagship phones from each iteration, then lump in 1 or 2 of the most popular devices from both the mid and low end for each iteration instead of providing an emulator that allows you to tweak arbitrary specs. I don't really care my app runs on a phone with 11MB of RAM for instance... it isn't a possible configuration. It's cool that I can do it. But it doesn't make the broken ass emulator work any better and it doesn't allow me to emulate a practical device. So it is functionally useless.
You also need the ability to know what you're targeting. As with iOS or Windows Phone you can choose a compatibility level. But the difference is, I can rather safely say where to draw the line to get my appropriate mix of market share and API availability. The same is MUCH harder to say on Android. And the tooling does nothing to help this.
And the IDE is also the least mature looking and feeling. Ideally, Google would simply release their own IDE with their own SDK instead of bolting their SDK onto Eclipse. Eclipse is nice, but it is a moving target and probably a large part of the problem.
But Google may never do such a thing. Because the whole point of this post was... they don't need too. People will deal with it because they feel that they need to. And maybe they feel they need to because that platform has the biggest share. Or maybe they feel they need to do that because it is the phone sitting in their pocket and they'd be a fool not to target their own device. Might makes right. Sadly, Google devs are forced to deal with inferior tools because people feel they need to target Android and better or worse tools aren't likely to change that.
As to how we got here. The tools are only bad relative to what is available now. Back when Android first came out, the SDK was no worse than what was dominating the market at the time. BlackBerry's SDK wasn't any better. I'm not sure what early iOS SDK's looked like, but I imagine they were a far cry from where they are today and when Android came out iOS wasn't dominant yet. And Windows Phone didn't exist. So the tools were considered good back in the day and they built a base back then and they simply haven't markedly improved and fell behind.
Microsoft improves its already fantastic Visual Studio IDE on a regular basis.
Apple improves their development suite (if at a slower pace). And even goes so far as to toss in new programming languages in an attempt to resolve things for its developers.
Google on the other hand doesn't seem to care how terrible their suite of tools is. And they don't really need to. They have the monopoly on mobile devices. People will target Android, whether they use Google's tools or not (those in the "or not" camp are typically using cross platform tools/tech).
Oddly, my favourite part of the conference was the part around Appurify. This is a great service, but ultimately one which shouldn't be needed. And Android is truly the only platform out of the top 3 (or even top 4) where such a service would ever be necessary. Apple's hardware is WAY too constrained for such a service to be justified. Windows Phone hardware is more limiting, but the platform is also much more heavily structured.
On the other hand, I wouldn't be surprised to find a toaster that run Android.
But hardware fragmentation, and even OS fragmentation aren't really the problem.
Even where a software runs on a device that should be supported by Android and leverages only valid API's for that device it can still behave differently than it does on another device that meets that same criteria. And while I cannot promise the opposite is globally true across iOS and Windows Phone devices, the reported occurrences are far lower. To the point where I've only ever heard of such occurrences on faulty devices.
And that is just the runtime. A bad runtime can bite even developers who write good code. A good runtime runs reasonably consistently across supported devices. I'm sure Google is putting in effort here on an ongoing basis. But, at least for older devices or devices which aren't officially updated to the latest software (which is appears to be a large percentage of devices) those efforts don't really end up helping.
But, probably the bigger problem is that modern applications are fairly complex. They have user interfaces and need to respond to touch commands which are difficult to interpret some times. They may need to respond to virtual keyboards and gestures. They may need to read input from a variety of sensors including gyroscopes and accelerometers. They need to deal with potential connectivity issues from potentially multiple sources (cellular data vs. WiFi). They may be sensitive to changes in transfer speeds (move from an area with LTE coverage to an area with only 3G coverage to an area with none).
Even a simple mobile app is often not a simple mobile app. And this is the reason that your development tools are such a big deal for developers. You need emulators that function and function like a normal device. You need the ability take your testing from an emulator and to a real device and then debug remotely as well. This was probably this biggest gripe I experienced and heard from others as well. The emulators are a pain in the butt to setup and, once setup, often fail to even load. And since I've never seen a functional Android phone fail to boot, the problem is with the tools.
Honestly, what they need the emulator to do is supply profiles that match known devices. I would say, take one or two flagship phones from each iteration, then lump in 1 or 2 of the most popular devices from both the mid and low end for each iteration instead of providing an emulator that allows you to tweak arbitrary specs. I don't really care my app runs on a phone with 11MB of RAM for instance... it isn't a possible configuration. It's cool that I can do it. But it doesn't make the broken ass emulator work any better and it doesn't allow me to emulate a practical device. So it is functionally useless.
You also need the ability to know what you're targeting. As with iOS or Windows Phone you can choose a compatibility level. But the difference is, I can rather safely say where to draw the line to get my appropriate mix of market share and API availability. The same is MUCH harder to say on Android. And the tooling does nothing to help this.
And the IDE is also the least mature looking and feeling. Ideally, Google would simply release their own IDE with their own SDK instead of bolting their SDK onto Eclipse. Eclipse is nice, but it is a moving target and probably a large part of the problem.
But Google may never do such a thing. Because the whole point of this post was... they don't need too. People will deal with it because they feel that they need to. And maybe they feel they need to because that platform has the biggest share. Or maybe they feel they need to do that because it is the phone sitting in their pocket and they'd be a fool not to target their own device. Might makes right. Sadly, Google devs are forced to deal with inferior tools because people feel they need to target Android and better or worse tools aren't likely to change that.
As to how we got here. The tools are only bad relative to what is available now. Back when Android first came out, the SDK was no worse than what was dominating the market at the time. BlackBerry's SDK wasn't any better. I'm not sure what early iOS SDK's looked like, but I imagine they were a far cry from where they are today and when Android came out iOS wasn't dominant yet. And Windows Phone didn't exist. So the tools were considered good back in the day and they built a base back then and they simply haven't markedly improved and fell behind.
Comments
Post a Comment