
A few days of programming on iOS and Android illustrates a vast difference. - ssutch
https://plus.google.com/108681339647207923208/posts/hGaprZk9FC9
======
bendmorris
Counterpoint: I just began developing my first Android app a few days ago, a
turn-based strategy game. I've only had an Android device for a month or so so
the platform is relatively new to me, and I didn't even know Java (although,
to be fair, I knew C# fairly well a couple years ago, which is arguably the
same thing plus type inference.) In a few days, with relatively few problems,
I was able to build an app and I'll be releasing it in various markets soon
(once I stop polishing and let it go, which is hard for me to do.)

I found the experience to be straightforward and intuitive. I was able to find
tutorials for any task I couldn't figure out myself and the API documentation
is perfectly adequate. Working with images and settings files are two areas
where I was very pleasantly surprised at just how easy it was.

There were some minor frustrations. The Android emulator fought me a little so
I started just debugging on my actual device. Debugging certain problems can
be difficult, Eclipse can cause headaches and throw random nonexistent
exceptions, etc. but overall I think you've vastly overstated the difficulty
level of jumping into Android development. "The depth of knowledge of in
design patterns required is so great..." It's really not. With almost no
experience with Java or Android, I've put together a working app in a few days
that, in my opinion at least, is pretty good, and that works on various mobile
devices with different resolutions and capabilities.

Some other things I'm happy with about the Android platform: the SDK is free,
Android is open source, you're very unrestricted with regards to what your app
can do, and Android Market developer accounts cost a one time fee of $25
instead of $100 a year.

~~~
SomeCallMeTim
I'm a long-time game programmer, and not at all an Apple fan (somewhat the
opposite, in fact). When I picked up Android I really, really wanted to like
it.

Every time I turned around, the Android platform surprised me. In a bad way.
Full disclosure: I'm also not a Java fan, and think it was a completely brain-
dead idea to make Java the first-class API. I'm certainly not a Microsoft fan,
but even C#/Mono would have been better (not that I know any C#), if only so
they wouldn't have had to waste time reimplementing the VM for licensing
reasons. But it's not Java that I had a hard time with.

I've developed games on 12 different hardware/software platforms. There are so
many things missing and/or broken about the way Android does things that I
feel embarrassed for Google. Some of those things have subsequently been
fixed, but many haven't, and some have been ignored in the bug database for
YEARS now. A LOT of those things wouldn't have been problems if they didn't
have so many layers between the app and the hardware (Java being one of those
layers, but not the only problem).

As you say, it's really Not That Hard to just throw a simple app together that
does what it needs to. Intents and Services are also ABSOLUTELY not the
problem. The developer who wrote the original article didn't read enough of
the docs or the right docs, or isn't as smart as he thinks he is -- the
concept of Intents is not rocket science. The application lifecycle isn't even
hard to understand -- it's laid out in the intro docs pretty clearly.

If only Android actually DID what those docs said, things would be a lot
easier for a game developer. In fact, an "app" can be stopped and then a new
one started before the old one actually receives its shut-down message. In the
same (Linux) process -- so any native code with static data is still sitting
around. One of many annoying problems I ran into.

I think the core mistake of almost every new platform is one of ego. "We'll
design this NEW AND DIFFERENT platform in some revolutionary and awesome way,
and make everyone rewrite their apps in this way feel is Better." When dealing
with platforms, the one most important thing to do, in my opinion, is to HIDE
the differences between one and another platform as much as possible. Android
does this to some degree WITHIN the Android ecosystem, but we simply DON'T
NEED multiple ecosystems. I submit it would be better for everyone if there
were a single cross-platform engine that everyone used. Before I get dismissed
as a kook, please think about OpenGL, and the fact that something as complex
as a rendering subsystem IS in fact supported on all platforms, to everyone's
benefit.

What would have been better is a library that abstracts away the fact that
Android is its own unique OS, period. When I write code, I don't want it to be
Android code, or iOS code, or WebOS code, or Windows [Mobile] code, or Linux
code. I want it to be, as much as possible, completely cross-platform. I want
the platform to fade into the background. You could bootstrap this by creating
all the UI and other OS code as a portable layer that can run on many
different systems.

But no new platform developer ever seems to get that, and so we end up with a
new ecosystem for every new platform, and it's left to third parties to fill
in the gap with cross-platform libraries. But it's not the developers -- or
the users -- that big initiatives like Android get funded to satisfy.

/rant

~~~
MichaelEGR
@SomeCallMeTim >I submit it would be better for everyone if there were a
single cross-platform engine that everyone used.

>What would have been better is a library that abstracts away the fact that
Android is its own unique OS, period. When I write code, I don't want it to be
Android code, or iOS code, or WebOS code, or Windows [Mobile] code, or Linux
code. \---

