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)
http://stackoverflow.com/questions/4842612/how-do-you-save-a...
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 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 actually used it as my primary Latex editor while writing my PhD thesis this spring.
Full disclosure... I develop using Eclipse every day.
And he is not kidding about the write your code for you, it really feels that way.
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.
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.
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.
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.
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'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?
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.
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...
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.
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.
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.
> 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.
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?
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.
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'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.
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.
Instruments has no competition from traceview.
http://android-developers.blogspot.com/2010/10/traceview-war...
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.
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!
> 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!
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...
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.
http://www.smallcloudbuilder.com/apps/articles/410-crossing-...
