Thread: Best way to port a Swing Application to Android

Android GUI is very different from Swing.

What would you recommend I do?

Study the tutorials. Here are some links:

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

http://developer.android.com/guide/c...damentals.html

I ported a couple of very simple desktop applications to Android as a start to learning Android. I'd recommend starting simple and advance as you learn.

Not sure what you mean by "by hand". I don't know that there is a "converter" program to do it.
Most of the GUI design and interfaces need to be completely redone.
A desktop window has mouse and keyboard events. Android has that plus many different "touch" and other sense events. I'm working on an app now that needs to be sensitive to the device's orientation and to know whether the screen is on or off.
Many different ways for the user to interace with the app. It's a Whole new world for me.

I mean I will have to learn the android API and start all over from scratch to create the entire GUI-code all over again.

Yes, that is pretty much true.
It's mostly the GUI that's new. For the apps I ported over, most of the non-GUI code copied and pasted into the Android project without any problems.

The GUI needs to be created from scratch, but you can port the operational code by refactoring your Swing Application.
To do this refactoring:
1. Create a new project (let's call it: "Core")
2. Move all operational code from your Swing project to your Core project and refactor the code so the Core project is NOT dependent on the Swing project (Core should have no reference to Swing whatsoever)
3. Add the Core project to your Swing project's dependencies and connect the loose ends back up (your Swing Application should now work exactly like it did before refactoring)
4. Create the Android GUI in your Android project
5. Add the Core project to your Android project's dependencies and connect up the loose ends (your Android project should now be functional)

This approach allows you to maintain a single code base (Core) for the operational code for both your Android and Swing applications. A huge benefit to this comes when debugging. If you have a bug in your Android app, and you cannot reproduce it in your Swing application, this would mean that the bug is located in your Android project, not your operation code (Core). If you have a bug in your Android app and you can reproduce it in your Swing application, this most likely means that the bug is located in your Core project. You can fix the bug once in your Core project, and you can then immediately release the fix for both the Android and Swing applications. A shared codebase means you only have to fix the bug in one place.

Everything Norm said is true. If you're looking for an automagic way to convert Swing code to Android code, you're out of luck- as you should be, since Android is a completely different environment with different inputs.

That being said, JavaFX supposedly deploys to both desktop and Android. I've never tried it myself though.

Originally Posted by Cornix

I really was hoping there was some kind of standard way of doing it. After all, java is supposed to be cross platform and since Swing is part of the Standard Edition I just hoped this principle would apply to swing as well.

Exactly: Swing is part of Java SE. Android isn't Java SE, it just "borrows" a lot of stuff from it (hence the lawsuits between Java and Google). It does not borrow Swing, since the graphics are very different on Android.

More info here: http://en.wikipedia.org/wiki/Compari...nd_Android_API

Originally Posted by Cornix

Yeah, I read that already, thats why I asked here. Its a real bummer, I was very disappointed when I found out they did not include the complete SE.

In the long run, it makes a lot of sense. Swing is on its way out, and Android needs to keep up with the latest technological innovations. Swing probably isn't the way to do that.

I've seen JavaFX working on Android, so it's at least possible. But really, if you want to be a good Android programmer, you should learn "the Android way" of doing things. It's really not that bad once you get used to it.

Originally Posted by Cornix

I dont want to be a good android developer. I dont have an android device, I would not even be able to test it, but some of my users asked if the port would be possible so I wanted to do some research.

Ah, gotcha. That sucks then. You could also use Android's virtual device feature which lets you deploy programs to a phone that displays on your desktop.

The emulators are accurate enough. They are slower (normally), but functionally okay. You can configure the emulators to emulate specific devices to test with, so there is a lot to work with there without getting actual hardware devices. A program may run on some devices, and won't run on others. It depends on the Android version the phone uses and the Android version the program was built with.

If you have a specific phone you are making the program for (or a specific group of phones), find out what version of Android they run, and build your program with it. If you do that, there should be no reason (apart from bugs) that the program should not run properly on the phone.