4 ms·

Excellent and practical tips and a few highly-recommended book recommendations/study materials from the HN community: "Ask HN: Jumping into Android Development

Excellent and practical tips and a few highly-recommended book recommendations/study materials from the HN community: "Ask HN: Jumping into Android Development" http://news.ycombinator.com/item?id=1347170 http://news.ycombinator.com/item?id=1347170 The general consensus from my extended network of mobile developer friends and acquaintances: Android is harder to develop for than iOS - you will spend more time and effort on building something nice than you would in iOS. Windows Phone 7 is not an easy transition for .Net and C# developers because it is basically Silverlight framework programming. No one I know is doing WebOS (Palm) development. Also, the money in mobile development is almost always from making apps for companies and organizations that want to have their own app (e.g. consulting). This is from my knowledge of how my friends are making a living. Yes, they have their own apps but to succeed in the direct to consumer device marketplace is really is more about being a better marketer, designer than a mobile developer. The consumer who downloads your program only sees the tip of the iceberg (the UI, the functionality, the user experience). Does it make them feel cool (or appear cooler to their peer group) and/or add some bit of value to their life workflow? They don't care how it was made. Note: This is why HTML5 apps are at a disadvantage - there is only so much you can do with Canvas.

brown9-2 16y ago
you will spend more time and effort on building something nice than you would in iOS Can you elaborate on the reasons why?
- wallflower 16y ago
  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
- 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...).
garply 16y ago
I don't want to launch my own apps, I just want to consult. I've only recently learned to develop for Android (did some very cheap consulting gigs - including porting a small game for practically free). Any advice on how to find clients?
- andreyf 16y ago
  Any advice on how to find clients? Launch your own app, they'll find you ;)
  - sudont 16y ago
    That sounds like an inverse lamentation. I'm pretty sure I remember a couple of dev's in the cocoa blog world complaining about the amount of unsolicited consulting requests they got after launching a couple of somewhat popular apps.
- ydant 16y ago
  Put Android Developer in your profile on LinkedIn. I don't know how successful it ultimately ends up being, but you'll certainly get spammed with recruiters trying to find Android developers.
- espinchi 16y ago
  - Launch a couple of apps into the Market, and get some good numbers (number of downloads, rating). Yes, this is easier said than done, but this is essential for your learning too - Have a personal page where you showcase your applications. Ideally accompanied by a blog - Update your LinkedIn I'm not interested in consulting, but I've had several requests. Usually they have had a look at the three of the things I mention above. I guess generic advice by freelancers on finding clients should help you too.
- wallflower 16y ago
  The apps you ship on the marketplace are your portfolio. Focus on making quality apps.
- gte910h 16y ago
runjake 16y ago
Windows Phone 7 is not an easy transition for .Net and C# developers because it is basically Silverlight framework programming. Which is incorrect, because WP7 and Silverlight are comprised of .NET technologies. There are some new APIs, but C# developers can make extremely smooth transitions, similar to Mac OS X->iOS.
- kenjackson 16y ago
  I agree, that statement made about Silverlight is incorrect. And clearly a statement from someone who doesn't know what .NET or Silverlight is. Additionally there's the XNA stack on WP7 -- which is also a purely .NET stack.
  - wallflower 16y ago
    Yes, I don't have any first-hand experience. I apologize for spreading misinformed data. Please forgive me. The last MSFT experience I have is circa VB6/ADO. I will chastise my .Net acquaintance for giving me the impression that WP7 was hard for .Net/C# devs - and, myself, for spreading misinformation. Personally, when I looked at it (about 2 yrs ago), I didn't know where to start. How did you learn XAML, MVVM? Just brute force and practice? I'd love to be able to do a Zagat-like WP7 app. To be able to know what the custom part of that app development was. http://wmpoweruser.com/zagat-for-wp7-first-look/ http://wmpoweruser.com/zagat-for-wp7-first-look/
    - kenjackson 16y ago
      I didn't know where to start. How did you learn XAML, MVVM? Personally I'd start by using Blend. While the drag and drop approach is largely criticized, it's a great tool for seeing the Xaml get built as you build the UI. And the actual markup generated is quite good. You don't need to know or use MVVM to do Silverlight apps. It can be useful, but I wouldn't try to learn that first. And if you make use of databinding whenever possible, you'll almost have to contort yourself to not do MVVM (although you'll be data-bound against properties in the code behind... this is easy enough to change). The Zagat app is beautiful, and honestly, really straightforward to do most of the Silverlight stuff I saw. Like literally, I think if you know C#/.NET you could get a similar looking app up in a week. The hard part... having the Zagat data. But seriously, a C#/.NET dev should be able to be modestly proficient in Silverlight over a weekend, IMO.

brown9-2 16y ago

you will spend more time and effort on building something nice than you would in iOS Can you elaborate on the reasons why?

wallflower 16y ago
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
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...).

