I'm porting my app from iOS to Android: what do I need to know?

Question

What pitfalls should I avoid?

• What Java language paradigms do Objective-C developers consistently misunderstand? I learned to program in Java, but I have worked in nothing but Objective-C for years now.
• How are the design patterns different between Android and iOS?
• If you've made the transition yourself, what parts of Android confused you or took you longer to learn than it should have?
• Is Eclipse the best OS X IDE for Android?

For the record, my app is very strongly tied to UIKit and Foundation, so the word "porting" may be a misnomer; I'll actually be completely rewriting it for Android. No code reuse. Also, I'm doing this to learn Android, so I'd rather fail at the port and learn Android than take a shortcut.

---

As a bit of background, this question was prompted by the types of questions I see on Stackoverflow. Frequently you can tell what someone's background was (C# or Java) by what silly mistakes they make when they're trying to write Obj-C. I'd like to avoid the kinds of mistakes that make Java developers roll their eyes and say, "Silly Objective-C developers, won't they ever learn?"

Answer 1

I'm porting an app from iOS to Android, it's someone else's app that I am working with to do the port but none-the-less.

First off I would say that the user bases have been taught drastically different ways of interacting with their devices. A lot of this comes from the actual design of the applications as well as the ways that the devices function.

Some general things:

• Landscape is pretty much required on Android devices
• Android apps tend to keep running when they aren't actively being used, so you need to think about this for network issues, gps, etc...
• Device Segmentation, there are tons of android devices and screen resolutions, this is where relative layouts and nine-patch images are very handy.

A big one that a lot of people don't initially think about Your UI can not be exactly the same on both devices, sure it can be similar but porting an iPhone UI to an Android Device will not work out very well.

Some reasons:

• Long touch context menus
• Menu popups
• Device segmentation causing differing resolutions and aspect ratios
• Not the same controls to work with

The back end really isn't a big deal as most of it is just implementing the main bulk of what you were working with into Java and the Android SDK. My biggest issues have come from what the User expects and UI behavior and differences, sometimes it's better and sometimes it is worse. It really just depends on what your app is doing.

EDIT

I just realized I didn't answer the actual parts of your questions, so here goes (my best shot at least)

I wouldn't say there are any big language paradigms that Obj-C devs misunderstand, I would say that Java is probably simpler to get what I want it to do from an OOP perspective. (I should say I only really work with .NET and Java and only know enough Obj-C to get by).

I would definitely use Eclipse, I tired using IntellijIdea for a while and it just gave me to many problems trying to get it to do certain things.

Answer 2

[this answer is kind of a ramble or rant. I was going to delete it but thought it might be interesting: let me know via comments if I should delete it and I will].

I don't work on Android but I do work in Java and iOS (with Obj-C). The one thing that is really different about Java development is just how much an IDE can help out (people will tell you not to use an IDE, which is a totally different take on the same thing: few people advise this with Java, however). XCode is generally unable to even CORRECTLY detect the most simple syntax errors (due to the structure of the language, I think). In Java, on the other hand, the IDE can get you moving much faster than you would be without it. You can also do really cool stuff like programming the calling cient and THEN writing the method. In Eclipse, for instance, if I type

blah.doIt(firstObj, secondObj);

and firstObj and secondObj are String instances, the IDE will give me the option to make a method with the sig "public void doIt(String firstObj, String secondObj)." That is really cool, and just the tip of the iceberg: the IDE is your friend. I've heard that IntelliJ might be even cooler (though in my trials it hasn't been).

Is there a pitfall in this answer? Perhaps it is: thinking the IDE plays the same role in Obj-C and Java. In Java, the IDE can do things that would be amazingly difficult to do yourself. The automatic refactoring, because of the way Java is, it 100x more powerful than XCode's. This means that you can postpone some design questions until later.