There are options out there. I'm one of those 3rd parties soon releasing a
comprehensive middleware solution for app dev including a lot of game dev
oriented effort that provides a clean abstraction layer via a component
architecture that uses a large majority of advanced Java language features
under the hood without sacrificing performance.

Keep a watch out for TyphonRT; drop me an email via the contact address and
I'll be glad to discuss more and make sure you get early access. I'm aiming to
get it out ASAP and before I give an all day game dev workshop at AnDevCon II
in November. I suppose one thing that makes TyphonRT unique is that it's a
tool, framework, and future platform (PaaS). At the heart of things you can
pick and choose individual blocks of functionality (tool), or utilize the
runtime framework (framework), and soon there will be optional PaaS features
aiding Android and cross-platform dev in the coming year after launch.

Another Java based cross-platform effort which is similar in purpose though
significantly different at the architecture level is libgdx. For C/C++ check
out Battery Tech and the Proton SDK for similar cross-platform efforts (both
of these with even more device coverage).

TyphonRT provides that layer of sugar you seek without losing performance and
creating full cross-platform execution for OpenGL apps without changing a line
of code for J2SE -> Android. TyphonRT is not limited to OpenGL though and can
utilize any graphics API potentially allowing a hybrid UI, but the rest of an
app still being cross-platform.

Having worked intensely with Android since v1.0 and the G1 hit my hands in Oct
'08 I have more than a few stories on the difficulty of low level development
/ games, etc. across different OS and major device hardware generations. I've
experienced first hand a good deal of general engineering blunders and have
found and reported a few major ones myself (you know when big G fixes a bug
immediately upon being reported you found a good one; the 3.0 & 3.1 / NIO
immutable endian swap issue comes to mind!).

Middleware will mature and soon provide a lot that the Android SDK lacks for
certain app development areas. In many ways the Android SDK while novel in
several areas is still being developed from an old engineering model, but that
is seemingly unavoidable for a large organization such as Google. There are of
course additional inherent problems with tying the SDK to firmware, but such
is life.

I do agree with your last point though that generally the SDK in addition to
the particular ecosystem quirks that have occurred over time isn't exactly
indicative of satisfying developers.

~~~
SomeCallMeTim
Thanks, but I guess I didn't get across how much I still hate Java. ;) I feel
it has 95% of the problems of C++, without the advantages (predictable speed,
mostly). I'm sure your platform will be useful for anyone porting J2SE code to
Android, but that's not me. And it doesn't look like you're supporting iPhone?
That's a huge chunk of the market still.

I know that middleware providers will step in to fill in the gaps, but it's
just annoying to be non-native on ALL platforms. And there are already a lot
of options.

<http://www.batterypoweredgames.com/batterytech> is one that I know that's low
level, for instance -- it gives you events, OpenGL and sound on Windows, Mac,
iPhone, and Android. It's pretty bare-bones, though, as far as I know.

There are also stacks that allow you to write in JavaScript [1][2], 3d engines
[3][4][5], and one that I just found out about one that sounds really awesome,
though I haven't used it yet called Moai [6]. Moai is Lua-based, open source,
supports iPhone and Android, and has a Lua-based cloud server component, so
you can write in the same language for your game and for the server side in
multiplayer games.

If I haven't been clear, I think Lua IS an awesome language, especially now
that LuaJIT 2.0 works on Android (and at least partly on iPhone), and so I'm
strongly considering using Moai for my next game.

I actually already use Lua on the server side, though I'm using a different
stack than Moai (they're on Mongrel2/Tir, and I'm using Nginx with lua-nginx).

[1] <http://www.sencha.com/> [2] <http://www.phonegap.com/> [3]
<http://www.stonetrip.com/> [4] <http://unity3d.com/> [5]
<http://irrlicht.sourceforge.net/forum/viewtopic.php?t=37235> [6]
<http://getmoai.com/>

~~~
MichaelEGR
>Thanks, but I guess I didn't get across how much I still hate Java. ;)

Can't solve that.. ;) ;)

>I feel it has 95% of the problems of C++, without the advantages (predictable
speed, mostly).

