
Android for iOS Developers - k-mcgrady
http://www.objc.io/issue-11/
======
fieldforceapp
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](http://blog.fieldforceapp.com) [1]
[http://developer.android.com/design/patterns/navigation-
draw...](http://developer.android.com/design/patterns/navigation-drawer.html)
[2] [http://android-developers.blogspot.com/2013/05/android-
studi...](http://android-developers.blogspot.com/2013/05/android-studio-ide-
built-for-android.html)

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

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

~~~
tsycho
Just see the Stanford lectures on iOS.

~~~
noconflict
Linkage?

~~~
umsm
[https://itunes.stanford.edu/](https://itunes.stanford.edu/)

------
chrisdevereux
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](http://www.apportable.com)

~~~
funkaster
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).

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

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

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

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

~~~
k-mcgrady
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."

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

~~~
k-mcgrady
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.

