An iOS Developer Takes on Android
nfarina.com
nfarina.com
Skip the ideological critiquing and start shipping some awesome products..
I guess that is really what separates the great developer from the good developer.
Java is a high level programming language. It’s unproductive to have an opinion about it.
- Python - Ruby - Ruby on Rails - Django - Coffeescript - Node.js
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.
Most people who complain about a language don't do anything about it.
It was those I addressed, not those who do.
... but that could be me post-hoc rationalising my whinging :D
What's unproductive is to decide to avoid the biggest-by-number-of-units mobile platform because of Java.
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.
They're also bringing a new UI builder this fall. They talk about all of that here:
Uh... no shit? That's exactly what the "emulator" part of "ARM emulator" means.
> it's not just a fake simulator like the one for iOS
It's not a fake simulator, it's a simulator period. There's nothing fake about it.
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.
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.
The Google IO talk linked in this thread addresses this point, so hopefully in Autumn the emulator will be usable (especially at tablet resolutions).
edit: Basically it boils down to too little context around the words emulated vs simulated.
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".
[1] http://android-developers.blogspot.com/2011/06/new-editing-f...
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)
http://stackoverflow.com/questions/4842612/how-do-you-save-a...
I actually used it as my primary Latex editor while writing my PhD thesis this spring.
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.
If the best advice you can tell people is not to use it, use a real device then why bother include it at all.
And he is not kidding about the write your code for you, it really feels that way.
Full disclosure... I develop using Eclipse every day.
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/
The Visual Layout Editor seems like too much goodness to miss out on. Jump to 7:17 in this video for a demo: http://www.youtube.com/watch?v=Oq05KqjXTvs
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.
http://clayallsopp.posterous.com/building-an-android-app-fro...
I've yet to actually try it though :)
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.
Enjoy the fun of Honeycomb hardware acceleration.
Instruments has no competition from traceview.
http://android-developers.blogspot.com/2010/10/traceview-war...
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.
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?
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.
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.
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.
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.
After you suffer the initial emulator load, changes appear in the app by simply bouncing the app. It's one big win for Titanium.
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.
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.
http://www.smallcloudbuilder.com/apps/articles/410-crossing-...
> 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 can get by with Emacs, JDK, and ant. Plus the Android SDK of course.
That's how I roll, and it works just fine.
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.
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.
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.
The alternative is to paint the contents of the cell manually (that is without using UILabels and the such) using CoreGraphics.
Check out the drawContentView: method here: https://github.com/ferostar/fast-scrolling/blob/master/Class...
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.
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.
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.
Ouch!
Im curious, where you experienced in Java before jumping into Android?
really?...m just curious...are you saying it takes less code in java than objC for a given problem?
Which resources (online or otherwise) did you find most helpful?
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.