4 ms·

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

by zrgiu 16y ago

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!

chopsueyar 16y ago
What are your 'best practices', particularly with #2 and #6?
- nuclear_eclipse 16y ago
  Re #6: http://developer.android.com/guide/practices/screens_support.html http://developer.android.com/guide/practices/screens_support...
- zrgiu 16y ago
  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...).
  - sudont 16y ago
    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.
    - ydant 16y ago
      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.
      - sudont 16y ago
        Ah, I always had a sneaking suspicion my friend was lazy... :) Thanks for the clarification.

by zrgiu 16y ago

chopsueyar 16y ago

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

nuclear_eclipse 16y ago
Re #6: http://developer.android.com/guide/practices/screens_support.html http://developer.android.com/guide/practices/screens_support...
zrgiu 16y ago
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...).
- sudont 16y ago
  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.
  - ydant 16y ago
    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.
    - sudont 16y ago
      Ah, I always had a sneaking suspicion my friend was lazy... :) Thanks for the clarification.