From Java to Android, challenges

Java on Mobile Devices Android
#1

Android depends on Java. With that, you might think learning Android programming would be relatively straightforward for a Java programmer. My experience has been otherwise. I thought I’d list some of the differences that took me most by surprise. Reading a list like this beforehand might help someone new to Android get going a little quicker, or at least, with a bit less disorientation.

(1) Android is a quickly moving target. This has two main implications:

  • the IDE (Eclipse or Android Studio) initial configuration documentation may not be entirely up to date, and once installed will require frequent updates, some of them quite bulky. When updating, an existing project may require steps not mentioned in accompanying documentation (if any exists).
    ** Virtually all books are out of date to some degree, some even by the time they are published, and can contain deprecated or obsolete code. Always check for errata listings!! Likewise, when searching online for help, be sure and pay attention to the dates of the posts and don’t assume they are still 100% valid. StackOverflow is the main resource for help, and often the most current answers are ranked below the leading answers (which have become stale)–so you have to know to look for them.

(2) The basic structure of an Android program is more like a Java Applet than a Java Application. In fact, it is a more elaborate version of the Java Applet, with additional states. In other words, no “public static void main(String[] args)”.

(3) XML is used for widget layout, Strings, and many other resources.

(4) In order to run and debug the code one has written, one has to either have Android devices for testing or get an emulator working. Emulator configuration can be rather challenging (see 1 above). I’ve managed it on my Linux with AMD cpu (Windows 7 or Linux with Intel is a bit easier to configure, it seems), and at this point running an update, with the accelerator or working, occurs in 15 seconds, which is within tolerable. (I have a budget-level, but new PC.)

Anything to add to the list?

I’m hoping to see a bit more activity in this forum overall, as JGO is a high-quality community. Am happy to share solutions as I come across them, if there are questions or interest.

#2

My key findings with Android are essentially the same as yours, with the following extras:

  1. The “JDK” such as it is, is stuck back a generation and probably won’t go any further - no lambdas for you!

  2. Writing sensible ordinary Java makes for rather slow code, especially when you’re trying to do anything that really has to be fast (eg. a sprite engine). The JIT is barely better than the old 1.1 days (remember them?), and garbage collection is still an issue.

  3. Last time I looked there were some serious performance problems with buffers which kinda just made we want to give up as I’m dead keen to avoid native hackery.

  4. Managing the Android lifecycle is bats and seems remarkably hard to get right, especially when it comes to managing GPU resources efficiently.

Cas :slight_smile:

#3

Don’t allocate in the main loop, like the good old days of programming C on the Playstation 2 :slight_smile:

Joking aside it is the slow progress of language that really grates with me. It puts me off playing with the new Java 8 features knowing that I won’t be able to use them in game dev as I will want to target android.

I don’t mind the lifecycle of the application it just something to learn and memorise.

#4

If you are targetting anything below 5.0, then that’s true. Android 5.0 and higher have no JIT anymore. The new ART runtime compiles everything to native code at installation time. Performance improvement compared to the JIT is between 0 and 100%, depending on the type of calculations.

Yes, it is. But again, it has largely been improved in later versions. Current runtimes (even the newer Dalvik ones) can run the garbage collection in parallel most of the time. The stop-the-world time for each collection has been reduced to single digit ms.

Not sure what your exact problems were!? From my experience, this was true for Android 2.x and below but everything higher than 4.0 should be fine. There were issues with float buffers for example. You could work around them even without using native code though.

Yes, that can be tricky at times. And again, it has improved in newer versions, because the behaviour is more consistent now compared to how it was with 1.x and 2.x.

#5

I’m glad it’s all getting better (heh, see OP point 1 :point:)

Cas :slight_smile:

#6

In reference to @EgonOlsen’s post:

For usage of 4.0 or better: over 90%
For usage of 5.0 or better: not quite 10%

http://developer.android.com/about/dashboards/index.html

http://chart.googleapis.com/chart?chf=bg%2Cs%2C00000000&chd=t%3A0.3%2C5.7%2C5.3%2C39.2%2C39.8%2C9.7&chl=Froyo|Gingerbread|Ice%20Cream%20Sandwich|Jelly%20Bean|KitKat|Lollipop&chs=500x250&cht=p&chco=c4df9b%2C6fad0c

Lollipop is 5.0+
Ice Cream Sandwich is 4.0+
Darker = progressively newer versions.

#7

A lot of the performance Tips: http://developer.android.com/training/articles/perf-tips.html

One of the most important from the link in my opinion, can become a GC problem.

Use Enhanced For Loop Syntax
The enhanced for loop (also sometimes known as “for-each” loop) can be used for collections that implement the Iterable interface and for arrays. With collections, an iterator is allocated to make interface calls to hasNext() and next(). With an ArrayList, a hand-written counted loop is about 3x faster (with or without JIT), but for other collections the enhanced for loop syntax will be exactly equivalent to explicit iterator usage.

There are several alternatives for iterating through an array:

static class Foo {
    int mSplat;
}

Foo[] mArray = ...

public void zero() {
    int sum = 0;
    for (int i = 0; i < mArray.length; ++i) {
        sum += mArray[i].mSplat;
    }
}

public void one() {
    int sum = 0;
    Foo[] localArray = mArray;
    int len = localArray.length;

    for (int i = 0; i < len; ++i) {
        sum += localArray[i].mSplat;
    }
}

public void two() {
    int sum = 0;
    for (Foo a : mArray) {
        sum += a.mSplat;
    }
}

