

So here is the issue with Android - pospischil
http://www.fakesteve.net/2009/10/so-here-is-issue-with-android.html

======
martythemaniak
"Now imagine you're an app developer."

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).

~~~
kogir
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.

~~~
hackoder
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.

~~~
angelbob
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.

~~~
buster
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.

------
buster
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.

~~~
hackoder
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.

~~~
bioinformatics
That's because he's the fake CEO of fake Apple.

~~~
hackoder
I got that. Its just irritating when someone who's not an authority in an area
pretends to be one.

------
drp
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.

------
vchakra
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.

------
kogir
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.

------
haseman
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.

~~~
pospischil
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?

~~~
haseman
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. :-)

------
pospischil
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)

~~~
jsankey
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).

~~~
kogir
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.

~~~
jsankey
_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.

