I know Java apps can be run in Android. But what I want to know is this: I have a perfectly normal Java app and I want to port it to an android platform. What changes would I need to do to my app in terms of GUI and other code to make it usable in Android? I know Android uses XML file to control the look and feel of its app. So would I need to change my GUI completely?
I just want to know the general overview of how porting may be done. If anyone could point me to right resources, that would be great. Also, for your info I'm a newbie to developing android app, so please be patient with me :)
Update: Both very helpful answers. Thank you!
The short answer is that you would simply rewrite all of the GUI from scratch, for Android. It simply uses a completely different UI framework. While basically all of the core Java libraries are there, Swing and AWT libraries are not.
If you are looking to translate parts of it automatically, I don't think there is any such tool. You're going to be building a brand new Android GUI.
And really, that makes sense. These frameworks are serving reasonably different platforms and needs (desktop vs. phone). You probably need to be redesigning your app quite a bit to go from a desktop to a phone.
Good news is the non-GUI parts ought to work as-is with no changes, unless they do something unusual. You may have to package third party libraries into your project if they are used by your code.
I expect that it will be a great deal of work to do the porting, as the way that your application works with Android will be different.
You will also have some issues, perhaps, with the fact that not everything in java is supported, as it is a mobile device, but does more than JavaME.
It would help if you could explain a bit about the application, as how much it needs to interact with the user or any other resources on the device will determine how to port and how much work is involved.
Your best bet though is to see about learning to program on the Android, and there are several good books on the subject. I got one from Manning publications that I found helpful.
You may want to look at the comments in this article, as I think it would be a good starting point for you on what may need to be changed:
http://www.anddev.org/problem_in_android_project_conversion-t1633.html
Related
My team and I are within days of finishing our first iphone app. However, we went to program the same app onto android. None of us have any experience with android. I've been reading up on some tutorials for android beginners.
Since I know there are many knowledgable and experienced android/iphone programers on stackoverflow, i was wondering if there are any tips/resources you guys could shoot my way.
thanks!
For the best experience (for your users), you really ought to learn how to develop on Android using the standard Android tool chain. Applications shouldn't just be 'translated' from platform to platform, they really should be redesigned.
There are differences between platforms that really require rethinking of how things should work, both at the user level and at the code level. Simply translating between platforms results in a poor experience for the result.
I don't know how your project is structured out or what technology you use. Anyway, for me, I implemented all the logics and coding in C++ other than the interface itself. Then, I used JNI for the C++ code on Android. At the end of the day, it's a matter of building Java GUI programming on Android.
Alternatively, you could use some portable framework like Titanium and PhoneGap. But they do need some learning curves and you might experience weird behaviors.
I have an Blackberry library written using JAVA as well Blackberry(RIM) specific API's. I would like to port the same library in to Android platform without making any code changes and make it run.
Here i am looking for the best way to achieve it
Any cross compiler/cross framework is available for making my Blackberry run on Android platform.Thinking this would make my job easy ;)
Please share your inputs on this.
Thanks in advance.
You can't do that. AFAIK, Blackberry uses J2ME technologies(can be wrong here). Android system is built in absolutely other principles. You have got to learn android in order to understand how to build GUI, how to process with background tasks and where you store your data. Sorry.
Start with application fundamentals.
If porting was that easy, a lot of developer would be out of work.
You will not have to rewrite the whole application, but surely there must be quite a few changes done. If you have a clean design, you might be able to reuse a lot of code as it is. Otherwise it will get more complicated. For the RIM API, it might be a good idea to write interface-classes first ("RIMXyz implements IntrfXyz"), that have all the function-call that you use of the RIM-API. Then you can write the Android API classes using "AndrXyz implements IntrfXyz". Put the RIM-dependend stuff in a separate external lib, and do the same with the android-dependent stuff. Then you can have a RIM-prj and an Android-prj, each only linking to the dependent classes and the reusable classes. That way you could structure you porting project quite nicely.
Also the "top" end of the application surely has to change, because you have to use the "activity"-class in Android to get anything running. Those are the two aspects I see.
I hope this is understandable, a bit hard to put it in a few words...
I have started a cross-platform project for Android/Java applet, and this is how I've done it. It works. ;-)
You cannot do this without some code rewrite. If you can tell us more about the classes in the RIM API that you are using, you might get some specific answers as to what classes from the Android API to use.
You should find similar functions in android api to replace RIM API invocations and refactor your code using for example Abstract Factory design pattern. (http://sourcemaking.com/design_patterns/abstract_factory)
I used Eclipse with the Android SDK to develop the original application. I ask since this was my first Java (and Eclipse, and Android, and XML) project. I assume that most of the Java should run on the PC without too much trouble. I may want to restructure the code to isolate the Android specific functions. Should I stay with Eclipse or move to something like NetBeans? Any advice would be terrific.
Eclipse vs Netbeans is irrelevant to your problem. They are both just glorified text editors that let you edit java code, with a little bit of compilation help. You can write any java app in either, its really just personal preference.
The ease of porting to windows really depends on what your application is. If you have a large chunk of code that is not dependent on any of the UI or lifecycle stuff, then you should be able to create a separate java library for that and reference it in both your android app, and your windows app.
The challange will be replacing the UI. As Fredley mentioned, swing is the built in option. Its a bit of a pain, but you should be able to find plenty of documentation on it.
If your application is tightly tied to the UI, then you are going to have a very hard time finding any code in common.
Assuming that most of your code is in Android-independant classes, your biggest hurdle will be the GUI. Investigate swing to start off with.
The choice between NetBeans and Eclipse is largely one of preference. NetBeans has some nice GUI tools- but so does Eclipse. In my opinion, it's usually best to stay with what you know.
Here's a decent post on the subject of Java IDEs: What is the best free IDE for Java Programming
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've just finished a relatively large project for the Android, and it's left a bitter taste in my mouth with the knowledge that it will never run on one of the most ubiquitous handsets this side of the solar system (the one by that fruity little club).
So, for my next project, I want to write it in a way that makes most of the components easily transportable between the iPhone and Android platforms. The way I'm thinking of doing this is by coding most of it in Objective-C, and then adding the platform-specific parts in more Objective-C and Java respectively. On the Android side, this will require using the the NDK.
My knowledge of C is good, but my knowledge of Objective-C is close to zero, and I have no desire to learn C++. How sane is the approach above, and is there a better one? Is there any way I can code in Java and still reach the un-hacked iPhone market? And how likely is it that the people I know (iPhone users) will have an Android phone by next year?
Step back and think about what in the end you will logically be able to share.
The UI models are fairly different, the components are different. In the end what you might be able to share is data object classes, possibly some algorithms. It's not even like you could realistically end up sharing network code as in the old days because you aren't directly using sockets, you are using HTTP libraries.
So will all of the effort you are putting into this really find a payoff in the end? It seems to me the end result will be a brittle mess that is hard to update, and is mediocre on both platforms instead of being great on either.
Why are you writing applications? To make life easier for you, or your users?
Others have said basically this, but I'd like to make it more explicit. Your best bet is probably to write:
Cross-platform data models & core logic, using:
bits of GNUstep (Obj-C), or
CF-Lite (C), or
Whatever you'd like, as long as it's cross-platform :P
iPhone-only interface code, using Cocoa Touch (Obj-C)
Android-only interface code, however they do it for the Android.
That's as close as you can get; any attempt to write cross-platform interface code will undoubtedly result in a mediocre app on both platforms. But making all the rest of your code portable and just wrapping a device-specific interface around it is done all the time and has been worked great for some iPhone developers.
Objective-C without Cocoa is not so useful and won't bring you much closer to haveing a working iPhone codebase. You'd probably be better off writing your core in C with Core Foundation and using either Java or Objective-C for the platform specific parts. Apple has open sourced a large chunk of Core Foundation as CF-Lite, and it's toll-free bridged with Cocoa on OS X (i.e. you can use many CF classes interchangeably with their Cocoa counterparts).
My guess, which has no experience to back it up, is that you probably could write Obj-C with Google's NDK somehow, given that GCC exists for ARM, is open source, has an Obj-C compiler and a basic Obj-C runtime (which if it doesn't already probably could be hacked up to work on a new architecture), etc.
That might also be a lot of work for questionable benefit.
And of course "Obj-C" (without the NS classes) means something very different than "Cocoa", which is what most people really mean when they say "Obj-C". You might be able to re-use some of GNUstep for some that, but... Honestly, I doubt it. Sounds again like a lot of work.
So, yes, I think it is possible. It's also a lot of work and I don't think it's worth it.
Given what you've said, if I were attempting this, I would be tempted to write as much of your core logic as possible in C, then wrap it with two separate GUIs for each platform.
Coming at this from a different angle... I know that you said you wanted to try and stick with Java, but if you know C# then you could go with the MonoTouch framework for the iPhone. Mono is essentially and open source implementation of the .Net stack. The Mono team is working on bringing Mono to the Android so you could basically write a shared C# library for your business logic and have different Views/Controllers per platform. This would all be in C# of course and it is a bit more expensive, but it does solve the problem of writing everything in different languages.
I believe it is called MonoTouch on the iPhone and MonoDroid on Android.
The Apportable SDK is an Objective-C approach to write once and deploy to both IOS and Android. It will cross-compile a running IOS Xcode project to an Android SDK.
See here for sample apps that run on both platforms in minutes after download.
I'm not sure about Android but with the iPhone you can essentially write straight C as long as you wrap it up in Objective-C classes.
The Objective-C runtime has not been ported to Android yet. It shouldn't be too much work, but still, without a working knowledge of the language I doubt you'll have an easy time porting it.
What you are trying to do is going to be hard for a generic application, but should be possible for games, if you choose to develop the game in plain C (which is supported by both the Android NDK and the iPhone). You'd have to write up some glue code to pass input events from the Obj-C and Java environments into your C code, but that shouldn't be much of a problem - Objective-C allows you to directly call into your C code and there are plenty of example projects which do exactly this for Android.
I haven't tried this myself or finished watching the talk yet, but there is a Google Tech Talk on Developing iPhone Applications using Java up on YouTube that looks pretty promising.
XMLVM is a project which is capable of translating (some) Android applications to the iPhone. For more infromation, visit http://xmlvm.org/android/
I realize this may be a tad late, but it seems the industry is going in the direction of web apps these days to achieve app portability. That is, embedding a web-browser in your "skeleton native app", and writing javascript, css and html for Android, iOS and the other major smartphone platforms.
There are tools that help you with this. You might want to check out PhoneGap and Sencha Touch, but there are many more. Note that this approach may not be ideal for real-time/animation-intensive apps.
Here is a talk from facebook's mobile # scale conference where two teams (dropbox and orchestra) used similar approaches. Dropbox used C++ to create libdropbox and Orchestra (mailbox) used Objective-c to create libmailbox.
Again, they wrote their front ends in the platform native language and used their cross platform libs for core logic and data.
Key benefits I took away: Mailbox went from ios to android in 5 weeks because it was just building UI code. Dropbox can beta test changes to core functionality that are in the shared library with Android beta deployments were it's easier to do massive deploys at scale for beta builds.
If you can wait until later this year (exact amount of time unknown), Adobe will have AIR for Android and a compiler to iPhone. Thus you can write an app in AIR for the Android and use most of the same code to compile to the iPhone.
http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/
Even if you can't wait see: http://www.insideria.com/2008/12/actionscript-to-cocoa---protot.html where it explains the similarities between ActionScript and Cocoa.
Also check out: http://labs.adobe.com/technologies/air2/ for the AIR version capable of using the touch screen.
So you can soon write once and deploy to Android and iPhone using ActionScript 3.
Haven't seen anything about it here but it seems to solve one of the problems with GWT - the fact that you have to write Java code to generate your GUI. Instead this software allows you to design the GUI using drag-and-drop tools - a WYSIWYG interface.
I'm not trying to sell the product, by the way.
I just want to know whether it works as advertised, is effective, easy to use, etc?
Anyone have any experience to answer these questions?
GWT-Designer is now freely available as the product has been acquired by Google. http://googlewebtoolkit.blogspot.com/2010/09/google-relaunches-instantiations.html
Google will improve the product which is already quite good.
I don't think that the lack of a GUI editor is a problem with GWT. Consider HTML, there are plenty of WYSIWYG editors for that (like Dreamweaver) but most experienced web designers don't touch that stuff with a barge pole, they hand code it. Not because they're masochists, but because they want control over the source, they want to make it clean and readable. Coding is a scientific artwork, best left to Human Beings ;)
I tried GWT Designer very early on, and I found that it was fairly poor (and only worked on Windows because it had some dlls that went along with it), but things may have changed drastically since then.
I'm using GWT Designer for my Capstone project. I did start from scratch, and it worked quite well. I'm no fan of WYSIWYG software, so I was pleasantly surprised. Here's a link to a post I did on it:
http://benarchie.blogspot.com/2010/12/gwt-designer.html
GWT-Designer is getting better all the time. Give it another look some time, it's catching up to things like visual studio in my opinion.
Personally I like GWT Designer for Eclipse and it is free.
It is a rapid development tool. Not a solution for non-programmers however it will accelerate a Java coders ability to learn how to use the GWT API. Once you learn the tool it will reduce coding time.
I found it necessary to frequently switch between code and WYSIWYG editor to get things exactly how I wanted them. The two editors work well together. You will still need to refer to Java Docs to gain a full understanding. Most of the Java Docs have excellent Java and UiBinder code examples in them which are ready to cut and paste.
Creating GUIs in UiBinder is definitely the way to go because it simplifies the hierarchical nature of laying out GUI elements. The API is missing some information about how to hand code in UiBinder however between GWT-Designer, Java Docs and Google, you will find an answer.
The built in Jetty web server also simplifies deploying and testing on your local machine. I was able to make small code changes and see the effect in the web browser immediately.
Try these tutorials.
http://code.google.com/eclipse/docs/gwt_uibinder.html
http://code.google.com/webtoolkit/tools/gwtdesigner/tutorials/stockwatcher.html
I've tried GWT Designer recently. It still looks poor. If you don't want to lose flexibility, I would recommend to use GWTLab
Just tried it then. Most of my ui.xml files wouldn't open because it doesn't currently support #UiField(provided=true).
The ui.xml files that didn't use this feature would often crash with things like UnableToCompleteException.
Maybe if you started from scratch using designer you might have more luck.
I had a year's subscription but did not renew it, being a bit disappointed with the product.
1) The designer injects all Java code adding creation/property setting/event handling to the module you are building in a most unecomic way. Additionally, it is pretty difficult to modularize the application. Compared to Flex, for instance, the number of lines of code gets easily double or triple in a module and seeing the forest from the trees is not easy.
2) Web applications I built only a a couple of years ago CEASED WORKING possibly due to changes in Javascript engines. That was something I did not expect and is very possibly GWT's fault.
3) The GUI designer needs A LOT of CPU power and so does the build phase.
The concept is nice, however, I admit and GWT designer is the only of its kind. The feeling of difficulty in modularizing may well be my lazyness.
EDIT: Shortly after I wrote the above comment Instantiations/Google introduced the UiBinder concept which makes a lot more sense than the original amalgamation. Now it is a lot more professional.