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.
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.
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.
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.
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).
- 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.
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.
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.
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!
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.
"Ask HN: Jumping into Android Development"
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.