Developing on WP7 vs Android vs iPhone(blog.edwinevans.me)
blog.edwinevans.me
Developing on WP7 vs Android vs iPhone
http://blog.edwinevans.me/?p=77
12 comments
Summary: The author is a long-time Windows developer and extremely familiar with Visual Studio.
I don't understand where you got your summary. Looking at his CV - http://home.pacbell.net/eevans2/resume.html - it seems he has a range of experience.
I don't understand where you got your summary. Looking at his CV - http://home.pacbell.net/eevans2/resume.html - it seems he has a range of experience.
I don't understand where you got your summary.
From this part of the article: I admit that I’ve spent many more years developing in Visual Studio than Eclipse or Xcode...
Based on my own years in Visual Studio, I assumed that this meant Windows development of one flavor or another.
From this part of the article: I admit that I’ve spent many more years developing in Visual Studio than Eclipse or Xcode...
Based on my own years in Visual Studio, I assumed that this meant Windows development of one flavor or another.
Could be an IntelliJ user like myself (when I'm not using VS, that is).
[deleted]
But his personal tastes are shared by an enormous number of Windows developers, so based on his blog post, I imagine that WP7 will succeed with in-house corporate developers. Interesting.
I'm not sure that's true. To answer that question you'd have to compare WP7 development to MonoTouch. There's no doubt the WP7 development system is more refined but MonoTouch allows you to use C# and a .net like environment while at the same time letting your staff keep the iPhones they already love.
I'm not sure that's true. To answer that question you'd have to compare WP7 development to MonoTouch. There's no doubt the WP7 development system is more refined but MonoTouch allows you to use C# and a .net like environment while at the same time letting your staff keep the iPhones they already love.
Popularity among corporate developers fits the analysis that WM's main success will be in replacing Blackberries as work-issued phones. Corporations would surely like to have a phone OS that their sysadmins and programmers understand, so they can integrate it well with Exchange and write in-house apps easily.
Small point perhaps but a place I was working at five years ago was developing in house custom apps for their workforce on the old windows mobile phones (probably 5 or 6? can't remember) but they did it because you could dev in .net and well it did what they needed it to do. That was about 400 devices and they were not cheap back then.
This is total shallow flaimbait.
As a C#/Ruby developer I embarked on the somewhat painful journey of learning Objective-C a few weeks ago. I got my first personal app written to control my Denon 3808 remote.
Admittedly it would have taken me a fraction of the time in either C# or Java ... square bracket central is something that is hard to get used to.
However, I find the whole experience of developing on iOS very well documented ... this is not COM development with MFC, it is much more approachable. It is a pleasure to have a language that has its roots in Smalltalk and having a fairly comprehensive yet-not-gigantic set of support classes is great. Objective C delegates are nice, the evented style it offers is nice. Auto release pools take away a lot of the pain of memory management. I am sure that after a few months of development in Objective C I would be quite productive. However I still prefer C#. Also, I prefer Ruby over C#.
When I first learned WPF a few years ago I could not believe the bloat of the base library, it took weeks to really understand how all the XAML stuff works, building custom controls was tricky business.
Today, Silverlight (which has its roots in WPF) is much more polished. As far as I can see if you use the toolkit and controls that ship with WP7 development is quite seamless. However, my understanding is that the iOS set of APIs are more comprehensive due to the huge first to market advantage they have.
There are lots of very subtle advantages to each of these platforms that only and expert in all 3 could point out. That is an article I would love to read.
As a C#/Ruby developer I embarked on the somewhat painful journey of learning Objective-C a few weeks ago. I got my first personal app written to control my Denon 3808 remote.
Admittedly it would have taken me a fraction of the time in either C# or Java ... square bracket central is something that is hard to get used to.
However, I find the whole experience of developing on iOS very well documented ... this is not COM development with MFC, it is much more approachable. It is a pleasure to have a language that has its roots in Smalltalk and having a fairly comprehensive yet-not-gigantic set of support classes is great. Objective C delegates are nice, the evented style it offers is nice. Auto release pools take away a lot of the pain of memory management. I am sure that after a few months of development in Objective C I would be quite productive. However I still prefer C#. Also, I prefer Ruby over C#.
When I first learned WPF a few years ago I could not believe the bloat of the base library, it took weeks to really understand how all the XAML stuff works, building custom controls was tricky business.
Today, Silverlight (which has its roots in WPF) is much more polished. As far as I can see if you use the toolkit and controls that ship with WP7 development is quite seamless. However, my understanding is that the iOS set of APIs are more comprehensive due to the huge first to market advantage they have.
There are lots of very subtle advantages to each of these platforms that only and expert in all 3 could point out. That is an article I would love to read.
"Objective-C sucks" is just silly. If you know and like C#, of course you'll like developing for WP7 more. Weird that he talks about null references in Objective-C but you can send all kinds of messages to nil and you'll be fine. Not so in C#/Java.
I actually was just wishing c# had as terse of a null check syntax as ObjC. I love the fact that I can type
if(!object)
if(object == null)
if(!object)
[[Do something]about it]
if(object == null)
DoSomething.Aboutit
This is actually really easy to do in c#:
public static bool operator true(Class c)
{
return c != null;
}
public static bool operator false(Class c)
{
return c == null;
}
well I know that it is possible, I was thinking of trying to write a similar type function with an extension method, but I just like how its included out of the box in ObjC. Really I think for a general purpose language C# is more flexible and while leveraging .NET you have more tools available to develop rapidly.
Part of me feels that Im not "really programming" when I write managed code though. I like writing C and ObjC because I feel like Im actually flipping switches on the CPU. It is silly I know(and all in my head), but being lower level seems to excite me more.
In reality I think its all about the right tool for the job, and choice is good.
Part of me feels that Im not "really programming" when I write managed code though. I like writing C and ObjC because I feel like Im actually flipping switches on the CPU. It is silly I know(and all in my head), but being lower level seems to excite me more.
In reality I think its all about the right tool for the job, and choice is good.
I meant it doesn't complain when sending a message to a nil object though this is probably not what you intended and makes tracking down bugs harder... or maybe I just have C++ mindset.
I think when many people hear about ObjC's nil semantics, they use it as a pretext for dropping all their null checks. This is a mistake, and you're right, it will make debugging exceptionally difficult when nils start falling through five levels of functions and propagated through ivars.
The trick is to use null checks almost like you're writing C++, but drop them when they are unnecessary and inelegant. Convince yourself that a null check is unnecessary before removing it. This way you're reducing the chance of bugs and making them easier to pinpoint.
For example, you can do:
tl;dr: Messaging nil is not idiot-proof but it makes code read better.
The trick is to use null checks almost like you're writing C++, but drop them when they are unnecessary and inelegant. Convince yourself that a null check is unnecessary before removing it. This way you're reducing the chance of bugs and making them easier to pinpoint.
For example, you can do:
if ([someArray count])
if (someArray && [someArray count])
[[someArray lastObject] dance];
tl;dr: Messaging nil is not idiot-proof but it makes code read better.
The worst offender is the comparison methods:
NSString *myString = nil;
if ([myString compare:@"something"] == NSOrderedSame) {
...
}Complaining that Apple's docs say it's easy is unreasonable. I'm sure microsoft's docs say so too. The problem isn't that Apple says it's easy, the problem is tha it's not easy. It's not even hard. It's stupid.
I speak as an iOS developer and long time Apple devotee. The way Apple manages signing and submission is a cruel joke. It was ok as a "get it out the door NOW" beta in, what, 2008, but it's barely improved. I spend more time figuring out wh signing failed than finding actual bugs.
I don't think arguing obj-c is useless to learn is fair, but he you're a windows guy. IMHO learn new languages is seldom useless, and I'd rather learn obj-c than c# for the exact sam reasons you'd rather learn c#, and I'd argue the intellectual benefit from learning obj-c exceeds that of adding c# to java or vice versa.
I speak as an iOS developer and long time Apple devotee. The way Apple manages signing and submission is a cruel joke. It was ok as a "get it out the door NOW" beta in, what, 2008, but it's barely improved. I spend more time figuring out wh signing failed than finding actual bugs.
I don't think arguing obj-c is useless to learn is fair, but he you're a windows guy. IMHO learn new languages is seldom useless, and I'd rather learn obj-c than c# for the exact sam reasons you'd rather learn c#, and I'd argue the intellectual benefit from learning obj-c exceeds that of adding c# to java or vice versa.
I have developed for Android, and recently started developing WP7. So far, I prefer the development environment and tools for WP7. Silverlight + Blend studio allows for quick and beautiful apps, and XNA studio does much of the work necessary to get the frame updating and rendering working. So far I am impressed with WP7.
I don't think enough people bring up the advantage Expression Blend brings to the table. It's like being able to design your UI in Photoshop
(Say what you will about Microsoft the one thing you have to give them credit for is the amount of money they spend to create developer tools)
Things might change once Adobe gets Flash up to speed on Android but until then Blend is by far the most powerful UI environment available for any mobile device.
(Say what you will about Microsoft the one thing you have to give them credit for is the amount of money they spend to create developer tools)
Things might change once Adobe gets Flash up to speed on Android but until then Blend is by far the most powerful UI environment available for any mobile device.
Yes, most people don't even know that Expression Blend exists. The first time I used it to customize my UI in Silverlight, I was blown away how quick and painless it was. To simply change the look of a button in Android, I had to spend far too long creating .9png files or w/e they are called.
To simply change the look of a button in Android, I had to spend far too long creating .9png files or w/e they are called.
Yes, so please don't do that. No user wants an app that looks different from every other app on the platform.
Yes, so please don't do that. No user wants an app that looks different from every other app on the platform.
The author says Marketplace approval is usually quick at about 2 days.
Except when you are one of the many developers whose apps get stuck in the marketplace, that never get approved or rejected because of lousy infrastructure on Microsofts side.
A developer I highly respect wrote about his ongoing struggle getting his Google Voice client out for WP7. If he wasn't already known from his MVP work, it's unlikely he would even have got those [extremely unhelpful] responses from Microsoft.
http://www.koushikdutta.com/2010/12/windows-phone-marketplac...
Except when you are one of the many developers whose apps get stuck in the marketplace, that never get approved or rejected because of lousy infrastructure on Microsofts side.
A developer I highly respect wrote about his ongoing struggle getting his Google Voice client out for WP7. If he wasn't already known from his MVP work, it's unlikely he would even have got those [extremely unhelpful] responses from Microsoft.
http://www.koushikdutta.com/2010/12/windows-phone-marketplac...
I started reading your comment and was getting ready to find Koush's frustrated tweets. Looks like a really nice product but it's been in holding for 26 days now for his latest big huge update. A damn shame when the WP7 marketplace is so far behind (relatively).
So my takeaway is that he prefers using Visual Studio and C# to write mobile applications, followed by java/eclipse/emacs for the android and Xcode/ObjC bringing up the rear.
I think its a fair assessment, as someone who spends his daytime hours in VS2010 writing C#, the tools are first rate. I personally like objective C as a language(I think C# and .NET is growing at a rate that will tire of keeping up with before too long where objective C is lean and easy to learn), and feel that things could be better if XCode were better. That said, the iPhone simulator is at least 100 fold better than the WP7 emulator.
I think its a fair assessment, as someone who spends his daytime hours in VS2010 writing C#, the tools are first rate. I personally like objective C as a language(I think C# and .NET is growing at a rate that will tire of keeping up with before too long where objective C is lean and easy to learn), and feel that things could be better if XCode were better. That said, the iPhone simulator is at least 100 fold better than the WP7 emulator.
My experiences with Android and iOS dev has been pretty bad. Android has unbelievably crappy tools. Mac iOS dev tools are beautiful and extremely slick, however I couldn't figure them out. Objective-C is a huge blocking issue for me.
Recently been using Titanium Mobile which I'm starting to really like. It makes iPhone dev really nice. With Android dev though you still have to deal with the crappy tools provided by Google (compiler, emulator, packager).
I don't doubt Visual Studio has a much easier development process for apps. C# is a decent language for that kind of thing. But I don't think I could bring myself back to ever using Windows again for development (even in a VM).
Recently been using Titanium Mobile which I'm starting to really like. It makes iPhone dev really nice. With Android dev though you still have to deal with the crappy tools provided by Google (compiler, emulator, packager).
I don't doubt Visual Studio has a much easier development process for apps. C# is a decent language for that kind of thing. But I don't think I could bring myself back to ever using Windows again for development (even in a VM).
What's so hard about objective-c? If you stay mostly-in-objc, it's not much different than ruby/python -- it's just method calls with named parameters. If you use any framework in ruby, you're probably already doing something similar since many method calls take in a hash where you pass in options.
Everything else after learning the syntax is just learning the api.
Everything else after learning the syntax is just learning the api.
I think because kids nowadays never learned C/C++ like us old timers. Manual memory management trips them up. Obj-C's "weird" object oriented syntax becomes a non-issue in 2 hrs of coding, so it has to be the manual memory management and API design that are the issue.
UIKit and Cocoa are, admittedly, pretty unorthodox compared to pretty much a lot of UI frameworks out there. That and Interface Builder being a separate app were the biggest obstacles for me learning iOS programming.
UIKit and Cocoa are, admittedly, pretty unorthodox compared to pretty much a lot of UI frameworks out there. That and Interface Builder being a separate app were the biggest obstacles for me learning iOS programming.
"Mac iOS dev tools are beautiful and extremely slick"
And yet have features found in SlickEdit circa 1992.
Twenty fucking years later I'd expect my IDE to a bit smarter. It might look beautiful (to you) but its brain dead.
And yet have features found in SlickEdit circa 1992.
Twenty fucking years later I'd expect my IDE to a bit smarter. It might look beautiful (to you) but its brain dead.
Do you have some implementable ideas?
Absolutely:
http://blog.binaryfinery.com/monotouch-qa
This is written for potential clients, rather than hackers, but I do go a bit deeper into why ObjectiveC sucks near the bottom.
Basically, use good tools. What hacker would create a website without analytics these days? Yet Apple wants us to settle for an editor that is dumb as bricks, when tools like Resharper or Eclipse that can not only analyze our code but refactor it automatically. XCode has 6 refactorings, and all of them will fail to do what you want, or just flat out refuse. Resharper has, I think, 120?
Resharper analyzes my code as I type. I develop iPhone apps on my PC in C# and even before I compile it on the Mac, I know its going to compile because Resharper has been analyzing it the whole time.
There are basically two problems with XCode and Objc and neither of them are solvable:
1) Writing tools for languages that have header files that can be included multiple times, and which require a class to be declared all over the place, is hard.
2) There's a shit load more developers for java, C, C++ and C# than there are for Objective-C. This may change, enough to incentivize groups (companies/oss) to write better tools, but they'll still be years behind groups like jetbrains or eclipse.
Now, C and C++ may be 20+ years old, but they've been in constant use and development that whole time, and by a majority of programmers. Yet even these languages have poor tools (the whole header issue). Objective-C is 20 years old, but with, what, a 15 year hiatus.
So the solution is to say "Why the fuck am I using a 20 year old language that lacks 20 years of tool development" and move on to something thats either a) newer or b) well established. I recommend MonoTouch.
http://blog.binaryfinery.com/monotouch-qa
This is written for potential clients, rather than hackers, but I do go a bit deeper into why ObjectiveC sucks near the bottom.
Basically, use good tools. What hacker would create a website without analytics these days? Yet Apple wants us to settle for an editor that is dumb as bricks, when tools like Resharper or Eclipse that can not only analyze our code but refactor it automatically. XCode has 6 refactorings, and all of them will fail to do what you want, or just flat out refuse. Resharper has, I think, 120?
Resharper analyzes my code as I type. I develop iPhone apps on my PC in C# and even before I compile it on the Mac, I know its going to compile because Resharper has been analyzing it the whole time.
There are basically two problems with XCode and Objc and neither of them are solvable:
1) Writing tools for languages that have header files that can be included multiple times, and which require a class to be declared all over the place, is hard.
2) There's a shit load more developers for java, C, C++ and C# than there are for Objective-C. This may change, enough to incentivize groups (companies/oss) to write better tools, but they'll still be years behind groups like jetbrains or eclipse.
Now, C and C++ may be 20+ years old, but they've been in constant use and development that whole time, and by a majority of programmers. Yet even these languages have poor tools (the whole header issue). Objective-C is 20 years old, but with, what, a 15 year hiatus.
So the solution is to say "Why the fuck am I using a 20 year old language that lacks 20 years of tool development" and move on to something thats either a) newer or b) well established. I recommend MonoTouch.
>Android is better for being able to develop on your platform of choice (though I suspect developing on Mac is best supported)...
Quickly like to point out that Eclipse on OS X is atrocious.
Quickly like to point out that Eclipse on OS X is atrocious.
I think it should be mentioned that you most definitely don't need to use Eclipse to develop for Android. If you don't like Eclipse, both of the other major Java IDE's (NetBeans and Intellij) have Android plugins. And, since all the important tools can be run from the command line, really any text editor will do. I wrote my first Android app entirely in Emacs. If you're an OSX user, TextMate would probably be a great choice for Android development.
Also, as I believe the article points out, with Android (or MP7) you can run your development environment in a VM of our choice on top of whatever you normally use as your desktop OS (I do my Android development in an Ubuntu VM on my Windows XP laptop). That's not practical for iPhone development. Putting together a "FrankenMac" is very cumbersome, the resulting VM tends to be unstable and fragile, not to mention that it's against the license agreement for OSX.
Also, as I believe the article points out, with Android (or MP7) you can run your development environment in a VM of our choice on top of whatever you normally use as your desktop OS (I do my Android development in an Ubuntu VM on my Windows XP laptop). That's not practical for iPhone development. Putting together a "FrankenMac" is very cumbersome, the resulting VM tends to be unstable and fragile, not to mention that it's against the license agreement for OSX.
When did you last try Eclipse on OS X?
I personally prefer Netbeans over Eclipse and Ubuntu or even Windows over Mac OS X, but Eclipse on Mac has become very usable since about two years ago. (I think there are still some problems with keyboard shortcuts, but I'll blame them mostly on OS X, not Eclipse.)
I personally prefer Netbeans over Eclipse and Ubuntu or even Windows over Mac OS X, but Eclipse on Mac has become very usable since about two years ago. (I think there are still some problems with keyboard shortcuts, but I'll blame them mostly on OS X, not Eclipse.)
I've been using Eclipse for the last three years, more heavily in the last year (Android development). I find it to be incredibly slow, to the point where it becomes unusable. After a couple hours, switching files takes 2-3 seconds, code hints take 4-5 seconds, etc. Very painful.
Agreed.
I could never find an IDE for java I liked on OS X. Eclipse is ugly, buggy and crashes every few hours. NetBeans is better, but not by much.
I could never find an IDE for java I liked on OS X. Eclipse is ugly, buggy and crashes every few hours. NetBeans is better, but not by much.
My main concern with WP7 is that it can run only managed code (see http://social.msdn.microsoft.com/Forums/en-US/windowsphone7s... for example).
This means that existing non-.NET code has to be rewritten from scratch to be ported to WP7, while on iPhone and Android it is possible to link native code.
If a developer wants to write the same application on iPhone or Android and WP7, basically no code can be shared. Is it worth it?
This means that existing non-.NET code has to be rewritten from scratch to be ported to WP7, while on iPhone and Android it is possible to link native code.
If a developer wants to write the same application on iPhone or Android and WP7, basically no code can be shared. Is it worth it?
IMO the comparison between these platforms is only interesting when you take alternate languages into account. We know Java, C#, and Objective C are all way behind, so how do more advanced languages fare on these platforms?
For WP7, the officially supported languages are C# and VB.NET. That being said, because it is just running Silverlight, you can try running any .NET language.
For example, there are a few people running F# on Windows Phone 7. I haven't tried it myself, but here is a link to templates for game development with F# on WP7: http://sharp-gamedev.blogspot.com/2010/12/project-templates-...
Here's an article on building a WP7 app with IronRuby: http://msdn.microsoft.com/en-us/magazine/ff960707.aspx While this isn't as fast as it could be, because you can't access Reflection.Emit to JIT method bodies to native code, it does show you can run Ruby in a WP7 app.
For example, there are a few people running F# on Windows Phone 7. I haven't tried it myself, but here is a link to templates for game development with F# on WP7: http://sharp-gamedev.blogspot.com/2010/12/project-templates-...
Here's an article on building a WP7 app with IronRuby: http://msdn.microsoft.com/en-us/magazine/ff960707.aspx While this isn't as fast as it could be, because you can't access Reflection.Emit to JIT method bodies to native code, it does show you can run Ruby in a WP7 app.
Exactly what I'm talking about; thanks for the links.
> We know Java, C#, and Objective C are all way behind (...)
Behind what?
Behind what?
While I side with his statement, I neither like the condescending tone of his phrasing. But i believe he means advanced, 'esoteric', fancy smarty pants stuff like functional languages. One can spend aeons frivolously debating why pragmatism is (not) better than pure expressive power. And which language is what and then devolve to what is definable. mere mortals have better things to do with their finite lives.
Anyways... I can attest to F# being a breeze to get on WP7 and Scala can be wedged into android with some effort. Thats about it I think of in terms of no extra runtime required solutions.
Anyways... I can attest to F# being a breeze to get on WP7 and Scala can be wedged into android with some effort. Thats about it I think of in terms of no extra runtime required solutions.
Behind the state of the art in language design. Compare C# to F#, or Java to Scala. And that's not even taking into account languages like Haskell, Io, and Clojure that introduce more radical new concepts. (Not that the concepts themselves are new, but they appear radical to Java and C# devs.)
So, square brackets are the new parenthesis for language arguments.
I'm not sure the author is really distinguishing between his personal tastes and the actual characteristics of each platform. But his personal tastes are shared by an enormous number of Windows developers, so based on his blog post, I imagine that WP7 will succeed with in-house corporate developers. Interesting.