circleof6 for Android is out now! Download and spread the word.
Droid Development Advantages
- Java: Java is an easy to work with language that reminds you of a programmer friendly C or C++. The syntax you are used to, without the segfaults. This was my third deployment scale Java project, and each time I’ve gotten to appreciate Java just a bit more.
- Learning curve: The learning curve to develop an Android app is much less steep than iOS-partly due to language and partly due to the primitive tools (much less to learn about them).
- Deployment and beta testing: Beta test on your Android device in seconds. Deploy in 30 minutes. No review process.
- Developer account: only $25 vs. Apple’s $99, ostensibly to “keep out spammers”.
- Low bar for “success”: let’s face it, apps just look less beautiful on Droid. Whatever the cause–Google’s UX choices, device fragmentation, laziness–making an app above the expectation is a notch easier than on iOS.
- Emulator: Devices are emulated not simulated, so you can much more realistically test your app on a device you don’t own from the comfort of your computer.
Droid Development Disadvantages
- Development environment: Eclipse (Droid) vs. XCode (iOS), XCode wins hands down. Apple’s tools for developing for iOS keep getting more powerful, especially from the user interface perspective. From storyboarding to friendlier MVC oriented organization.
- Deployment: The iOS app store experience is made for it to be easy to sell and buy applications. Developers are more inclined to charge for an app, and users are thus trained not to expect things for free, and when they get them for free to be especially appreciative.
- Fragmentation: sure you can emulate your heart out, and beta test on every device you can find (I recommend the service AppThwack to supplement) but Android users update less frequently and you will have to deal with legacy APIs if you want to fully support their devices.
- UI/UX: Fragmentation on this front too-dealing with small screens to tablets, touch keyboards to physical ones presents a challenge for UX and making sure your app is pixel perfect on every device under the sun. Some native solutions (e.g. contact picking) are simply awful on Droid, and you are faced with the difficult decision of going native (what users expect) or going good (what designers expect).
- Low bar for “success”: From your icon to your UI, if it isn’t up to Apple standards, you are out of the game, even if your application has the luck to be approved. This pushes everyone on iOS to a higher standard, and the app ecosystem shows for it.
- Emulator: they are slow to start up, extremely slow, even with maxed out RAM and an SSD. Once they start, apps are slow to load. Meaning you really have to have your Android device with you if you truly want to dev efficiently.
Coming primarily from the iOS world, it was a short transition to start Android development, shorter in truth than I expected. The biggest time sinks were getting used to the constraints of relative layouts and different screen sizes and resolutions, developing an intuitive feel for what would work (while the drag and drop auto-layout worked for learning, to get things right I had to manually specify exactly the relative layout I wanted).
Ps: best practices for deliverables from an Android app designer
I found when working with our designer, the inimitable Thomas Cabus, it easiest to have him deliver assets in a shared Dropbox folder in just a drawable-xhdpi (highest resolution) folder. Then I ran a script to generate the rest of the lower resolution assets, imported the entire folder tree to the project, and we were done. Adding an asset involved one export for him, one import for me. Included here is my simple python script, which depends on PIL and having ImageMagick installed:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|from PIL import Image|
|from math import ceil|
|for asset in glob.glob('drawable-xhdpi/*png'):|
|img = Image.open(asset)|
|xhdpi = img.size|
|hdpi = [ceil(xhdpi2hdpi*x) for x in xhdpi]|
|mdpi = [ceil(hdpi2mdpi*x) for x in hdpi]|
|ldpi = [ceil(mdpi2ldpi*x) for x in mdpi]|
|for convert_factor,dir_name in [(hdpi,'hdpi'),(mdpi,'mdpi'),(ldpi,'ldpi')]:|
|os.system("convert -resize %dx%d %s drawable-%s/%s" % \|