Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An iOS Developer Takes on Android

nfarina.com

Post reply on HN
Print view View original

31–40 of 119 posts

Re: An iOS Developer Takes on Android

#31

Post by clawoo »

reidmain wrote: post #22

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.

Check out the drawContentView: method here: https://github.com/ferostar/fast-scrolling/blob/master/Class...

Re: An iOS Developer Takes on Android

#32

Post by reidmain »

napierzaza wrote: post #27
reidmain wrote: post #22

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.

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.

Re: An iOS Developer Takes on Android

#33

Post by estel »

angry-hacker wrote: post #23
nextparadigms wrote: post #3

Earlier quoted context omitted.

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…

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

Re: An iOS Developer Takes on Android

#34

Post by znq »

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.

Re: An iOS Developer Takes on Android

#35

Post by rsynnott »

starwed wrote: post #11
flyosity wrote: post #2

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.

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.

Re: An iOS Developer Takes on Android

#36

Post by rsynnott »

nfarina wrote: post #13
dmix wrote: post #7

This was great. Im curious, where you experienced in Java before jumping into Android?

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.

Re: An iOS Developer Takes on Android

#37

Post by hahainternet »

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.

I've yet to actually try it though :)

Re: An iOS Developer Takes on Android

#38

Post by nextparadigms »

nfarina wrote: post #14
oflannabhra wrote: post #9

Great write-up. I read the whole thing and bookmarked it as well for future reference. Thanks for sharing. Which resources (online or otherwise) did you find most helpful?

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.

Have you tried the forum at http://www.anddev.org ? They have a lot of code snippets there for example.

Re: An iOS Developer Takes on Android

#39

Post by rsynnott »

rimantas wrote: post #6
al_james wrote: post #5

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.

Why would ObjC fry anybodie's mind? I am that weird to like it (coming from web dev background: PHP, Ruby, JavaSript)?

Ruby would help there; Ruby and Objective C both took considerable influence from Smalltalk for their object system.

Re: An iOS Developer Takes on Android

#40

Post by MatthewPhillips »

xcode wrote: post #29

Few Comments. 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…

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).
Post reply on HN