I suppose you'd have to get a little more particular in the 95% of problems
angle. I have been working with Java for quite some time and TyphonRT contains
necessary workarounds or API extensions enabling predictable speed. For
instance TyphonRT being a Java based component architecture is highly
dependent on iteration over collections of components. The custom collections
API in TyphonRT has recycled and resetable iterators overcoming the "iterator
problem" of the standard collections API. There is a bit more of other things
done too to provide predictable runtime performance. A lot of that involves
staying as memory efficient as possible and not triggering GC. Of course when
things get too hairy yeah native code is used. One has to do that for physics
engines (Box2D / Bullet) especially on Android. I'm really loving JavaCPP
which is a relatively new effort for managing native bindings
(<http://code.google.com/p/javacpp/>).

>I'm sure your platform will be useful for anyone porting J2SE code to
Android, but that's not me.

If you are most familiar with C/C++ certainly by all means go with that and
the NDK and use BatteryTech, Proton SDK, or something like that to provide the
core cross-platform architecture support.

>And it doesn't look like you're supporting iPhone?

Not yet, but just like Unity which you mention cross-compilation is not out of
the question. Like libgdx once the main framework is mostly finalized I'll be
looking at say an Angle backed for the desktop and / or other options for
expanding device and environment support. The primary goal is to create a
leading edge Java framework / platform first. The platform / PaaS aspects also
are a priority in the short term among many other things like strong Scala
support / integration over say iPhone support. A thing to keep in kind too is
that TyphonRT is not just aimed at game dev, but is applicable for all dev
efforts including enterprise.

So yes, if you need cross-platform support go native or use a canned 3D engine
like Unity if it matches the type of game you are trying to make.

>I know that middleware providers will step in to fill in the gaps, but it's
just annoying to be non-native on ALL platforms.

Hrm? C / C++ is available on the majority of platforms... ?

><http://www.batterypoweredgames.com/batterytech> is one that I know that's
low level, for instance -- it gives you events, OpenGL and sound on Windows,
Mac, iPhone, and Android. It's pretty bare-bones, though, as far as I know.

Yes it's not a complete game engine nor is Moai which you mention you have
your eye on presently. BatteryTech, libgdx, and TyphonRT provide the core
architecture to abstract the common requirements (input, audio, etc.) for real
time apps & games. TyphonRT also has higher level optional components for game
dev including a fully featured component oriented entity system (libgdx /
BatteryTech, etc. don't). This class of tech is meant for folks that can build
their own engines and perhaps their own creative games rather than trying to
force canned engines to do things they are not great at doing. As mentioned
though there are optional components with my efforts to further assist game
dev efforts beyond core architecture abstractions.

Regardless of what you choose though I hope you make some cool games for
Android! :)

~~~
SomeCallMeTim
>>I feel it has 95% of the problems of C++, without the advantages
(predictable speed, mostly).

>I suppose you'd have to get a little more particular in the 95% of problems
angle.

Hmm...getting very much off topic here, so I want to keep this brief, but
roughly speaking I'm talking about the problems of the language being very
verbose and missing a lot of useful features: no duck typing (C++ at least has
templates, which have their own drawbacks -- Java generics need to be Object-
derived), no coroutines, and no first-class functions are three examples that
come to mind. Just look at the size of programs in the "Language Benchmark
Game" -- Lua's entries are tiny compared to Java. Call me lazy. ;)

In addition, in Java you HAVE to force everything into an object paradigm,
whether it makes sense or not. Lua can act object-oriented if you want it to,
but you can also use it in other ways that simply make more sense to the
problem at hand.

>Yes it's not a complete game engine nor is Moai which you mention you have
your eye on presently.

No implied criticism there. As you mention BatteryTech is also low-level.
There's a place for that.

For what it's worth, Moai does come with things like physics; not sure how
they bind things together, but I would have guessed that they have a very
basic engine with game objects. Could be wrong.

JavaCPP looks interesting, though I'm instead just minimizing my use of Java
so I can have a Windows and iPhone version trivially.

>>I know that middleware providers will step in to fill in the gaps, but it's
just annoying to be non-native on ALL platforms.

>Hrm? C / C++ is available on the majority of platforms... ?

Yes, but it's the API for getting events, putting up native dialogs, etc. that
will be non-native everywhere. On Android more so than usual.

And actually...C/C++ isn't currently supported on Windows Mobile, at least in
the public SDK, for what it's worth. Though C/C++ are supported on pretty much
every platform where the company behind it isn't being stupid, yes.

No implied criticism toward your project in general, by the way. It's just not
my thing, since I'm not a Java person. It does sound like you've solved a lot
of the problems that people often have with Java, though, which is great.

>Regardless of what you choose though I hope you make some cool games for
Android! :)

Thanks. :)

~~~
MichaelEGR
>Hmm...getting very much off topic here, so I want to keep this brief ... the
problems of the language being very verbose and missing a lot of useful
features

Yes, let's not belabor things, but I do want to point out that Scala
essentially covers all of the points you raised. It supports duck typing (type
safe too!), coroutines, first-class functions, and is more syntactically
elegant. Scala even supports a particular mechanism to "sort of" support
primitives w/ generics with the @Specialized annotation. So yes, I'm turning
to Scala to provide additional language features and it's especially cool
keeping type-safe aspects and being able to do joint compilation, so this
works well for desktop / J2SE & Android integration. Of course Scala on top of
the finely tuned TyphonRT / Java COP API and such is nice; more concise code
for sure; this in addition to having access to all of the Java and/or Android
SDK and 3rd party libraries. On the Java tip too regarding generics / Object
situation TyphonRT has primitive collections available as well which is the
main use case.