zero() is slowest, because the JIT can’t yet optimize away the cost of getting the array length once for every iteration through the loop.
one() is faster. It pulls everything out into local variables, avoiding the lookups. Only the array length offers a performance benefit.
two() is fastest for devices without a JIT, and indistinguishable from one() for devices with a JIT. It uses the enhanced for loop syntax introduced in version 1.5 of the Java programming language.

So, you should use the enhanced for loop by default, but consider a hand-written counted loop for performance-critical ArrayList iteration.

#8

This annoys me because these are all pretty trivial things for an optimizer to normalize, but even with all of Android’s compilation steps I guess I’ll just stay disappointed. ART looks interesting though.
Enjoy that medal, whoops.

#9

All those sorts of things are just more good reasons just to go straight to C++. Or (shudder) Unity.

Cas :slight_smile:

#10

I’ve seen some Android and iOS experiments with Rust, that could be interesting too.

#11

I’m thinking of porting legacy java too.

One major advantage I have, I think, is that 95% of my graphics is done using only a canvas, no swing or awt widgets. If I use only a canvas, then doesn’t that eliminate using XML for layout?

Big open question, networking. Can I use raw sockets?

#12

You can. the only restriction is that you can’t open a network connection on the main thread.

#13

I’m interested in learning the answer to this too. Am slowly picking my way through tutorials and haven’t gotten to this situation yet.

I’ll say this, though, the use of XML has been pretty painless so far. AndroidStudio (I’m not sure if Eclipse provides this) has a screen where you can drag and drop components, and it handles the XML file creation for you. As long as you know the basics of how XML syntax works, the learning curve for this is slight.

I know there are a lot of folks passionate about the use of Libgdx as a way of dealing with Android. My first guesstimate on pros/cons of taking a legacy file and converting to Android:

libgdx

have to install and run Android tools in Eclipse
conversion of graphics to OpenGL (may require additional program structure changes)

java/android rewrite

install IDE (Eclipse or Android Studio)
learn Android
conversion of graphics to GWT

I suspect the graphics run more efficiently in OpenGL than GWT, a big consideration. But, once one knows their way around with Android, the conversion of legacy Java apps might be easier to GWT than to OpenGL.

Reality check?

#14

I plan on picking up the Android SDK later this week, this sounds interesting. I’m not usually a fan of drag and drop creation, though this seems pretty handy :point:. Might take a look at learning more about XML anyway though

#15

Well, there you get a whole lot of other pitfalls. I’ve quite C++ coding, because I kept running into obscure problems, which took a lot of time to track down and fix. If development time is a crucial resource to you, stay with Java.

#16

Adding to my original list (of conceptual hurdles when going from Java to Android):

(5) Planning program structures in terms of Activities and Intents.

#17

Wondering if someone can help me fix an error i’m getting when creating an Android project in Eclipse

For some reason when AppCompat_v7 is created, i’m getting an error in folder res/values-v21/styles_base.xml related to no resource found

My min SDK version is 2.3.3 (API 8 I think) and my target is 4.3 (API 18) and i’m also compiling with API 18. I don’t actually have API 21 installed, could that be the issue?

FIXED:

For some reason I had to edit project.properties inside both my project AND inside appcompat_v7 to android-21. No idea why though.

Also seems that ActionBarActivity is deprecated so I changed that to AppCompatActivity

#18

Getting the versions to line up has definitely been an issue for me. I occasionally break my tutorial projects when a new version comes around. I tend to get rid of old versions when I obtain new ones with the SDK Manager. I can’t say I’m totally clear on what gets tweaked where, but searching on the complete error message usually gets posts with others having the same issue, and so far I’ve managed to keep it all running.

All that said, I think your question could/should appear on its own thread. There’s no reason we can’t have more questions going in the Android area, imho. I’ll certainly do my limited best to help out when I can.

Speaking of “moving targets”, there’s going to be a streaming demo/lecture on Android M (current is L for Lollipop), tomorrow: https://events.withgoogle.com/whats-new-in-android-hackhome/

#19

Oh awesome - native Android discussion (albeit a little old - but this is a slow board). ;D

It’s been many years since I made the jump from Java to Android, but I don’t recall the move being that big of an issue. Mostly it’s a matter of figuring out which libraries exist, but that seems to me to be the same for any move to a “new” language.

(1) Regarding Android being a moving target, I’d be happy with them moving a little more; i.e., @princec’s point about them being stuck in Java7 land. I work with Scala and Java 8 in my day job at the moment, and it’s almost painful to have to work with the Android SDK sometimes (so… much… boilerplate…).

(2) A piece of advice: for complex native UI’s make sure to look at Fragments, and not just Activities and Intents.

(3) I use XML for almost all of my UI work. I find the Android UI editor useful to see the results of what I’ve done, but I always “code” the UI directly in XML. IMO, it’s an extremely powerful little system for the purpose it serves, and I much prefer it to anything else I’ve tried.The main reasons why I’ve never gotten around to moving to libGDX or similar frameworks, is the amount of code I would have to write to create identical UIs to what I can write with a few lines of XML in native Android (I have text heavy UIs).

Also, ProTip @SauronWatchesYou: Use Android Studio. I use Eclipse at work, and stuck with it for a long time for my Android development, but these days sticking to Eclipse is just asking for unnecessary problems. It’s no longer supported by Google, and the stuff built into AS quite simply makes it a superior Android IDE.