Hacker News Reader

Comment by flyosity | Hacker News Reader

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.

View on HN

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:

http://www.youtube.com/watch?v=Oq05KqjXTvs

> Another smaller issue would be that the Android emulator is basically running "ARM hardware" on top of x86

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.

Why are people down-voting this parent?

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.

My guess is people are down voting for tone, and the fact that he didn't even read what he quoted.

> 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).

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".

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?

They've largely been released a month ago [1]. Some elements are still missing, however.

[1] http://android-developers.blogspot.com/2011/06/new-editing-f...

Emulator snapshots help the initial bootup time

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 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.

Just start the emulator op in the morning. There is no reason to shot it down when you go back to coding.

I was going to ask whether there was a problem with your 'u' key, but you used it in "you". I'm confused.

Jst trying to confose you more - He used 'u' in more than just you. (Just, emulator)

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.

Still, you will have to wait for around 30s for each refresh; While the new binary gets uploaded

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.

I've found eclipse not too bad using my MacBook Air -- having an SSD helps a lot.

I actually used it as my primary Latex editor while writing my PhD thesis this spring.

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.

you can disable those GC pauses..how? the default eclipse.ini do not change it..

He's right about eclipse. After you learn it the productivity boost is tremendous. I'm sure lots of dev environments are like this.

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.

Eclipse is big, but it is really, really good to.

And he is not kidding about the write your code for you, it really feels that way.

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.

Reply on news.ycombinator.com