> Lua can act object-oriented if you want it to, but you can also use it in
> other ways that simply make more sense to the problem at hand.

I'd argue it's not a silver bullet as a primary language to write an entire
game / engine in w/ more discussion continuing along those lines; there seems
to be flexibility gained and lost. As a scripting engine that's one thing, but
not a catch all for everything.

The important part here though and hopefully this ties back in a little with
the OP and your concerns is that there are options available to take the edge
off of mobile dev Android or otherwise and things should radically change in
that regard in the next couple of years.

@seclorum is certainly correct that cross-platform mobile dev with OpenGL/ES
is not out reach at all and once the C/C++ or Java decision is made depending
on dev flexibility one can be creating rich content games not limited by a
particular mobile OS concern.

Ultimately you want to pick the tool you are most comfortable and proficient
with as in regard to indie game dev there are many other fish to fry let alone
the hit based nature of the current app stores.

>For what it's worth, Moai does come with things like physics; not sure how
they bind things together, but I would have guessed that they have a very
basic engine with game objects. Could be wrong.

From what I read Moai supports Box2D. You know who else supports Box2D;
everyone... BatteryTech, libgdx, TyphonRT, the list goes on, etc. etc. ;) It
does sound like there is a basic game object API in Moai, but it only is
geared towards 2D presently.

I know Robert of BatteryTech is doing a whole lot of Lua integration and work
with BatteryTech, so do take a 2nd look and drop him an email perhaps.

>JavaCPP looks interesting

Indeed.. It's the 1st JNI / native marshaling assistance API that I like that
takes the pain away of hand rolling JNI code. :)

>Yes, but it's the API for getting events

This is abstracted with most middleware mentioned. In fact input control is
the largest category of core architecture components in TyphonRT (almost 10%).

>putting up native dialogs, etc. that will be non-native everywhere.

Why would you do this if you are creating an OpenGL/ES cross-platform game?
Use a GL based GUI that will be cross-platform!

>It's just not my thing, since I'm not a Java person.

Fair enough hence why I'll stop posting on the thread! :) Though I did want
mention some responses on the off the top general criticisms at the front of
this reply. JVM languages will breathe some life into the Java sphere of
things. This in concert with well developed middleware will make a lot of
things that are hard now much easier soon enough.

It gets better.. ;P

~~~
SomeCallMeTim
OK, just going to answer a few points, to try to wrap this up. :)

>I'd argue it's not a silver bullet as a primary language to write an entire
game / engine in w/ more discussion continuing along those lines; there seems
to be flexibility gained and lost. As a scripting engine that's one thing, but
not a catch all for everything.

I write a lot of the core "engine" in C++ for speed and lack of garbage
creation. The game I've got on the Android market right now has about 3149
lines of C++ code specific to the game (not counting 7400 lines of auto-
generated Lua bindings), but 10k lines of Lua code. Most of the game code is
in Lua; is that scripting?

The engine itself has about 10k lines of C++ code, and very little Lua. I want
the engine to be as fast as possible, so it's hard for me to imagine doing it
in a language that isn't C or C++.

>>>putting up native dialogs, etc. that will be non-native everywhere. >Why
would you do this if you are creating an OpenGL/ES cross-platform game? Use a
GL based GUI that will be cross-platform!

Geting UI right is really, really hard. For the primary game UI, and dialogs
with buttons, sure, all of it happens in GL.

But if I want a list dialog, or a grid view, or a WebKit view, I'm not going
to want to do my own halfway implementation -- I'm going to want a dialog with
a native feel. There's no game anywhere that I've used that really gets
anything as simple as a keyboard entry field completely right, if it doesn't
use the native UI; there are some things better left to the UI experts.

A good friend of mine is a big Scala fan, but I haven't really explored it as
an option.

The thing that kills Scala for me (without knowing anything else about it) is
that most platforms I write for don't already have a guaranteed JVM -- iPhone
and Windows being big ones. I mean, sure you almost always have SOME JVM on
Windows, but I'd likely want to be shipping a specific JVM.

And that means adding multiple megabytes onto my package size. You've got 20Mb
on iPhone if you want to be able to download over the air. Adding 5Mb to
support a language...isn't an option.

LuaJIT takes up about 50k. With all its libraries. And performs on par with
Scala. Which is a huge win for me. How much overhead does Scala add to an app
on Android? I bet it's more than that, even with the guaranteed JVM (well,
DVM) preinstalled.

~~~
MichaelEGR
> OK, just going to answer a few points, to try to wrap this up. :)

And for the wrap up wrap up ;P

> I write a lot of the core "engine" in C++ for speed and lack of garbage
> creation.

