Hacker News Reader

Comment by brown9-2 | Hacker News Reader

you will spend more time and effort on building something nice than you would in iOS

Can you elaborate on the reasons why?

Two things: Device fragmentation and the UI layout

Device fragmentation means that you will need to test your app on multiple Android devices and operating systems to ensure the experience you built is up to par with what the user sees

UI layout: To build a decent UI requires taking the wayback machine to Java Swing and GridBagLayout. It is getting better though with Gingerbread.

Third thing: Too much decoupling in the development environment

I can. My opinion might be biased because I don't do iOS development (but all my friends do), instead I do Android, WebOS and Bada development.

So, here are a few reasons:

1. On iOS, if you use the native interface the app would look good. On Android, it will look like crap :-)

2. On iOS you have predefined UI effects and transition, on Android you'd have to do custom

3. iOS is faster, and has a much higher memory limit than Android. Allows apps to use more resources (because it's not multi-tasking)

4. iOS doesn't have a capped app size. Most Android phones have application storage limited to around 10Mb. Android introduced lately support for installing apps on external storage but.. check #5

5. Fragmentation. You currently have to suppor 2 major Android versions (4 minor). Believe me, that really caused me a lot of problems in the past 2 years

6. Screen sizes. On Android, you currently need to support 5 different screen size ratios, as well as over 10 screen sizes. handle that!

What are your 'best practices', particularly with #2 and #6?

Re #6: http://developer.android.com/guide/practices/screens_support...

for #2, we're simply in the woods. Android has support for some basic transitions, but because of the nature of the OS, you can't use them to create screen/tab transitions. So, the usual process for this is: 1. move object X pixels 2. wait Y milis 3. go back to 1 until you're done.

on #6 Android has support for a limited range of display setups, making it fairly easy to provide different UI resources for small, medium and large screens. If you want to start supporting different aspect ratios (the Droid is a good example), you have to either start detecting resolution at runtime and modify layout accordingly, or make sure you build your layout in such a way that it will adapt itself to the aspect ratio. The later is preferred, but always needs extensive testing (hopefully on real devices) because every minor OS version messes up something (1.5 has problems with PNG transparency, 1.6 with 'center' positionings, etc...).

I was under the assumption that view classes on android were harder to work with compared to a UIView, which can be subclasses and re-worked with new behavior.

Or, at least that's the reason my friend gave for not developing an interface beyond the default UI for his app.

I have no experience with iOS development, but in Android you can extend classes for views and provide custom behavior for most things you'd want to customize. You also can configure quite a lot of the look and feel of the interface entirely using configuration files - this includes animations when you do things like touch buttons, border styles, colors, fonts, etc. I find it fairly easy to work with.

We could do with a good GUI for designing interfaces, but it's not horrible once you grok the layouts work. Google have acknowledged publicly that the current UI builder in Eclipse isn't good, but there's no public schedule that I'm aware of for when that will be improved.

Ah, I always had a sneaking suspicion my friend was lazy... :)

Thanks for the clarification.

Reply on news.ycombinator.com