I recently went in the opposite direction (Android -> iOS). Forget all of the flame wars. If you know one, dabbling in the other is a great learning experience. The two platforms are running roughly the same hardware and facing roughly the same challenges, and the software architects at Google & Apple have chosen different ways to solve the problems.<p>Sometimes the patterns feel similar. You can rig up an iOS tableview/data source delegate/fetched results controller to look almost exactly like an Android listview/adapter/loader. But in other areas they function completely differently. It is well worth the time spent learning the other IDE and language. My Android app is better because of what I have learned in iOS and vice versa.
An important correction: Unlike iOS, Android does not come with a simulator. It has an emulator. That explains many of the differences in startup speed and performance. A simulator runs natively and does not have to emulate the ARM machine code on your x86 device. The Android emulator is theoretically more accurate and runs the entire Android OS, but the cost penalty is huge. Therefore, most Android developers test small changes initially on a device.<p><a href="http://programmers.stackexchange.com/questions/134746/whats-the-difference-between-simulation-and-emulation" rel="nofollow">http://programmers.stackexchange.com/questions/134746/whats-...</a>
"A trick often used by iOS devs is to use the tag of a view to hold lookup information, such as offset in arrays. With Android you can shove the entire object into the tag; pretty useful."<p>Yes, but if it's something like a ListView, don't put offset in array there, because the views are recycled (when user scrols), so you're likely to end up with corrupted data. I got bitten by this in the beginning. You can go to great lengths to prevent this from happening, but it will be hard for a reason, because that's abusing the design principles.<p>I'd recommend reading up on the ViewHolder pattern in this context.<p>Long story short: cache all the references to all specific sub-views of the row view in the tag (so you don't have to retrieve them again and again) - that's good practice. Just don't store any position-specific data in it.<p>Watch <a href="http://youtu.be/wDBM6wVEO70?t=9m50s" rel="nofollow">http://youtu.be/wDBM6wVEO70?t=9m50s</a> - very informative
"I used to think the iOS simulator was painful, now I realise it's pretty awesome. Skip the Android simulator all together and deploy to a real device, or be prepared to spend a lot of time waiting."<p>With its "native" emulator, yes, but there are better alternatives like Genymotion. Giving up on them is not good development advice.
You can get a pretty responsive emulator if you use an x86 ABI and HAXM[0].<p>[0] <a href="http://software.intel.com/en-us/android/articles/intel-hardware-accelerated-execution-manager" rel="nofollow">http://software.intel.com/en-us/android/articles/intel-hardw...</a>
Some things I would note:<p>* Do not use getBaseContext() like he does when he created the new Activity. Use getApplicationContext for most things (unless an Activity is required) as this is guaranteed to be the same throughout the lifetime of your application.<p>* For log alternatives, checkout Timber by Jake Wharton (<a href="https://github.com/JakeWharton/timber" rel="nofollow">https://github.com/JakeWharton/timber</a>)<p>* I would suggest using the Build.VERSION_CODES when making the check against which version of android the device is (<a href="http://developer.android.com/reference/android/os/Build.VERSION_CODES.html" rel="nofollow">http://developer.android.com/reference/android/os/Build.VERS...</a>)
"Tag
A trick often used by iOS devs is to use the tag of a view to hold lookup information, such as offset in arrays. With Android you can shove the entire object into the tag; pretty useful."<p>No.. Just no. That's considered really bad form. The tag of a view should not be used (Abused) to hold an index etc.. that is linked to the data set.
If you're commenting on the ease or difficulty of building iOS/Android native apps in this thread, and you aren't actively building an app for both or have built one before, you probably don't know what you're talking about.<p>The eco-system for building and deploying apps on both sides has gotten way better in the past couple years. There are pros and cons to both sides of development.
UIViewControllers fall somewhere between an Activity and a Fragment.<p>In particular if you use any kind of view controller containment (custom container view controllers), you can only do that with fragments, and only then with Android 4.0+.<p>As someone who's looked at building tablet apps, the containment is a good thing to consider. In these cases, iOS makes it easier to combine your existing view controller hierarchies, while there are some idiosyncrasies (only 1 action bar across the top of a "split view controller") on Android still that don't always make things easy (in my opinion).
"When the user rotates the device your activity is completely reset"
You just need to set " android:configChanges="orientation|keyboardHidden" in the manifest.<p>This is very well documented.
My experience with ListView was... weird. It doesn't ask you for a height for each row like UITableView does, just for a row count. Then, it measures your views as you return them. This meant that the scrollbar was completely unreliable, it would resize based on the height of the currently visible views. Is there an obvious way around this that I'm missing? ListAdapter doesn't have anything for specifying height.
If you want a sort of CoffeeScript experience instead of Java you can also go with Xtend [0]. It's supported best in Eclipse but I do find the cleaner syntax a bit more pleasing to work with. It's only transpiling to Java so you can even mix it with Java while updating an existing codebase or for whatever reason.<p>[0] <a href="https://www.eclipse.org/xtend/" rel="nofollow">https://www.eclipse.org/xtend/</a>
> Nemisis7654 said: (<a href="https://news.ycombinator.com/item?id=7391380" rel="nofollow">https://news.ycombinator.com/item?id=7391380</a>)<p>> There is also the excellent Genymotion emulator.<p>> <a href="http://www.genymotion.com/" rel="nofollow">http://www.genymotion.com/</a><p>Genymotion deserves to be mentioned in a top level comment. It's the by far the fastest Android emulator and it works brilliantly simple.
If you looking for an simulator instead of an emulator I would can recommend genymotion. (<a href="http://www.genymotion.com/" rel="nofollow">http://www.genymotion.com/</a>). It's VirtualBox based and incredibly fast.