Most definitely. That was all I was getting at is that the core engine should
be as fast as possible.

What game on Android Market BTW? Would be glad to check it out and support
yah! :)

> Geting UI right is really, really hard... But if I want a list dialog, or a
> grid view...

Indeed.. UI is hard though I'd say list dialogs and grid view is still GL
possible without too much difficulty given various tool kits. Yes a WebKit
view is difficult to pull off cross-platform presently. There are options like
Awesomium though I've yet to see it used on a mobile platform, however I'm
sure something will come up soon.

Yes.. a keyboard entry field depending w/ a GL UI in conjunction with say
popping up the default native UI keyboard for touch only devices is something
that would need to be fine tuned.

I plan to tackle general GL UI matters at a future point to offer a nicely
integrated set of optional components. You are right though it's generally
difficult.

For aspects in TyphonRT that require local / native peers the main application
container is loaded declaratively with a cross-platform interface component
backed by the proper native implementation, so from the devs perspective they
can just request the common interface and the platform specific aspects are
active behind the scene.

>... most platforms I write for don't already have a guaranteed JVM

Yes, for a desktop release it might be pertinent to distribute a private
stripped down JVM. For mobile.. Well.. It's not easily feasible or likely
allowed if I recall in the TOS to have a JVM on the iPhone. Cross-compilation
is the likely way to go if / when TyphonRT supports iOS.

>How much overhead does Scala add to an app on Android?

Yeah you got me there.. ;) If one uses the Scala standard library that jar
file is ~8MB. Whether that can be split up and paired down I'm not sure yet.
I'm close to starting on Scala integration (mind you this is optional w/
TyphonRT).

There are also platform aspects of TyphonRT that will reduce overhead for
multiple apps installed, but this gets into a bit more conversation here than
necessary; essentially though side-loading shared components installed by
other apps thus minimizing each app requiring a large download.

So yeah, some work and experimentation ahead. I'll definitely be working on a
minimum profile (if possible) for Scala integration.

------
shaunfs
Screw it, I'm psyched! It's a great time to be a mobile developer! I was going
to write a whole response regarding iOS vs Android until I realized the debate
is like religion or politics. Currently both platforms are great and only
getting better with each iteration. I'm developing for both platforms and
loving it. Just in the latest iterations look at what we can do.

iOS * AirPlay - My phone will be my gaming console and media center, genius! *
iCloud - Good, no more transferring files back and forth. * CoreImage &
AVFoundation - 30 lines of code to add video editing and filters to my
application, sounds good! * GLKit - High-level 3D libraries for a game
developer noob like me. I'm in! * TwitterAuth - I'm still going to integrate
FB authentication but this is cool too.

Android * Ice Cream Sandwich - No more fragmentation. Unifies hundreds of
devices (not just phones). Brand new UI library. I can't wait! * ADK - My
home, car, and toaster will soon be at my mobile command while giving me
status updates. This is so awesome! I foresee Android powered cleaning robots
in the future. * Face-tracking - So my phone can recognize me and focus in on
my face and voice automatically. This sounds like fun. * USB Host - I can plug
anything USB into my Android phone. Hot damn!

~~~
hahainternet
Here's my question. In this (somewhat ungrounded in Android reality) article
the poster makes the claim that on iOS, you 'just get' a few seconds to finish
off everything.

This does not seem like a sustainable model. If my app and the next app a user
launches are both memory heavy, I expect my app to be killed to make space.
How does this process work on iOS?

Also, nobody really seems to understand how amazing Intents are before they
use Android :)

~~~
jmelloy
You get notified when the user switches apps away from yours, so at that point
you quicky get your shit together and assume you could be killed at any time.

------
mahmud
Android is not a toy, you can easily see it's an improvement over traditional
mobile, and it highly influenced by the web.

I fought Android until I decided to throw my entire weight behind Java and
settled on it as a platform. Don't fight it: learn Java proper, do a few SWT &
Swing apps, feel the burn .. then do Android.

You can ignore the abstractions and just "draw up" your application with
Eclipse, inside one giant activity, but you would be doing yourself a
disservice.

I told myself "Java sucks, it's bloated, it's big, yada yada yada. Just man up
and learn it; no sense in bitching about what you don't know" :-) Glad I did.
It gets work done.

~~~
evinfinite
Just a point that needs clarification: how is any of this comment relevant to
the points raised in the OP? That is, how does this help against the fact that
Android has:

* A much more complex set of (good!) abstractions that are poorly documented;

* and, if I might add alongside the OP, requires a much higher workload in terms of code length and complexity, debugging, device configuration management and tools for what seems to be a much lower payoff?

I have a successful iOS app out, and I tried to rearchitect it in a manageable
way to port it on Android. What I found out is:

