Android for iOS Developers | Hacker News Reader

Android for iOS Developers

objc.io

120 pointsk-mcgrady24 comments

A good lunchtime read, thanks. A couple of misleading topics and word of advice from our own experience [0] of starting Android development after years of iOS development:

- Google seems to moving away from Activities in favor of Fragments (can someone confirm this?) so we'd recommend a Fragment based design pattern;

- App navigation paradigms seem to be evolving quickly, with Google recently introducing Navigation Drawer as a standard [1], among others;

- Choosing the navigation paradigm first seems to important as these seem to be Fragment based, using Bundle objects to share data between Fragments;

- Use Android Studio [2] because it seems a) Google is going to standardize on this, and b) the navigation paradigms are offered as app template options and can be a good starting point presumably with 'blessed' Fragment design patterns.

Good luck!

[0] http://blog.fieldforceapp.com [1] http://developer.android.com/design/patterns/navigation-draw... [2] http://android-developers.blogspot.com/2013/05/android-studi...

I thought the Navigation Drawer was no longer considered a best practice. I wanted to move to it on my iPhone app but I read a couple of blogs that claimed it wasn't good.

It's hard to do good phone nav.

Your Fragment subclasses is where your code that interacts with the user should be (the code that used to be in your Activity subclasses). Activity should contain Fragment objects by means of loading a layout.

The cool thing about Fragment is that you can organize your Fragment subclasses using different layout files, and you can organize the layout files using resource qualifiers. That means that Android is picking your layouts, and the number and layout of Fragment objects on a particular screen geometry, for you, instead of you having to write code that groks screen size, density, and text size.

I dislike navigation drawers almost as much as I disliked the now deprecated "dashboards." It is a place where you can do nothing but go some other place. If you have that big an app, I suppose it's OK. But making navigation a natural part of, say, picking an item from a list, or picking a menu item is preferable. Nav drawers look better than dashboards, but if you consider them from the user interaction PoV, they are the same.

Yes to using Bundle objects to move data. That's how sending data to a Fragment is independent of whether it is in the same Activity or not.

If anyone has iOS 101 for android developers, please comment. I haven't been successful in finding a good one. Google doesn't help. Hell, even bing doesn't help.

Not a course, but maybe you can find this tool useful:

https://code.google.com/p/java2objc/

java2objc is worse than useless. generates shockingly verbose and complicated code and can't be used for UI stuff obviously.

Just see the Stanford lectures on iOS.

Linkage?

https://itunes.stanford.edu/

Good idea, perhaps this should be the next article! However, in the meantime, you can look through the sample project here: https://github.com/smbarne/AndroidForiOS. It implements a simple app on both platforms, and it should give you a good overall idea for iOS based on the Android code.

I'd love to read a writeup by someone with experience using Apportable[1] to develop an Android app. How closely does it mirror the behavior & performance of UIKit, does the iOS programming model translate well to Android, etc.

[1]: http://www.apportable.com

I'm currently porting a game with very little UIKit (i.e. cocos2d v3 plus a couple of native UIKit elements for user interaction beyond the game), and as I understood it apportable is mostly for porting games. If you want to do UIKit, you need to contact them to get access to the proper SDK:

"XCode interface builder files can be decoded by Apportable. We have several flavors of UIKit available, so if you are building your app in UIKit, contact us to get an appropriate version of the SDK."

http://docs.apportable.com/supported-files.html#interface-bu...

However, I did never really look into it. If they were to fully support UIKit, it would indeed be a great way of also supporting Android for certain types of apps.

It doesn't. For me, it works only if you have an OpenGL game and use a few of the native API.

If you're building a UIKit app, it doesn't work at all: broken support for almost everything.

To be fair, I think they are rewriting the UI layer, but after working almost two years in several cross-platform projects, I decided that for anything that's not a game (no custom UI), it makes no sense if you want your app to look "good" in all platforms. Just rewrite it (at least the UI layer).

Did the Foundation-level stuff work ok for you? Did you try to use many third-party libraries?

Being able to keep all the logic and networking stuff intact would be a big win when porting iOS -> Android even if the UI needs rewriting.

It's one of the things we are working on by making the UIKit layer is optional. There is a library called BridgeKit that makes dealing with Java <->Objc easy without JNI so making code go back and forth is trivial. We are also building a version of the platform that even trims off Obj-C as a better NDK for C++ developers that want to target Android from Xcode.

Yes, the foundation part is fairly complete. Like I said: if your game/logic is written in Obj-C and it's in OpenGL, it should be ok.

If you have a lot of UIKit-intense parts (semi-complex xibs, anything related to Autolayout or Storyboards), then you might need to rewrite them.

NOTE: my comments are based on what I experienced with a UIKit only app a few months ago.

Portability frameworks are OK for games, but not for non-trivial non-game apps. If you need an expedient implementation, in most cases I would go for a Web wrapper rather than a portability framework. <-- Advice does not apply to games.

I just started in on the Android version of the iOS app I'm working on. Wish I had this resource two weeks ago but wasn't too terrible finding this all out on my own. Was actually thinking of compiling a sort of left/right list of iOS/Android equivalents with visuals/code examples but don't think I'll get around to it. How many people would be interested in something like that? (if it doesn't already exist?)

So far nothing stands out too greatly from the iOS development experience. But I haven't finished the Android yet so I still have to look forward to seamlessly releasing to the Google Play store without having to jump through any of the inefficient hoops that Apple has.

I was really sure this was going to be an April Fools' Day joke. Still not sure if it is.

From the email announcing this issue:

"Although this started out as an idea for an April Fools' joke, it matured into a really good issue about Android development for Objective-C developers. After all, it's interesting and instructive to learn about what developing for the other major mobile platform is like."

As an iOS developer clicking this link, I was expecting a introduction to various pieces of Android, each with more details linked. This page is just a bunch of links with no context. Why are the items in reverse numerical order? Anyways, it is currently a bad landing page. I bounced.

Here is the link to the actual article: http://www.objc.io/issue-11/android_101_for_ios_developers.h...

objc.io is an online magazine. At the top you are seeing the latest issue, which is #11. The links immediately below that are the articles in this issue.

Once you go below the most recent issue, you are seeing the past issues, which is why they are in reverse order - most recent to oldest.

As someone else said it's a monthly magazine for iOS developers. This month they are covering Android. I decided to link to the magazine rather than a specific article. The title of the HN post is taken from one of the articles in this issue.

Reply on news.ycombinator.com