So here is the issue with Android(fakesteve.net)
fakesteve.net
So here is the issue with Android
http://www.fakesteve.net/2009/10/so-here-is-issue-with-android.html
7 comments
Apple and Google have brought a lot of new people into our industry. There's going to be a learning curve, and it's going to be painful for all of us at first.
Forgive me, but do you work somewhere where you have access to what's coming down the Android pipeline? You're in for an unpleasant surprise.
Most of the devices I've seen are great by themselves. If I played with one in a store I'd want it. But as a group, when they're what my company has to target for distribution, things could get really ugly.
Most of the devices I've seen are great by themselves. If I played with one in a store I'd want it. But as a group, when they're what my company has to target for distribution, things could get really ugly.
How? Android 1.6 seems to provide enough features for abstracting away the differences between current and near-future devices.
Practically; I was an early adopter for the HTC Magic. Despite that, all the apps designed for the G1 worked fine. I could even use Emacs in ConnectBot (ssh client) with the soft keyboard. Now that's abstraction!
Practically; I was an early adopter for the HTC Magic. Despite that, all the apps designed for the G1 worked fine. I could even use Emacs in ConnectBot (ssh client) with the soft keyboard. Now that's abstraction!
I dont see why it would be hard to change the screen resolution on the fly, kinda like what desktop games do. Other apps can use fluid layouts to fit multiple resolutions.
When it comes to other features of the phone, e.g. camera or accelerometer, like one of the posters said- you'll have to do progressive enhancement. Intelligent web developers already know how to do this. You feature test, then you enable a particular feature. Its not all that difficult.
When it comes to other features of the phone, e.g. camera or accelerometer, like one of the posters said- you'll have to do progressive enhancement. Intelligent web developers already know how to do this. You feature test, then you enable a particular feature. Its not all that difficult.
Fluid layouts are a reasonable compromise, but they mean a layout that's slightly "off" in many cases. Look at how GTK+ scales on different mobile devices, for instance.
It works, but it means giving up a lot of control, and the results tend to show it.
It works, but it means giving up a lot of control, and the results tend to show it.
forgetting the fact that GTK is quite some years old and software has evolved. You really think it's impossible to have a scalable UI? Ever surfed the internet with different resolutions? Now imagine you don't have cross browser incompatibilities and a framework that behaves the same everywhere.
What a stupid post of someone who obviously doesn't know a bit of android app development.
The UI widgets are done through XML (not unlike you do HTML for the browser). And guess what: Browsers can display the same webpage on totally different resolutions and be navigated by keyboard, mouse or whatever you want.
It's quite the same for Android. You do the layout in XML, Android scales it and puts it how it fits. This works pretty well.
Second: In general every widget, button, whatever can be access by touch or buttons. There is even an android phone without a touchscreen. This list goes on and on.
One part of why android is a great platform is that it is designed from scratch to be a _modern_ mobile operating system and the developers took care of a lot of cases. Unlike some other operating systems, it's new and especially designed for modern hardware (now, look at windows, symbian, and i am wondering how mac osx would perform on a variety of devices...)
Another example. As a developer you want to have the geographical position of the phone: Easiest way to do is ask for it, regardless of it coming from GPS, WLAN or GSM cell info. But you can also put criteria in the exact same function call if you want exact positioning (say, GPS but von WLAN). Of course, if there is no geo information available the call will tell you this and you have to take care of it. But you'll have to do that anyway, because GPS/WLAN/cell info is not available everytime on a capable device. This goes on and on in the whole framework.
Last but not least: Afaik, neither iphone apps nor windows mobile nor symbian apps will run on a different CPU architecture. Android apps use a VM and can be just run on every architecture the VM runs for. Switch from ARM to x86? No problem, take the same app (not two versions compiled for two different architecures) and they will run just fine.
It's quite shocking that someone writes such a post. It doesn't look like he has even read 1 page of information about android, yet he spreads bullsh. A shame this is posted on YC, too.
It's quite the same for Android. You do the layout in XML, Android scales it and puts it how it fits. This works pretty well.
Second: In general every widget, button, whatever can be access by touch or buttons. There is even an android phone without a touchscreen. This list goes on and on.
One part of why android is a great platform is that it is designed from scratch to be a _modern_ mobile operating system and the developers took care of a lot of cases. Unlike some other operating systems, it's new and especially designed for modern hardware (now, look at windows, symbian, and i am wondering how mac osx would perform on a variety of devices...)
Another example. As a developer you want to have the geographical position of the phone: Easiest way to do is ask for it, regardless of it coming from GPS, WLAN or GSM cell info. But you can also put criteria in the exact same function call if you want exact positioning (say, GPS but von WLAN). Of course, if there is no geo information available the call will tell you this and you have to take care of it. But you'll have to do that anyway, because GPS/WLAN/cell info is not available everytime on a capable device. This goes on and on in the whole framework.
Last but not least: Afaik, neither iphone apps nor windows mobile nor symbian apps will run on a different CPU architecture. Android apps use a VM and can be just run on every architecture the VM runs for. Switch from ARM to x86? No problem, take the same app (not two versions compiled for two different architecures) and they will run just fine.
It's quite shocking that someone writes such a post. It doesn't look like he has even read 1 page of information about android, yet he spreads bullsh. A shame this is posted on YC, too.
Pseudo-experts seem to be everywhere, and they're making it that much difficult to pick out people who actually know what they're talking about. So much noise...
You're absolutely correct that it seems like this person hasn't built a single android app.
You're absolutely correct that it seems like this person hasn't built a single android app.
That's because he's the fake CEO of fake Apple.
I got that. Its just irritating when someone who's not an authority in an area pretends to be one.
It's Fake Steve Jobs. I imagine it's a little tongue-in-cheek...
Actually i just saw that it's fake steve, that changes the intention i thought he has quite a bit.
Nevertheless, i don't want to know how many iPhone lovers will now look down (even more) on Android that, imo, is the best mobile platform out there, from a technical point of view (i'm not talking about ugly underpowered devices or the ugly standard theme, but the architecture). Don't know much about Palm Pre, though.
Second point: Most of the comments in the story now say "yeah, that's what killed Windows Mobile".. Errr, fine. But i am wondering how Nokia became world leading mobile manufacturer with a freaking lot of devices? It sure has nothing to do with screen resolution. It's just sad.. and as always i'm falling for the trolls :(
Nevertheless, i don't want to know how many iPhone lovers will now look down (even more) on Android that, imo, is the best mobile platform out there, from a technical point of view (i'm not talking about ugly underpowered devices or the ugly standard theme, but the architecture). Don't know much about Palm Pre, though.
Second point: Most of the comments in the story now say "yeah, that's what killed Windows Mobile".. Errr, fine. But i am wondering how Nokia became world leading mobile manufacturer with a freaking lot of devices? It sure has nothing to do with screen resolution. It's just sad.. and as always i'm falling for the trolls :(
How are these complaints really different from developing desktop software? Remember those little "system requirements" blurbs that use to be on the sides of software boxes when people actually went to stores to buy physical media with software on it? Developing for any platform is hard and having to deal with missing or inadequate hardware has always been a stumbling block.
Desktop applications have shifted to the web. It's only a matter of time before mobile apps are also obsolete.
Desktop applications have shifted to the web. It's only a matter of time before mobile apps are also obsolete.
It would have been a good argument, until you try to use the capture current photo image on the iphone and then realize it wont work on the ipod touch. Or the compass features (for augmented reality) and find out you are out of luck on older iphones.
Form factor is only one problem. At work I've seen a couple not yet released Android phones, and each OEM feels the need to customize Android itself. One even modified the maps API to be incompatible with the G1/myTouch. Others replace all the built in UI controls.
I'd like to think that users and carriers were smart enough to realize this is bad, but I've seen this before: Android, meet J2ME. You share more in common than you know.
I'd like to think that users and carriers were smart enough to realize this is bad, but I've seen this before: Android, meet J2ME. You share more in common than you know.
Mobile software is hard.
At our company (small mobile software shop) we currently have ant scripts that churn out builds for over 100 devices with at least 10 different screen sizes and many different input methods touch/dpad/trackball. On one binary. These things can be done, it just takes work.
At our company (small mobile software shop) we currently have ant scripts that churn out builds for over 100 devices with at least 10 different screen sizes and many different input methods touch/dpad/trackball. On one binary. These things can be done, it just takes work.
No question about it -- and yes, its hard work.
Your in a great position to answer the LCD question then -- I imagine some of the phones you are targeting have features that others don't. And some of those features, in the higher end phones, would be useful in your applications. So, do you just ignore them, or do you spend resources building some features that will only be beneficial to a subset of your users?
Your in a great position to answer the LCD question then -- I imagine some of the phones you are targeting have features that others don't. And some of those features, in the higher end phones, would be useful in your applications. So, do you just ignore them, or do you spend resources building some features that will only be beneficial to a subset of your users?
The unhelpful answer is: it depends.
Obviously, you should design your application to reach as many people as you can with a core set of functionality. For us, this means passing on possibilities that work only on a small set of devices. (Unless that small pool can generate enormous revenue)
Further, we add nice-to-have features to our core app that can be switched on and off at build or run-time by our QA team depending on the device.
Sorry I can't be more specific. If you're looking for more information feel free to email me. :-)
Obviously, you should design your application to reach as many people as you can with a core set of functionality. For us, this means passing on possibilities that work only on a small set of devices. (Unless that small pool can generate enormous revenue)
Further, we add nice-to-have features to our core app that can be switched on and off at build or run-time by our QA team depending on the device.
Sorry I can't be more specific. If you're looking for more information feel free to email me. :-)
A few of us were discussing this today/yesterday -- in regards to whats wrong with android.
What I am wondering is -- how does Google, et. al. avoid the "Lowest Common Denominator" problem. Or are they doomed?
(My opinion? doomed as far as apps are concerned)
What I am wondering is -- how does Google, et. al. avoid the "Lowest Common Denominator" problem. Or are they doomed?
(My opinion? doomed as far as apps are concerned)
We work around this problem with our own XML runtime parsed UI Library. It lets us have a set of layout files for each screen size of the application. Since we've implemented it for almost every platform out there, it means I'm mostly writing application logic. (Which has it's own set of pitfalls)
As much as I hate buzzwords, it really helps to take an MVC approach to mobile development. Different screensizes and input methods just require different views on top of the application logic.
As much as I hate buzzwords, it really helps to take an MVC approach to mobile development. Different screensizes and input methods just require different views on top of the application logic.
I think people will manage just fine without a company dictating one, and only one phone specification for everyone to use for all purposes.
You avoid this problem by not restricting APIs to what works on every phone, but providing optional APIs for the more capable devices. Good apps will be well integrated with multiple devices - where those devices have enough market share to be worth targeting.
The alternative of only having one device to rule them all is unrealistic. It's a kind of lowest common denominator approach to matching users to phones (as opposed to matching apps to phones).
The alternative of only having one device to rule them all is unrealistic. It's a kind of lowest common denominator approach to matching users to phones (as opposed to matching apps to phones).
J2ME does just what you suggest. They're called JSRs. I know from experience that doesn't work, because even if the platform doesn't target the lowest common denominator, app developers will out of necessity.
It's too expensive to optimize for every device. It all sounds great until there are multiple extension APIs to access the same thing, all of which are subtlety different and none of which are common across OEMs.
What's even worse is when the API is shared, but each OEM implements it differently. For instance, one OEM's phones regularly return pictures rotated 90 degrees clockwise.
Each problem by itself seems small, but combined they're formidable.
It sucks for users too. They may hear that app X is awesome from a friend, only to find that the same app sucks on their own phone.
It's too expensive to optimize for every device. It all sounds great until there are multiple extension APIs to access the same thing, all of which are subtlety different and none of which are common across OEMs.
What's even worse is when the API is shared, but each OEM implements it differently. For instance, one OEM's phones regularly return pictures rotated 90 degrees clockwise.
Each problem by itself seems small, but combined they're formidable.
It sucks for users too. They may hear that app X is awesome from a friend, only to find that the same app sucks on their own phone.
It's too expensive to optimize for every device.
Agreed. The "solution" I suggest just allows you to avoid the lowest common denominator - it doesn't make it cheap, or even viable for all devices. But for the most popular devices it should be economical. I guess it depends on how fragmented things get - but I don't think a phone monoculture is any kind of solution, it just shifts the problem.
Agreed. The "solution" I suggest just allows you to avoid the lowest common denominator - it doesn't make it cheap, or even viable for all devices. But for the most popular devices it should be economical. I guess it depends on how fragmented things get - but I don't think a phone monoculture is any kind of solution, it just shifts the problem.
That might solve the problem for great apps -- but lets face it, a lot of the apps we see in the app store(s) out there aren't great. Which phones are end-users going to buy? The ones with cool features that no apps use, or the cheaper one that runs all the same apps as the high end phone?
And it doesn't solve the different resolution problem....
(Just playing devils advocate here -- your strategy is basically what apple has done w/ iPhone 1, 2, 3--and has been quite successful thus far. But had apple built a dozen phones in that time frame I don't think things would be playing out the same way).
And it doesn't solve the different resolution problem....
(Just playing devils advocate here -- your strategy is basically what apple has done w/ iPhone 1, 2, 3--and has been quite successful thus far. But had apple built a dozen phones in that time frame I don't think things would be playing out the same way).
I am actually an android app developer and some of the comments here make me question how many others actually are, versus relying on second-hand bullshit.
While it's slightly harder than developing for a single device, it is quite manageable. Some examples:
- different screen resolutions: this means that you must rely on UI layouts or make your pixels in your graphics code relative. This is an issue the iPhone will have in the future as well, as they WILL eventually upgrade the resolution on that screen.
- different input methods: make sure both gestures/swipes/touches and key presses both map to the correct functions
- missing features: accelerometer, cameara, etc: check and Handle gracefully or refuse to work. iPhone developers have to deal with this as well, except they can only refuse to work (by specifying minimum OS version to install).