* The code would be roughly twice as much as the iOS version.

* A proper UI effort would require roughly 2.5x work than the iOS version, as I need to prep up a flexible layout that will work on phones (the buckets 'small' to 'large'), and then another for tablets (actually up to two: 'xlarge' and Honeycomb, which may require some rethinking to accommodate the new action bar). Contrast this to two, fixed-size layouts for the iOS version.

* I already have a path for implementing backgrounding on iOS and it requires minimal change to account for services not available while backgrounded; otherwise, code is exactly the same. On Android, I would have to plan for it from the beginning and set up very poorly documented IBinder stuff to have my Activities talk to a background Service.

* The general unwillingness of Android users in the face of paid apps, and a use model that does not lend itself easily to the insertion of ads, would make my (more costly) effort go unpaid.

I must admit I have never used resources other than developer.android.com and
Google, and the latter didn't help me as much as (as little as)
developer.android.com did. There might be an excellent book on all of this,
but I haven't bought any — any recommendations are welcome.

~~~
hahainternet
Could you give me an example of exactly _why_ the claims you've made are true?

Why would your app need twice as much code? Why is using the Android ui
designer so much harder than iOS's equiv?

What is so undocumented about IBinder? It's basic IPC?

I would really like to hear reasons, not abbreviations.

~~~
tolmasky
Although not having used Android specifically, I can easily see the UI
designer being poor compared to iOS's. I still have yet to see anything as
good as Interface Builder for any other platform, and I think a lot of it just
boils down to the fact that when IB was designed it was actually considered to
be "the right way" to make pieces of your app from the beginning, as opposed
to something bolted on later. Making a nib less app is really hard in Cocoa. A
lot of stuff in Cocoa/Touch just makes more sense from a UI builder
perspective than a hand-coded perspective. The new constraints API which is
absolutely awesome is a good example of this for desktop Cocoa, and the
storyboarding stuff is a good example for Cocoa Touch.

~~~
koko775
Moreover, Interface Builder's file format is quite literally a serialized
version of the class constructed at runtime, as configured in Interface
Builder. What can be done in IB can also be done in code, which is more than I
can say for Android's xml.

~~~
hahainternet
What do you mean it's more than you can say? Android's system is precisely the
same. To build an Activity you set up and extend Views using the ViewGroup
function 'addview'

