Android Development Tips For iOS Devs
stuartkhall.com
stuartkhall.com
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.
Its exciting really. You see similarities and you also see differences. I think this helps more than it hurts since these "new ideas" will help me with the other environment (and vice versa).
This actually got me interested in learning other languages/frameworks (php, haskell, ruby on rails). After I get the hang of Android, I want to play around with an iOS app from scratch. Sure, I could use some conversion software to do this job. But, I'd rather not. I like to understand what's going on under the hood. I guess its the CompSci in me.
I guess what I'm saying is that I think it is so much better to have a universal understanding of these technologies then to blindly stick to one "team".
As an aside...didn't Facebook mentioned they used PHP not because it was "better" but because it happened to be the technology that worked for what they were doing at that time?
http://programmers.stackexchange.com/questions/134746/whats-...
Genymotion is a decent alternative to the 1st party emulator, it runs significantly faster.
However, Genymotion is x86-based, so ARM libraries you use in your app that are designed to run on an ARM device will not work in Genymotion on your computer. However, if your use of those is limited to just a few Activities in your Android app, you should be able to do a lot of things with Genymotion, and just tiptoe around trying out that Activity on your computer and instead use it on-device.
That's also because deploying an APK on a test device (or several devices) is way easier than deploying an IPA on an iOS device.
As someone relatively new to iOS this past month or so, I was shocked by the number of hoops I have to jump through just to take a piece of code I've written and put it on a device that I own and is sitting right next to me[0].
Coming from Android development, I never thought twice about this - it's easy to push the APK to my phone as part of the build process, and I don't even have to plug my device in to do so.
[0] Including shelling out $99 for a certificate that gives me the permission to do so.
- create provisioning profile(s)
- hit refresh in Xcode and hope it pulls in the profiles you want to use (maybe only an issue if you're a member of multiple teams)
- modify build settings
once you've done that its simple but there is definitely a setup overhead with Xcode and devices
The point is that the original comment is flat out false.
The original point was that there are steps to go through, and creating a paid developer account is a non trivial step
> That's also because deploying an APK on a test device (or several devices) is way easier than deploying an IPA on an iOS device.
False.
> it's easy to push the APK to my phone as part of the build process, and I don't even have to plug my device in to do so.
Also true of iOS.
If you want to make the case that enrolling in the developer program is a hassle, that's fine, but it's misleading to make it sound as though that is part of the build process.
This works on any number of devices.
You need a Google Play Developer account in order to distribute through the Google Play store, but you can directly install an application on an unlimited number of devices for free without ever signing up for an account. This is not possible on iOS without jailbreaking every phone.
Android also has a plethora of debug options hidden in a special device settings menu that can be hugely helpful for troubleshooting performance issues.
I'm porting an iOS app to android right now, and android is way behind on the development side of things.
On the other hand, having iOS connect easily to a debugger disproves nothing I said.
I shouldn't need a computer attached to get screenshots for my app. Power + home button, or cmd+S in the simulator.
Even my users can easily send me screenshots, some of the time unprompted even.
I would highly recommend using Android Studio + Gradle over Eclipse. IntelliJ is a significantly better tool for writing and refactoring code than XCode. Some of the tight integrations between XCode and the phone are superior (especially around profiling), but overall I think IntelliJ is a much stronger tool. Even something as simple as doing layout is vastly better on Android. There is no choice between 'in code or in Interface Builder'. XML + the viewer in Android Studio is the best of both worlds.
I also think Relative Layouts accomplish 99% of what auto layout accomplishes in a much friendlier manner.
And you only need a tax ID if you're trying to imminently release a paid application or an app with IAP. But we're discussing development, not release.
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.
I'd recommend reading up on the ViewHolder pattern in this context.
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.
Watch http://youtu.be/wDBM6wVEO70?t=9m50s - very informative
@property (nonatomic, strong) id context;
or
@property (nonatomic, weak) id context;
if you are sure the context will always exist.
Number of times I have used view tags: Once.
http://blog.xebia.com/2013/07/22/viewholder-considered-harmf...
I refactored all my code after reading this, and now I consider the ViewHolder an antipattern.
It is incredible how much cleaner and readable my codebase is with custom views. And the performance is the same.
With its "native" emulator, yes, but there are better alternatives like Genymotion. Giving up on them is not good development advice.
It's not a coindidence that it is recommended by very talented developers such as C. Mottier: http://cyrilmottier.com/2013/06/27/a-productive-android-deve...
This makes automated testing impossible on the simulator, whereas in iOS I can run my full test suite (400-something tests) in the simulator in a couple seconds.
Also, there's the case sensitivity - iPhone Simulator is not case sensitive (maybe depends on your filesystem settings), while the device is case sensitive. This can be really annoying the first time round.
[0] http://software.intel.com/en-us/android/articles/intel-hardw...
* 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.
* For log alternatives, checkout Timber by Jake Wharton (https://github.com/JakeWharton/timber)
* I would suggest using the Build.VERSION_CODES when making the check against which version of android the device is (http://developer.android.com/reference/android/os/Build.VERS...)
alias lc="adb logcat | sed -e $'s/^I.*/\e[0;94m&\e[0m/g; s/^D.*/\e[0;92m&\e[0m/g; s/^W.*/\e[0;93m&\e[0m/g; s/^E.*/\e[0;91m&\e[0m/g'"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.
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.
If you're writing a new app, you can probably exclusively target iOS7.
iOS cons: The device limit. This makes deploying apps to your users more difficult than it should be. Xcode is also an extremely weak IDE, but AppCode makes up for it.
Android pros: Faster iteration with releases, because no review process. You're also less likely to fight app review for dumb shit.
The nexus 5 is only ~$420 with shipping.
Intelli-J support.
Android cons: Emulator is for all purposes unusable. You will need to buy a device. Fragmentation of the OS across all devices.
At least on Windows it is quite usable for OpenGL ES emulation, when using Intel's virtualization driver.
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+.
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).
This is very well documented.
[1] http://stackoverflow.com/questions/15039913/android-how-to-m...
Two more things:
1. The wormy scrollbar is actually standard on Android: the messaging app does it, IIRC even the twitter app on Android does it. So even though your iOS experience tells you it's weird, any users of yours on Android likely won't notice.
2. If your items are all the same height then your scrollbar won't be wormy. So if this is really that important to you, then make your ListView return items that all have the same height.
Can you expand on that? Do you mean that it's expensive for the OS for some reason, or do you mean that it's expensive for your (client) code to compute the height of each item?
It seems like in most cases it's a simple method like "return isHeader : HEADER_HEIGHT : ITEM_HEIGHT;"
To calculate the scroll accurately you need to calculate the height of 1000 elements to get the full height.
Instead in the common scenario you just calculate the height of the rows displayed on the screen and estimate the height using the average and the count.
For something completely client side it is possible either to specify a fixed height or change the smoothScrollbar attribute of the listview (it is more expensive though and not used very much).
Nobody complains, I guess everyone is just used to the way it is. :D
In other scenarios (contact list, list of artists and albums and songs) you know the height of an item from its type, and you can just return (one of a set of) constants like I said. That shouldn't be expensive at all.
So, as screigh said, you won't have the wormy effect on contact list, artists, songs, etc. because each row is always x pixels. The same happens if you have for example a series of thin and thick rows because they average out.
Another reason why using a set of constants is not common is that we have different screen sizes and different resolutions to deal with, so what looks like a good value for a resolution might not be the best for another.
> There is also the excellent Genymotion emulator.
Genymotion deserves to be mentioned in a top level comment. It's the by far the fastest Android emulator and it works brilliantly simple.