
Android development has its own Swift - hasseg
http://blog.futurice.com/android-development-has-its-own-swift
======
jo_
I feel like this overlooks one of the more fundamental problems to Android
development. It's not an issue with Java, it's an issue of Android being a
cathedral of complexity. There are four dozen ways to accomplish the same
tasks, each of which utilizes a different (but ultimately incompatible) piece
of the API. You can build your Activity and embed your Fragment in it which
houses a ListView to display your--- wait no maybe I should override ListView.
No, people say that's a bad idea. Okay I'll override this object which
ListView displays. Okay that kinda' works well enough. I'll figure out how to
style that later. Okay now I need this thing to go to this other activity when
cli-- maybe I should just replace the Fragment, since we're kinda' using the
same data. No wait. I'll change the activity. Okay it looks like there's no
function to do that. I'll go back to changing the Fragment to something else.
Okay, that's giving me an exception. Lemme find where I can change the
Activity... Oh, I have to do it elsewhere. Well I can hack my way around that.

It doesn't end.

"Button is actually a special type of view with extra properties." Great, so
everything is a... You know what, I don't care. I feel like I did in the mid
2000's with game development: there are a thousand libraries which each are so
complex that it's impossible to get good work out of them. Instead, I always
ended up falling back to the simplest home-rolled solution. Except in the case
of Android, there's really nothing more fundamental. I can (and do) use
PhoneGap because it makes my life _significantly_ easier in many respects, but
I think Android really needs to be restructured on a more fundamental level.

~~~
kllrnohj
No, if you're reaching for PhoneGap it's because you already know HTML/CSS/JS
and just don't want to learn Android's UI. Android's building blocks are
simpler and more predictable than HTML/CSS is, so clearly complexity is very
much not the issue you are having. It's just lack of knowledge and a lack of
motivation to learn it. Which is fine, just not at all what you are claiming.

Android's pieces do force you in to a significant amount of upfront complexity
which makes rapid prototyping hard, but that complexity pays off a hundred
times over when you start fleshing out the application into a real project.
It's very critical infrastructure as the app complexity increases.

~~~
jo_
You're probably right. I'm not convinced you're right, but I'll operate on the
assumption you are and offer a feeble defense with anecdotal (and
experiential) evidence to explain why I would rather use Android UI but
consistently turn to PhoneGap.

I knew Java first, then picked up HTML/CSS/JS on my own. I'm cozy enough with
Swing and I'm getting there with JavaFX.

I would rather develop in Java with Swing or even JavaFX. I reach for PhoneGap
because I can develop my application 'live'. Make code changes, switch
windows, changes are live. I can pull up the UI panel and make adjustments to
styles to see what looks good. I can test the entire application and debug it
before I push it to my device. If something fails to load, I can see why
without waiting for an emulator to spin up and without pushing to the device.
Plus, if the application crashes in my browser, I can pull up the debug
console and step through it. I'm sure all these things are possible with ADB,
too. There are lots of little things which irritate me with native Android
development. I'm still releasing apps and every so often I try to do a native
one. Whenever I do, though, I always find myself stuck on something that seems
infuriatingly simple or clear -- something that 'Just Shouldn't Happen," and I
look over at PhoneGap and I know that, despite JS being kinda' shitty, and
despite the lack of consistency in HTML5/CSS, it still beckons for silly
reasons like, "Small annoyances are more soluble! You don't have to rebuild
and reupload to fix a null-pointer error! You can use the REPL to play with
objects in memory!" and so on.

Maybe I am reluctant to learn the nuance of Android UI on a subconscious
level. Maybe I'm reinforcing my own beliefs when I sit down with an Android UI
book or go through the UI tutorials online. I've just never felt the workflow
was very intuitive, and the small (though frequent) irritations are enough to
drive me back to something which is worse architecturally and more time
consuming in the long run, but doesn't have the little things that make it
unpleasant to work.

CAR ANALOGY! I have two routes to work: one of them is short, but goes
directly through the city and has a crazy merge that I need to do to get
there. Some days I take this route because "it would be totally great if I'd
just get familiar with it," and I start out fine. Except for the insane merge
which is backed up for a few blocks. I'm driving fine, and I feel like now
that it's over I'm home free. Oh. This street has construction. Sudden stops.
My head is starting to hurt. Nearly half way there. Okay, I don't see a way
around this route. I have to backtrack because I made a wrong turn early on.
More construction. Traffic lights that aren't working right (or are, but I'm
mixing them up with the ones facing perpendicular traffic). Finally at work.
I'm irritable and still have a whole day ahead of me.

