Hacker News Reader

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

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/

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

Any advice on how to find clients?

Any advice on how to find clients?

Launch your own app, they'll find you ;)

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.

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.

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

The apps you ship on the marketplace are your portfolio. Focus on making quality apps.

Publishing apps, put it on your website you do apps with links to apps you've done. Publish free util apps with an add in them for your shop. Etc.

Put contact details in your profile, also please drop me an email.

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.