garply 16y ago

I don't want to launch my own apps, I just want to consult. I've only recently learned to develop for Android (did some very cheap consulting gigs - including porting a small game for practically free). Any advice on how to find clients?

andreyf 16y ago
Any advice on how to find clients? Launch your own app, they'll find you ;)
- sudont 16y ago
  That sounds like an inverse lamentation. I'm pretty sure I remember a couple of dev's in the cocoa blog world complaining about the amount of unsolicited consulting requests they got after launching a couple of somewhat popular apps.
ydant 16y ago
Put Android Developer in your profile on LinkedIn. I don't know how successful it ultimately ends up being, but you'll certainly get spammed with recruiters trying to find Android developers.
espinchi 16y ago
- Launch a couple of apps into the Market, and get some good numbers (number of downloads, rating). Yes, this is easier said than done, but this is essential for your learning too - Have a personal page where you showcase your applications. Ideally accompanied by a blog - Update your LinkedIn I'm not interested in consulting, but I've had several requests. Usually they have had a look at the three of the things I mention above. I guess generic advice by freelancers on finding clients should help you too.
wallflower 16y ago
The apps you ship on the marketplace are your portfolio. Focus on making quality apps.
gte910h 16y ago

runjake 16y ago

Windows Phone 7 is not an easy transition for .Net and C# developers because it is basically Silverlight framework programming. Which is incorrect, because WP7 and Silverlight are comprised of .NET technologies. There are some new APIs, but C# developers can make extremely smooth transitions, similar to Mac OS X->iOS.

kenjackson 16y ago
I agree, that statement made about Silverlight is incorrect. And clearly a statement from someone who doesn't know what .NET or Silverlight is. Additionally there's the XNA stack on WP7 -- which is also a purely .NET stack.
- wallflower 16y ago
  Yes, I don't have any first-hand experience. I apologize for spreading misinformed data. Please forgive me. The last MSFT experience I have is circa VB6/ADO. I will chastise my .Net acquaintance for giving me the impression that WP7 was hard for .Net/C# devs - and, myself, for spreading misinformation. Personally, when I looked at it (about 2 yrs ago), I didn't know where to start. How did you learn XAML, MVVM? Just brute force and practice? I'd love to be able to do a Zagat-like WP7 app. To be able to know what the custom part of that app development was. http://wmpoweruser.com/zagat-for-wp7-first-look/ http://wmpoweruser.com/zagat-for-wp7-first-look/
  - kenjackson 16y ago
    I didn't know where to start. How did you learn XAML, MVVM? Personally I'd start by using Blend. While the drag and drop approach is largely criticized, it's a great tool for seeing the Xaml get built as you build the UI. And the actual markup generated is quite good. You don't need to know or use MVVM to do Silverlight apps. It can be useful, but I wouldn't try to learn that first. And if you make use of databinding whenever possible, you'll almost have to contort yourself to not do MVVM (although you'll be data-bound against properties in the code behind... this is easy enough to change). The Zagat app is beautiful, and honestly, really straightforward to do most of the Silverlight stuff I saw. Like literally, I think if you know C#/.NET you could get a similar looking app up in a week. The hard part... having the Zagat data. But seriously, a C#/.NET dev should be able to be modestly proficient in Silverlight over a weekend, IMO.