The other route is really long. I get on the onramp and it's slow but I'm
always moving. Quick scuttle and I'm free to drive. The roads are unfinished
and there's an omnipresent farty smell, but I'm moving at a comfortable pace
and I'm pretty relaxed. Oh, the bridge my route takes is out. Well, I'll
travel down the way a bit. No problem, though it's going to take longer. Swoop
around and I arrive at my destination. On the way there I also picked up a
Strawman at a barn to use in my analogy.

~~~
kllrnohj
Well, a lot of that gets back to "Android is hard to do rapid prototyping in".
I would looove something faster to iterate with personally, but I can also
understand how it could be detrimental in the long run. It's too easy to take
prototype code and ship it, instead of fixing up the underlying architecture
to play nice with all the various lifecycle and different device configuration
stuffs. Fragments are a pain to deal with in the early stages, but they force
you to modularize your app in such a way that makes long term maintainince and
UI changes easier.

You can now see changes "live" in Android studio with the preview pane, which
is getting pretty good these days. If you haven't played with that I'd suggest
giving it a shot.

The emulator is a disaster, I only ever develop on real devices. Pushing isn't
that slow, but it's definitely not as nice as just hitting refresh in a
browser.

------
eddieroger
Article is down for me. Here's a mirror (minus graphics and CSS):
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://blog.futurice.com/android-
development-has-its-own-swift)

The article felt like it was trying to rationalize something, like Android
needs a Swift. I'm not sure that's the case. The main point of the argument by
my reading was "less lines of code are possible," but that's not what Swift is
trying to bring the to the table (although no header files are nice). Swift's
biggest advantage is that since Apple has redefined the rules of the language
and don't need to stay C compliant, they can change the optimizer and enforce
rules differently. Less lines of code are a side effect.

~~~
DCKing
> The article felt like it was trying to rationalize something, like Android
> needs a Swift.

Android probably doesn't need a Swift as much as iOSX did, but there's still a
lot to be gained from having a less verbose programming language (and
corresponding platform API). Objective C, despite its older features and
unfamiliar syntax, was more expressive already than Java was. With Swift, they
removed the legacy and made the syntax familiar.

But I don't think this is the answer. If you debug Scala on Android at least
you don't have to make a mental mapping of what the corresponding Java
translation of your function would look like. A true new language with good
features and 'light' syntax would be great. Google already has such a
language: Dart.

But Google has already said that at IO 2014 that Java is the language for
Android and it will stay that way.

~~~
lobo42
> But I don't think this is the answer. If you debug Scala on Android at least
> you don't have to make a mental mapping of what > the corresponding Java
> translation of your function would look like.

Again, this is also not the case with Xtend. See this screencast :
[https://vimeo.com/38425995](https://vimeo.com/38425995)

~~~
DCKing
Ah, my apologies. The CoffeeScript metaphor is not completely valid.

------
izacus
The question about those code-generating languages in connection with Android
is always:

How HARD is it to debug?

Because most of them fail badly as soon as you need to do any complicated
breakpoint debugging (non-matching line numbers, broken local variable
inspection, useless and misleading stack traces) and that loses more time than
the language change will ever gain. After all, most of the time we're
developing for Android, we're dealing with Android API's and another language
does not address warts connected with those. Also powerful utilities like
IDEA/AS provide alot of assistance with writing / folding / managing Java 6
issues without debugging issues.

The other important questions: how big of a space hit is the standard library?
E.g. Scala on Android will generate/include alot of methods which means you
hit the 64k method limit of DEX format pretty quickly. That means you have to
use Proguard for each build (even development) and Proguard pass can easily
run for several minutes even on a 16G SSD equipped machine - killing
development speed.

~~~
frowaway001
> That means you have to use Proguard for each build (even development) and
> Proguard pass can easily run for several minutes even on a 16G SSD equipped
> machine - killing development speed.

No, not really. You can just install the standard library on your Android
device for development, and only use ProGuard on the final release.

~~~
izacus
Not when you reach 64k methods together with libraries for a debug build. Of
course, unless you want to go through the joy that is loading another .dex
file :)

~~~
oehme
The library you would use for Android (xbase.lib.slim), has about 2.5k
methods.

