Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (804)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (868)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  From Java to Android, challenges  (Read 68286 times)
0 Members and 1 Guest are viewing this topic.
Offline philfrei
« Posted 2015-05-26 02:57:27 »

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.

music and music apps: http://adonax.com
Online princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2015-05-26 07:46:42 »

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 Smiley

Offline PaulReeves

Junior Devvie


Medals: 3



« Reply #2 - Posted 2015-05-26 11:29:27 »

Don't allocate in the main loop, like the good old days of programming C on the Playstation 2  :-)

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline EgonOlsen
« Reply #3 - Posted 2015-05-26 12:03:06 »

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

and garbage collection is still an issue.
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.

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

4. Managing the Android lifecycle is bats and seems remarkably hard to get right, especially when it comes to managing GPU resources efficiently.
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.

Online princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2015-05-26 12:40:31 »

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

Cas Smiley

Offline philfrei
« Reply #5 - Posted 2015-05-26 17:16:15 »

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




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

music and music apps: http://adonax.com
Offline craftm

JGO Coder


Medals: 15
Projects: 1


_Keep Trying


« Reply #6 - Posted 2015-05-26 22:25:30 »

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:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
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.

_ Wink
Offline BurntPizza

« JGO Bitwise Duke »


Medals: 486
Exp: 7 years



« Reply #7 - Posted 2015-05-27 01:01:03 »

loopy stuff

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.
Online princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2015-05-27 07:31:11 »

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

Cas Smiley

Offline BurntPizza

« JGO Bitwise Duke »


Medals: 486
Exp: 7 years



« Reply #9 - Posted 2015-05-27 07:36:03 »

I've seen some Android and iOS experiments with Rust, that could be interesting too.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ddyer
« Reply #10 - Posted 2015-05-27 18:53:36 »

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?
Offline teletubo
Global Moderator

JGO Wizard


Medals: 76
Projects: 4
Exp: 8 years



« Reply #11 - Posted 2015-05-27 21:24:25 »

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

Offline philfrei
« Reply #12 - Posted 2015-05-28 15:27:31 »

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?

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?

music and music apps: http://adonax.com
Offline SauronWatchesYou

JGO Ninja


Medals: 33
Projects: 4
Exp: 2 years


Hi there! :)


« Reply #13 - Posted 2015-06-02 18:40:45 »

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 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 Pointing. Might take a look at learning more about XML anyway though

Hey, you! Back to work
Offline Varkas
« Reply #14 - Posted 2015-06-03 12:38:08 »

All those sorts of things are just more good reasons just to go straight to C++.

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.

if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline philfrei
« Reply #15 - Posted 2015-06-03 18:09:12 »

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

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


music and music apps: http://adonax.com
Offline SauronWatchesYou

JGO Ninja


Medals: 33
Projects: 4
Exp: 2 years


Hi there! :)


« Reply #16 - Posted 2015-06-04 15:37:23 »

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

Hey, you! Back to work
Offline philfrei
« Reply #17 - Posted 2015-06-04 18:37:09 »

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?

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/

music and music apps: http://adonax.com
Offline strategy
« Reply #18 - Posted 2015-07-07 18:00:00 »

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

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.





Pages: [1]
  ignore  |  Print  
 
 

 
Riven (583 views)
2019-09-04 15:33:17

hadezbladez (5517 views)
2018-11-16 13:46:03

hadezbladez (2405 views)
2018-11-16 13:41:33

hadezbladez (5779 views)
2018-11-16 13:35:35

hadezbladez (1226 views)
2018-11-16 13:32:03

EgonOlsen (4664 views)
2018-06-10 19:43:48

EgonOlsen (5684 views)
2018-06-10 19:43:44

EgonOlsen (3199 views)
2018-06-10 19:43:20

DesertCoockie (4096 views)
2018-05-13 18:23:11

nelsongames (5116 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!