[http://developer.android.com/reference/android/view/ViewGrou...](http://developer.android.com/reference/android/view/ViewGroup.html#addView%28android.view.View,%20int,%20android.view.ViewGroup.LayoutParams%29)

I actually use this to inflate a series of layouts, and then to arrange them
inside an existing layout dynamically.

~~~
koko775
No, there are methods and settings that can be set via code that cannot be set
via the XML, and vice-versa - I'm not talking about mixing them together. Yes,
they are the same classes. No, they are not created and instantiated and
configured in exactly the same fashion; there are occasionally differences.

~~~
hahainternet
Such as? I don't mean to carry on an endless comment thread but I don't quite
understand what you're talking about.

------
hackbod
"For example, to correctly implement asynchronous HTTP requests is an entirely
different challenge in iOS and Android. On iOS you use the built in libraries,
and if your user happens to change applications during the request, you can be
sure you have up to 30 seconds, usually more, to complete whatever actions
need done before termination. On android, you must implement the
`android.app.Service` API for all your important web calls. The app can be
killed at any time, and you must retain your arguments, and retry the call in
case it happens to die."

Except... no, you don't. :/

The first sentence of the documentation on Service: "A Service is an
application component representing either an application's desire to perform a
longer-running operation while not interacting with the user or to supply
functionality for other applications to use."

Do you need to do either of those things? If you say no, then don't use
Service.

[http://developer.android.com/reference/android/app/Service.h...](http://developer.android.com/reference/android/app/Service.html)

In the Processes and Threads documentation:
[http://developer.android.com/guide/topics/fundamentals/proce...](http://developer.android.com/guide/topics/fundamentals/processes-
and-threads.html)

It describes how when the user leaves the activity in a process, it goes in
the background. It doesn't kill the process. You can continue doing
networking. You don't need a Service to have background threads in your
process. (In fact again from the Service documentation, a Service is not a
thread at all.)

Just continue doing your work, and if the system needs your RAM for other
processes, it will kill your process, but otherwise you can continue
downloading in the background.

This is exactly how for example the web browser, and any app using a WebView,
works.

This is similar in many ways to iOS. Not surprising, iOS seems um inspired in
its multitasking design by Android.

------
zyb09
Well you're new to Android so things seem weird at first. It's all a matter of
picking up the underlying concepts. To be fair ObjC and Cocoa looks for most
Java devs like voodoo, but once you get it it becomes easier, too.

~~~
dpcan
Exactly. This article was completely one-sided.

He also failed to see the huge amount of community support there is for
Android developers too. There's so much information inside multiple forums you
would almost never be unable to find an answer to a problem.

~~~
mirkules
There's an insane amount of support for both platforms. Without StackOverflow,
50% of the developers would be unemployed :)

------
jan_g
I mostly agree with the blog post. It is perhaps too hard to make proper app
in Android, but all those abstractions are powerful, imho. Consider quick
search/suggestions. If done properly, then you can plug your implementation
also to system-wide search with just some config changes (and user permission,
of course). Sure, content providers seem far too difficult (search dictionary
example in dev docs), but then you can reuse them for your list activity or
quick search or access them from another app.

------
jinushaun
My problem with Android development is that, being a non-Java developer, I
never knew when to use the Android SDK or the Java SDK or the Apache stuff for
certain tasks. For example, networking. Googling online for solutions, I don't
know if any of the Java code I find is Android compatible.

~~~
babebridou
My rule of thumb: \- if you see "java.awt" or "javax.swing" in any package
import, run away. \- if you need to download a native library to run a hello
world, run away too.

The rest is/should be fair game. Try to run a hello world on the device.

~~~
DannoHung
Is there a good library for doing graphics in Java? I was thinking about
trying processing, but it doesn't seem quite appropriate.

~~~
babebridou
What kind of graphics? \- for charts on android,
<http://code.google.com/p/afreechart/> \- for maths calculations,
<http://commons.apache.org/math/> \- for opengl graphics on android, it's
already a pain with all the fragmentation here. There's OpenglES10 (but no
longer implemented on Xoom), OpenglES20 (2.2/2.3 and up, but no VBO support on
2.2), Renderscript (3.0 and up), JNI (if you want to program in C),
MonoAndroid (for mono, you need to pay for that though)... \- otherwise, just
go with the official Canvas API
[http://developer.android.com/guide/topics/graphics/index.htm...](http://developer.android.com/guide/topics/graphics/index.html)

------
gary4gar
I would love to see some scripting language in Android AND iOS which is
_Officially_ supported. Something like Python,Ruby or JavaScript which will
make app development much easier.

Hey Google, Give us a nice scripting langauge. Pretty Please?

~~~
ratsbane
Scripting Layer For Android (SL4A): <http://code.google.com/p/android-
scripting/> Though for stuff you're going to distribute it's much better to go
native, bite the bullet, and do it in Java.

------
schiptsov
This guy it seems trying to say that Android's APIs were developed by
(talented) engineers for engineers (skilled programmers) on the go, while
Apple just adopted mature libraries from OSX which are providing set of hight-
level abstractions and APIs understandable by any mediocre coder (the way of
'easy/cool' java/php frameworks).

But one should remember that too high-level APIs and abstractions has its cost
in terms of performance and bloatedness of required runtime
(J2EE/Spring/Hibernate way) especially on resource-limited (lack of FPU, etc)
platforms.

------
methodin
The only thing I know for sure is it took me about 4 hours to write a concept
Android app that used an existing app the market (barcode scanner) which I
could interact with via intents. It was free and I can install the APK on
devices without using the market. I don't really know what more I could ask
for.

Well that's not true, the other thing I know for sure is Objective C makes me
dry heave.

------
KirinDave
So of all the things which might be singled out as "over-engineered" in the
Android developer kit, he singles out the mechanism of _message passing_ as
worthy of the propeller beanie?

That's confusing to me. Message passing is one of the simplest actionable
metaphors we have in the world of programming. I'm new to android development,
but they seemed pretty straightforward to me.

------
amurmann
I worked on an Android app for about 2 months together with some experienced
Android developers. Most things, like displaying dialogs, storing things to
the Db, etc. worked quite well and I really came to like intents. However, I
completely agree with the authors criticism of the implementation of
asynchronous calls. We implemented in app purchase functionality for our app
and it was a huge pain. Google provides lots of documentation around this.
However it's very convoluted and looking at their example IAP app makes you
wonder if they had some contest going on to achieve the highest number Gang of
4 design patterns per lines of code. That massively distracted from what the
example was supposed to teach you. We ended up spending around 2 weeks to get
a solidly tested implementation of IAP working and get all edge cases covered.
My main complaint about this is, that we weren't doing anything fancy and 99%
of the code we had to write was not specific to our application. Something
that just takes our vendor information and one callback for the success case
and one for the error case would have totally done the job. I am sure there
are hundreds of dev teams out there writing the exact same code as we did.
Many of those probably are not testing their code or even just copying
Google's example, without understanding what's going on. This is a huge waste
of everyone's resources and will probably lead to many buggy apps. I
understand that Google wants to allow for the flexibility to cover 99.9% of
all use cases. However, they could still have offered a simple library method
for the 99% case and have allowed the other 1% to write their own thing. Now
everyone has to write their own solution. I hope someone will open source
their IAP solution. If not, I actually might do it, since it's just crazy
right now.

------
InclinedPlane
There are other ways to do it: <http://android.xamarin.com/>

~~~
fdb
Mono on Android sounds tempting. But how much overhead does the core runtime
on the platform add? What is the impact in KB's and runtime performance?

~~~
andybak
And how well integrated into Android 'proper' is it? For example - intents and
fragments?

~~~
bad_user
I played with it -- integration is very good, mirroring the Java API quite
well.

I would still use Java directly on Android though.

I do agree with the author that Android's SDK is a little complicated, but it
has good reasons for it and whenever I choose new platforms I take it as a
given that I have to make an effort to learn it.

I don't see much value in bitching that the learning curve is steep, when once
you get to know the platform it becomes easy to make it do what you want -- in
general I bitched about Java frameworks because power and ease of use are
completely missing, even once you learn them properly, but that's not the case
with Android.

And as far as iOS development goes, I work on apps more complicated than
drawing Hello World with a couple of buttons -- and to me Android is better
because it allows me to do mostly whatever the hell I want; compared to iOS
where I always ask myself " _is this even possible_ "?

------
1880
Maybe I am going off on a tangent here, but... why not just use an AsyncTask
with a synchronous HTTP petition inside? I am a novice in the Android SDK, but
it just seems easier.

------
huntergdavis
Counterpoint, and like I said on the original post: Within a few days of
programming Android I had published a few apps. You just need the App-titude,
and the attitude as they say. I'm on day 60 and have done 65 Android apps thus
far. Perhaps my live-coding video that was up last week would help?
[http://www.youtube.com/watch?v=x8bu8nNUZSY&feature=chann...](http://www.youtube.com/watch?v=x8bu8nNUZSY&feature=channel_video_title)

~~~
lurker14
Why 65 rush jobs instead of few polished apps?

Skillful Surround could be an attractive game if it got some TLC.

------
stretchwithme
Haven't tried programming Android, but not crazy about objective c. But
Apple's documentation is stellar and easy to access.

~~~
aerique
Agreed. I have no love for Apple and I'm developing directly on my jailbroken
iPhone through SSH and even then the documentation is very useful.

~~~
conradev
Heh. iphone-gcc sucks.

------
d99kris
For higher abstraction layer on Android, there's Corona SDK and other similar
tools.

------
ristretto
Wouldn't it be better though if we did not have to rely on either apple or
google for mobile programming? How about extending trusty old HTML to provide
low level Apis for mobile devices? Phone gap does it and it's already proving
valuable. As mobile bandwidth is becoming more stable it makes more sense to
quit the app store madness and embrace the wild open web as the only app
platform. In principle I do not see why there isn't a set of mobile browser
extensions already; i suspect that both google and apple will use their
platforms as a tool to lock in developers to their own strategies.

~~~
lurker14
Phonegap is a common JavaScript interface to native APIs. HTML is only
tangentially related.

Building apps with JavaScript is doable, but has performance consequences that
are severe on low-power mobile devices.

It's hard to fault Google for providing an open-source Java-compatible OS.
It's not their fault if other OS builders are not compatible and actively
block cross-platform solutions.

I haven't tried it, but I don't know a reason why one couldn't write an
Android native app on Objective-C. You'd need a cross-compiler and
technical/legal ability to port Cocoa though, the latter which I suspect would
be quite challenging.

------
babebridou
Java APIs are not designed to "just work" but rather to "eventually work with
anything".

------
malkia
Then again you won't find such names in iOS SDK
[https://plus.google.com/101253020771610439991/posts/YKKyGFdq...](https://plus.google.com/101253020771610439991/posts/YKKyGFdq2MT)

:)

~~~
getsat
Your link is a 404

------
TheRevoltingX
WTF? This guy is an idiot.

I make iOS and Android applications for a living. It is ridiculous to have to
create a service to make a few HTTP calls. For that, Android/Java provides
various threading classes so that you can keep multi-threaded code nice and
neat.

With iOS, out of the box, you get NSURL and its family. You have to setup
callbacks in your class and you have to keep track of your http calls per
class by using things like action=whatever. What a pain. ASIHTTPRequest makes
things much easier.

Ugh, this just makes me mad. Why would people listen to shitty developers? Why
are you spreading this ignorance?

Objective-C is a giant paint, with opaque types. Having to remember what class
you've put into a dict can get messy.

I have to work with both frameworks every day, and Android is the better
framework BY FAR.

~~~
jcizzle
I definitely laughed at the irony of this post.

~~~
TheRevoltingX
Care to rebuke? BTW, read hackbod's comment. She's an Android engineer. This
guy is flat out wrong and failed to read documentation. She puts it much nicer
than I can.

