Indeed. There is a fine line between sharpening the saw and procrastination. What usually clears it up is drive. It would be handy to have a ghost from our grandparents generation at our shoulder when we are about to go off on another whinge about an imperfect world who says "Get on with it!"
That's a fair point, but if your goal is to create something that people will pay for, targeting a popular platform with an infrastructure based around Java, what will having an opinion about Java buy you? Very little. You can like it, or you can not like it, but you'll have to use it anyway, so your time would be better spent thinking about something other than how much you like it or (as is probably more likely...) not.
Were all results of people challenging the status quo of language/platform capability. Developing new languages/frameworks/platforms is NOT unproductive, and has proved very successful in the past.
While java may not be a good excuse to avoid android, it's certainly a good excuse to improve upon the stack (as another commenter suggested, strapping Scala to it would probably be a huge productivity win).
Alas the OP took a pragmatic approach and just built the product. That's fine, but it isn't "better" than someone who (rightly) thinks java is junk and attempts to improve it.
While a fair point, I think expressing your dissatisfaction will let others know there is a market for a better solution. And potentially drive more innovation
... but that could be me post-hoc rationalising my whinging :D
Not really. The jruby guys have made a language very close to ruby that doesn't use any libraries, if you can live with them, there is Scala, also jryby, etc.
There have been quite a few articles before that just cast Android in a more negative light then it deserves.
I develop both iOS and Android apps and this article is the first one I wholeheartedly agree with.
Both platforms are obviously going to have some gloss and some warts, but in the end comparing the two in a zero-sum fashion is like arguing vanilla is better than chocolate.
As an iOS developer, this is probably the best comparison between iOS and Android development that I've read. I'm pretty scared of Eclipse and the slow-as-hell emulator doesn't sound fun, but coding layouts that don't involve lots of "how tall is this text for this given width?" calculations is a welcome addition.
The emulator is very slow indeed, but they talked about it at I/O and they said they will improve it this fall with hardware acceleration (they think lack of it was the biggest issue). Another smaller issue would be that the Android emulator is basically running "ARM hardware" on top of x86 (it's not just a fake simulator like the one for iOS).
They're also bringing a new UI builder this fall. They talk about all of that here:
Run adb install and adb uninstall from a command terminal to get a little bit faster deploys.
We almost never run the debugger in Debug mode, we run it in Run mode (any runtime errors you can debug later from the stacktrace and how you got there)
Wow, thank you so much for that information about the new UI builder... it looks awesome. Do we have anything more specific than just "fall" about the release date?
Note what you quoted. He said Android emulator this could be emulating just the OS portion of Android with a jvm that targets x86. Instead they ship an actual ARM emulator and do not emulate Android. From what I understand of iOS development they do it the other way. They compile to x86 and emulate the iOS system calls. They don't emulate an ARM and run the real iOS on it. Therefore the Apple way is a little fake, it is possible for behavior to differ between emulated iOS and real iOS. When you run the android sim there is no possibility of stub vs real OS differences, you are always on the real OS.
edit: Basically it boils down to too little context around the words emulated vs simulated.
> He said Android emulator this could be emulating just the OS portion of Android with a jvm that targets x86.
That's exactly what the iOS simulator does. It would not be an emulator in that case. It would be a simulator. Like the iOS simulator.
> From what I understand of iOS development they do it the other way. They compile to x86 and emulate the iOS system calls. They don't emulate an ARM and run the real iOS on it.
Hence being a simulator.
> Therefore the Apple way is a little fake, it is possible for behavior to differ between emulated iOS and real iOS.
It's not fake, it's a simulator. That's the whole point, and that's why it's called "simulator" not "emulator".
The iOS Simulator is specifically refereed to as a simulator NOT an emulator. It simulates the iOS on top of OS X and makes no attempt to be an emulator. It is a decent simulator.
> and the fact that he didn't even read what he quoted.
Of course I did. An Android emulator can only mean Android running on top of an ARM emulator, otherwise it's a simulator (like the iOS simulator). Emulators are always about hardware unless otherwise specified.
An Android emulator can only mean Android running on top of an ARM emulator How so? Android supports both x86 and ARM. I would have thought x86 on x86 would be the way to go since it has been done before with good performance. Heck they wouldn't even have to write anything just ship a customized virtual box or QEmu.
The current emulator _is_ QEmu. However, the current problem is not arm emulation, but moving pixels in software. You will notice, that the more you increase resolution, the more the performance drops.
The Google IO talk linked in this thread addresses this point, so hopefully in Autumn the emulator will be usable (especially at tablet resolutions).
I jumped into Android development about a month ago, and after a slow start its really been fun. I hated Eclipse at first, but it gets a lot better with time.
The emulator though - don't bother. The author is not exaggerating about several minutes to load. Just buy an Android phone and debug on that, or you'll spend more time cursing at the emulator than coding.
I mostly use real Android devices for developing and debugging. However, another alternative is running Android-x86 in a VirtualBox. (If you aren't trying to test native ARM code, of course.) It's very fast, and I use it sometimes to test different screen resolutions and DPI's.
I've found that booting the emulator does take a minute or two (I don't know about "several", but that's besides the point), but you don't have to restart every time you make a change or anything. It's just a once-per-session thing unless you accidentally close it.
My experience has been that it takes much less time than that, probably somewhere in the area of 5-15 seconds. I've only worked on tiny personal projects though; maybe this varies a lot based on project size.
My experience has been that it takes much less time than that, probably somewhere in the area of 5-15 seconds. I've only worked on tiny personal projects though; maybe this varies with project size a lot.
To me it still doesn't matter. It could take one second to load a binary, the emulator is completely unusable they way it currently is built. Android is already into it's 3rd revision and they somehow have managed to completely ignore this pink elephant.
If the best advice you can tell people is not to use it, use a real device then why bother include it at all.
It's true. The first time I ran the emulator it took a good 5 minutes to boot up. But because it took so long, I thought my computer froze or that I had made a mistake in installing the SDK since I had usually given up after waiting 30 seconds for the emulator.
Eclipse itself is _reasonably_ fast once it's loaded (occasional disruptive GC pauses aside); I think he's talking more about the (hideously slow) Android emulator.
If your scared of Eclipse spend some time with IBM WebSphere Developer workstation (Eclipse underneath, smothered with 10,000 "best in class plugins)[NOT an exaggeration]. Eclipse seems downright zippy in comparison!
Full disclosure... I develop using Eclipse every day.
While the emulator may be slow, it's got a lot more features than the iOS simulator. The Android emulator, for instance, has built in support for GPX tracks for the GPS, very useful for location-based functionality. There's an iOS lib for it but it's not quite the same.
This article was damn near perfect. I much prefer this style to "the problem with X" or "Why X will never succeed". This person isn't interested in platform evangelism, he/she wants to ship. A very inspiring attitude to have.
Seems like a very balanced article to me. The comments about Eclipse made me laugh (I just had to start using Eclipse for a different reason and hate it with the heat of a thousand suns).
Using Eclipse gets better as you get more comfortable with its peculiarities. I think the author did a good job of summing up the Eclipse experience--there's a lot to hate, and a lot to like. After using Eclipse for several years, it still has that "designed by committee" feel, but I do find myself missing some of its features when I'm using other environments.
I've actually been using the PHP... perspective?... for Eclipse and have found it to be pretty decent. (The author is right, some of the terminology is amusingly abstract.) Configuring the program just-so and learning to accept the slow boot-up are spot-on assessments.
That said, I should take some time to look for another IDE that captures the basic advantages of Eclipse. I'm mainly interested in having a panel with the project's directory structure, intelligent navigation (e.g. Ctrl-click on a function call to be taken to its definition in another class), and decent code completion and syntax checking. I might even be willing to pay for it.
> Android has a system of layout containers (similar to HTML)
It would be more correct (I think) to say it's inspired by other Java layout managers, Swing and SWT aren't a million worlds removed from Android (but I can't really expect someone new to Java to know that!)
And the emulator. The Android emulator is not slow. I have a netbook, which is an absolutely fantastic way of finding out which applications do far too much but you never notice because your computer is very fast. Team Fortress 2 is slow. Eclipse is slow. I tried booting the Android emulator and gave up waiting after an hour and a half.
Overall, awesome article. Refreshing to see someone providing a useful comparison between the two rather than arguing over one or the other, and as a Java developer who knows a little about Android, I feel I just learnt a lot about iOS. I'm actually amazed at how much they have in common, you wouldn't think so from the arguments!
Anyone who's used both IntelliJ and Eclipse as IDEs for Java development knows what I'm talking about. Eclipse, like Android, emphasizes "openness" and customizability while IntelliJ, like the iPhone, emphasizes "It Just Works" coherence and integrity.
If you like IntelliJ's approach, you might want to try AppCode, a development environment for Objective C made by the makers of IntelliJ, JetBrains. http://www.jetbrains.com/objc/
It's funny that he wrote off all the other IDEs in favour of Eclipse which requires more setup than to do Android development than IDEA does. Even if I didn't hate Eclipse it'd be hard to argue with "1. Install IntelliJ, 2. write your code".
Totally agree with the other comments. This is the first honest and realistic writeup about "Android vs iOS development" I've read.
I started with Android myself and started porting an Android app (which I wrote) to iPhone and I had exactly the same problems iOS developers have when starting with Android. So it's just a matter of what you're used, too. From my experience some things can be done quicker on iOS, others on Android. However, that doesn't necessarily mean better, because providing a framework for a special case usually comes with the cost of restricted flexibility.
I also agree that Eclipse is a behemoth and quite overwhelming in the beginning, but there is a great tool for any code base that is larger than your typical pet project. Especially when having to read, understand and trace down other people's code.
iOS developer here. Releasing first android version of my app this week. Even though I didn't do the coding, I've taken a look at the code and done quite a bit of testing. The part about animations is totally true. Animations are much faster and smoother on my iPod 3rd Gen than the equivalent animation on a Droid Incredible, which has much better hardware! We've tried to optimize as much as possible, but we are realizing that there is just no way to match the iOS version's speed and responsiveness.
The biggest complaint seems to be that Android is software rendered. As of 3.1 (i think, maybe 3.0) this is no longer an issue as a single line in the manifest will cause Android to automatically accelerate your drawing if possible.
It works pretty well... except for software input method (the other name for the touch keyboard).
A simple example: make a webview that scrolls down and ends with a textfield a couple screens below. Activate Hardware acceleration, scroll, touch the textfield, boom, the textfield remains below the keyboard so you don't see what you type.
Deactivate hardware acceleration. Do the same test. Boom, the screen pans up and the textfield is visible.
Once you've done this on a xoom, try it on an iconia or whatever other tablet you have.
What a great comparison. Admittedly I haven't researched this but I was surprised to read that the UI components in iOS were based on OpenGL. That's pretty cool! Hats off to Android for their layout manager. I like when I use an app on Honeycomb that scales well as opposed to blowing up the pixels to fill the screen.
Question to Android devs with iOS experience: are there any tools available which would be counterpart for Instruments?
Instruments do not get mentioned in these comparisons for some reason, I think these are great tools to debug and improve performance.
Interestingly (but inevitably) as a java developer who first learned Android and then moved to iOS, the sticking points he mentions are exactly the same ones I found, but the other way around.
I think Eclipse makes sense if you think like a java coder, Xcode not so much, and Objective-C will fry your mind...
That said, Eclipse and the Android SDK is a pain to install even if you are a java wizard.
"That said, Eclipse and the Android SDK is a pain to install even if you are a java wizard." Why? I just followed Google's instructions and it was breeze to install Android SDK...
My first install went pretty well. Then I upgraded my Linux box and installing it didn't go well. So I upgraded to the newest Eclipse and it worked okay.
Then I upgrade Eclipse and it broke, so I went back.
Then I tried to install it on Windows and it was so painful that I just gave up and remoted into my Linux box.
Recently, I tried Windows again and it went like a dream.
Installing Eclipse and Android SDK should be easy right now, but they weren't always.
>That said, Eclipse and the Android SDK is a pain to install even if you are a java wizard.
Really? I don't remember it being too bad, and I didn't start learning java until I had them installed! Although this was just a year ago, so perhaps older versions were less friendly.
ObjC's main "frying" factor is that it uses a different (and to my mind, superior) set of object-oriented patterns as primary abstractions. For example, subclassing is much less common in ObjC than in Java, preferring to use the less complex delegation pattern as opposed to subclass-and-implement patterns for behavior extensions.
Another problem some people have is that ObjC brings to the table all the pain of C. You've got memory management and bounds checking and unsafe casts all dumped into your lap. It can be pretty painful if you're not experienced in C, C++, or ASM programming.
I might be biased as well since I learned smalltalk+ruby about the same time prior to objective c. I personally find smalltalk derived OO much less painful than the java/c++ counterparts. But thats just my opinion, they both get the job done in the end.
I'm curious how it fries your mind exactly? Fries like Haskell in that it makes you learn different paradigms or fries as in challenges base assumptions on how things like OO/etc... work?
Nice overview. I have to disagree with the assessment of Eclipse though. Under one app you can build and debug Java, Python, Ruby, HTML, Javascript, and Air apps. Once you get used to the workflow, it's incredibly productive.
As for the emulator, unless you want to invest in a large set of devices, it's the only way to test against different screen sizes and device profiles. Even though it's nice to have a device for debugging, you'll need to make peace with the emulator to make sure your app doesn't go all wonky on devices other than your exact model.
Thanks for this article it just made me feel happy. I so tired of flame wars regarding IOS x Android that I barely read Engadget anymore. Many people dont understand why I have a Macbook, an Android phone and an iPod, looks like you MUST took a side and be an evangelist.
"It takes the Android Emulator ~2 minutes to boot up on my perfectly-modern machine. But what really hurts is the edit/debug cycle. Every time I change a bit of Java and need to rerun the app, it takes about 30 seconds to redeploy and start up in the Emulator. Compare that to 5 seconds on the iOS Simulator. It may not sound like much but remember you’ll be doing this hundreds of times throughout your day."
I do not have any experience with iOS development but I can vouch for how hard it is to use the Android Emulator. I just recently submitted an Android application for a programming course and if it were not for having an Android mobile device to replace the emulator I would not have completed the project in time. The Emulator is slow and buggy and made it hard to test new code.
If you are interested in developing an Android application deffinately check it out but take this guys advice and get a device to test it on. It will save you a lot of time.
Every time I change a bit of Java and need to rerun the app, it takes about 30 seconds to redeploy and start up in the Emulator. Compare that to 5 seconds on the iOS Simulator. It may not sound like much but remember you’ll be doing this hundreds of times throughout your day."
Is there no practical way to reduce this by using unit tests? I understand if you're doing UI tweaks but otherwise it seems far more efficient to do targeted testing.
> Apple has made it pretty easy to start writing iOS apps. Of course, Step One is “Buy a Mac.” Easy! Then just download the free Xcode Installer from the Mac App Store, and start writing code when it’s done.
> Android is a bit more involved. You can download the SDK easily, but to actually start writing code, you’ll want to setup Eclipse and install Google’s ADT Plugin.
Buying and setting up a new computer is "Easy!" but installing Eclipse is "more involved"? Having to sign up for a $99 developer program is omitted. The size difference, of a couple hundred mb for Eclipse vs 4gb for Xcode is omitted.
You don't need to sing up for develper program to start hacking for iOS. But if you want to run your code on real device or make it available in App Store you will have to do that.
Setting up new Mac is really that easy. You can just launch Mac App Store application, press a button to download Xcode and when it's done lauch the installer.
I hate to be picky about this but in all the time I've been doing iOS development and throughout everything I've ever read I have never seen anything to suggest that iOS using OpenGL for all of it's drawing (simulating a 2D interface in a 3D environment like the article suggests). Drawing is done using the Quartz system and animation is handled by Core Animation (which creates "an illusion of motion").
UIViews are basically event-handling abstractions above CALayers, which in turn are a relatively thin abstraction above common OpenGL actions. Core Animation simply manipulates these layers in the hierarchy, of which there are three per view: model, presentation, and render. The model is the one you interact with. When you change the location of a view, it changes the model, which is then reflected in the presentation. When you animate, it tweens from the beginning state to the end state. Fun fact: when you start a new animation and start it from the current screen state, it uses the presentation layer, instead of the model layer. If you don't start the animation from the current state, this is why you might see jerking - it tweens from the model layer instead of the presentation layer.
The render layer, the last of the three, is rendered by the render server, which is hardware accelerated, and shown to you. Fun fact: CALayer's renderInContext runs on the CPU, whereas UIGetScreenImage uses the render server, which is why it's so much faster - it runs on the GPU.
My understanding is, "drawing" (in-view composition) is largely, if not completely, software (Quartz2D). Composition between views is (can be, at least) handled by the GPU; and that may well include animation of views. I don't know how absolutely accurate it is to say that such composition 'uses OpenGL'. It may use hardware that provides OpenGL functionality, but that isn't quite the same thing (Quartz composition could talk directly to the GPU using it's native command format for instance).
Why do you "have to kiss that silky smooth scrolling goodbye" if you setup your UITableViewCells in Interface Builder?
I've used it for all of my apps and the scrolling is just as fast as any of Apple's native apps. Interface Builder just packages up all that initial layout code and then it is executed when the nib when it is unpackaged. After that there is no difference.
Actually there is a difference. If you create a table with a considerable number of cells (say, over 20) that contain a couple of labels and maybe an image when you swipe really fast the scrolling will hang, even if you are using the dequeue mechanism.
The alternative is to paint the contents of the cell manually (that is without using UILabels and the such) using CoreGraphics.
If you had twenty different UITableViewCells in a nib that had twenty different pictures then I admit the loading of these cells will cause the scrolling to stutter if you do it in cellForRowAtIndexPath:.
However I just finished an application with a UITableViewCell, defined in a nib, that had 3 labels and a image. The labels depend on the data that the row was displaying and the image was the same in every row (it was a custom disclosure image).
One of the table views that that used this cell had 100 rows and it loaded and scrolled without a hitch.
Most of the slowdowns people experience with scrolling is if they have transparent cells and/or they don't load lazy load images on a background thread.
I agree that if you've tried all sorts of optimizations and you are still experiencing slow scrolling then painting the contents manually will probably be faster but it is IMO more work then 99% of people need to do and, like naz said below, there can be accessibility issues.
When Loren Brichter wrote that 3 years ago it was a much bigger deal. The iPhone 3G was extremely underpowered compared to most of the devices people run iOS on today.
If you avoid transparent view backgrounds (just give labels a grey background if your cell has a grey background) and disk reads then you can make fast UITableViewCells without having to resort to drawRect. You should also avoid things like layer.cornerRadius and allocating lots of objects (such as NSNumberFormatters) in cellForRowAtIndexPath.
That said, if you get frame skips after all that then overriding drawRect for the content view is a great way to speed it up. You have to be careful to keep your app accessible though, since the view has no labels for the screen reader to read. And orientation changes can look awkward.
I also don't think it's particularly hard to do the x,y frame setups either. Just start by drawing boxes on a piece of paper. Figure how things interrelate, make the code, tweak the margins.
I agree. It's not the frame setup that sucks when compared to Android. It is the layout containers that Android has.
Setting the origin of a view in iOS vs Android is going to be approximately the same amount of code (whether it be Objective-C or XML) but it is the layout containers that save you from writing all that boilerplate code when the size of the parent views change.
He did make a good point of being able to preview your XML. I would kill for the ability to do that with iOS.
Interface Builder needs to go the way of Expression Blend where you aren't writing plugins that allow you to edit all the properties of a UIView. Interface Builder should scan all the possible properties of a UIView and then allow you to modify them.
If you're starting Android development, just save yourself the pain and just use the IntelliJ IDEA community edition.
The Android plugin included doesn't have fancy UI stuff, like for designing interfaces or visually editing the XML configuration files, but it does have code-completion of XML tags and properties and it works better as a code editor, being less painful.
I've tried doing that, but whenever I'm actually doing work on Android app a really large percentage of my time spent is done working on the UI. Not having the ADT tools for the UI just doesn't make sense to me.
Wow. I never expected that much negativity for the Android side. I've dabbled in both but haven't done Android since over a year ago. I was (and still am) really looking forward to using Eclipse and reading Java. I just get very tired of XCode.
Clicking their site http://www.meridianapps.com/ leads to "App Engine Error: Over Quota. This Google App Engine application is temporarily over its serving quota. Please try again later"
I "learned" Java in college, but didn't use it after graduating in '02. I was quite pleasantly surprised by all the (new to me) stuff like "anonymous inner classes," and ultimately I've come to respect the staunch minimalism of the language overall.
If you were finishing college in 02, the anonymous inner classes should have been there; I'm pretty sure they showed up in Java 1.1 at the latest. AWT used to be heavily dependent on them.
I thought the Android docs were quite good for the most part, but I usually just Google my questions and end up on StackOverflow. I'd love to give StackOverflow a great big hug someday.
This is a great and honest article and has changed the way I think about Apple users/developers.
Before that, I considered Apple users to be a group of gay douchebags, but today I have learned that there is at least a sane person on the other riverside.
(I have neither developed for any smartphone nor do I possess one, so no need for "Stupid FANDROID!1!")
1. The most important thing to think about and say is the market share, fragmentation, monetization issues. Article doesn't pay enough attention to this it, but it still drives why we do what we do. (save, the author was egged on to make the app by their users).
A paragraph would be useful. Perhaps something like.
Fundamentally, Android is the platform you have to be on to defend the turf. It generally wont make a lot of money, but you have to be there to protect & project mind share. Additionally, it is the dominant mobile platform.
2. Development Tools.
You can use IntelliJ Idea. Its a Mature Development Platform, and gives you many options. The article doesn't make any strong arguments against eclipse. The installation/getting started was more involved, but personally, it took me an hour or so, so I don't think it is a big deal. It is useful to separate opinions from facts. Personally, I use emacs bindings in all my editors, and Eclipse is pretty nice to me in general.
3. UI Design Tools
This section is written in a way that projects inaccurate information. It implies that you have to use XML as opposed to using a Interface Builder interface. This is not true - there is indeed a drag and drop interface akin to IB in android. The author mentions it as a preview tool. Indeed it is also a design tool.
It wasn't an advocacy piece, it was a developer's experience in changing environments, and giving some pointers on what to do differently in Android than what one is used to in iOS. The point is not to convince you to develop for Android. The point is to help someone make the switch quickly (such as using Eclipse rather than some other method that hardly anyone uses which will cause you to spend hours getting things set up and a lot of pain following a how-to that is written with the assumption that you're using Eclipse because, you know, almost everyone who developers for Android does).
Skip the ideological critiquing and start shipping some awesome products..
I guess that is really what separates the great developer from the good developer.