------
newgame
Another, imho, more appealing Swift on Android is Kotlin
[http://kotlinlang.org/](http://kotlinlang.org/)

It shares many features with Xtend but offers more. It has the opposite
"problem" wrt IDE support though: Great IDEA support but no Eclipse support.

~~~
staltz
Does it compile to Java source code?

~~~
theGimp
According to the FAQ page, it compiles to Java bytecode.

 _Is it Java Compatible?

Yes. The compiler emits Java byte-code._

[http://kotlin-web-site.jetbrains.org/docs/reference/faq.html](http://kotlin-
web-site.jetbrains.org/docs/reference/faq.html)

~~~
higherpurpose
Does that violate the new ruling in favor of Oracle lately? If not, what if
Oracle pursues that in the future, too? If I were Google I'd be like on
needles about continuing to support Java on Android, and I'd start looking for
a complete replacement (which will take years to come to fruition anyway, so
all the more reason to start now).

------
rdtsc
There is the scripting layer so you can use kivy and Python.

But I am really hoping Dart would get there, it is just a really nice
language.

------
curtis17
Imo Android needs a Swift because: 1\. Java is too verbose/tedious. Developers
are looking for something richer/more expressive. 2\. Oracle. Java is non-
open.

Ultimately, the language that will become the Swift on Android is the language
that makes it a core goal. This alt-Java could even be blessed by Google.
Google could eventually cut Java out of the picture: Swift4Java -> Dalvik/ART.

Xtend, Kotlin and Scala are possibilities.

Kotlin has the Jetbrains Android Studio relationship going for it. Also
compiles down to JS so could target Chrome/ChromeOS as well. Not as heavy as
Scala - less of a learning curve. Xtend is good, and compiling to Java source
could be an advantage. But Google do seem to be leaning towards Jetbrains
rather than Eclipse.

------
programminggeek
If I were to pick any language to do Android dev that wasn't Java, it would be
Kotlin. It's a great language with a great IDE. I haven't done Android
projects with it, but if I were hell bent on not using Java, that'd be my
choice.

------
hrjet
The nice thing about Xtend is that it has a light run-time library. I wish
Scala had a core-library that could be used in Android and such other
constrained projects. Perhaps a library without specialisation and/or without
collections could be made.

About Xtend, I think it is not production ready yet. Having tried it in some
POCs I hit several snags, such as incomplete support for inner classes and
anonymous classes. (Some support has been added recently, though not sure if
it handles all cases fine).

~~~
frowaway001
Scala modularized its standard library recently, so it should be smaller by
default already.

Remember that deploying on Android involves a ProGuard step, so the size of
the standard library doesn't matter that much anyway.

~~~
hrjet
The modularization reduced the API surface, but in terms of size of binary,
didn't have much effect (about 20% size reduction).

ProGuard is useful during deployment but cumbersome during development cycle.

~~~
frowaway001
As already mentioned, it's not necessary to use ProGuard during the
development cycle.

------
donniezazen
As someone new to both programming and Android development, I think the
biggest help is not some easy language but the questions and problems that
have been asked on sites like StackOverflow. You can replace the language but
how do you replace that whole stack of help articles written for Java for
Android.

------
lobo42
The second part of this InfoQ article features a getting started on Xtend and
Android: [http://www.infoq.com/articles/unusual-ways-to-create-a-
mobil...](http://www.infoq.com/articles/unusual-ways-to-create-a-mobile-app)

------
ethagnawl
I've always been intrigued by the possibility of using Clojure or JRuby to
build Android applications. There are toolkits (Lein Droid, Ruboto, etc.) and
tutorials for both, but the edges are still _very_ rough.

------
mncolinlee
My question is why Xtrend instead of Kotlin or Scala? Both languages have good
reasons to recommend them and both already support Android today.

~~~
rsynnott
Mentioned in the article; many JVM languages have substantial performance
issues under Dalvik. Scala certainly does; not sure about Kotlin.

~~~
eeperson
Is this actually true for Scala? I was under the impression that statically
typed languages run basically the same as Java on Android. Granted it has some
other issues (such as running in to limits on the number of classes).

------
k__
> It is best understood as “CoffeeScript for Java”, or as “Java 10″.

I wish it would look like CoffeeScript

------
artribou
Annnnddd... we killed it.

------
cferreyra
Seems like the link is broken

------
ytch
How about golang?

~~~
izacus
What's with this Go obsession in connection with Android? Go's design and the
way it works is terribly suited for Android development and currently isn't
even capable of plugging into JNI bridging architecture of Dalvik/ART.

Not to mention that Go is a language built for static binaries running on a
distributed server and the code running with alot of callbacks, external
exceptions and user-input looks horrible.

~~~
jamieomatthews
This is a proposal that's starting to get some serious traction.

[https://docs.google.com/document/d/1y9hStonl9wpj-5VM-
xWrSTuE...](https://docs.google.com/document/d/1y9hStonl9wpj-5VM-
xWrSTuEJFUAxGOXOhxvAs7GZHE/mobilebasic?pli=1)

In theory, Go could absolutely be used for android development

~~~
izacus
In theory, anything can be used for Android development.

In reality, the cost of JNI bridging, reboxing objects and the fact that
Android APIs heavily use Java objects as parameters makes usage of any non-JVM
compatible languages horribly ugly, clunky and rather pointless performance
and code-quality wise.

