An iOS Developer Takes on Android • Hacker News Board

Re: An iOS Developer Takes on Android

#41

Post by rsynnott » Mon, Aug 01, 2011, 4:20 PM UTC

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…

Number 1 here is really beside the point; it's a business issue, not a development one, and a controversial one at that.

Re: An iOS Developer Takes on Android

#42

Post by naz » Mon, Aug 01, 2011, 4:23 PM UTC

clawoo wrote: post #31

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 h…

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.

Re: An iOS Developer Takes on Android

#43

Post by eevilspock » Mon, Aug 01, 2011, 4:23 PM UTC

Eclipse is to IntelliJ as Android is to iPhone.

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/

Re: An iOS Developer Takes on Android

#44

Post by nutjob123 » Mon, Aug 01, 2011, 4:25 PM UTC

hahainternet wrote: post #37

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

It works pretty well in all the cases i've used it. Its the only way that i have been able to get the new animation class to work smoothly.

Re: An iOS Developer Takes on Android

#45

Post by marcomonteiro » Mon, Aug 01, 2011, 4:28 PM UTC

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

Re: An iOS Developer Takes on Android

#46

Post by chocopuff » Mon, Aug 01, 2011, 4:29 PM UTC

clawoo wrote: post #31

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 h…

you don't have to do that. preload your uitableviewcell in ViewDidLoad, then in your cellForRowAtIndexPath, just return the array instead of the cell.

Re: An iOS Developer Takes on Android

#47

Post by pwelch » Mon, Aug 01, 2011, 4:33 PM UTC

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

Re: An iOS Developer Takes on Android

#48

Post by shareme » Mon, Aug 01, 2011, 4:38 PM UTC

rsynnott wrote: post #35

starwed wrote: post #11

Earlier quoted context omitted.

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

Re: An iOS Developer Takes on Android

#49

Post by nfarina » Mon, Aug 01, 2011, 4:41 PM UTC

marcomonteiro wrote: post #45

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

The OpenGL-nature of iOS was explained to me at WWDC by the head of graphics at Apple. But you can never be sure of anything!

Re: An iOS Developer Takes on Android

#50

Post by div » Mon, Aug 01, 2011, 4:44 PM UTC

ThomPete wrote: post #17

What a wonderful approach to development. Skip the ideological critiquing and start shipping some awesome products.. I guess that is really what separates the great developer from the good developer.

Could not agree more.

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.