Microsoft's new pitch: 'Every .Net developer just became a Windows Phone developer'
Summary: Microsoft officials promised more details about the company's Windows Phone 7 development strategy would be revealed in mid-March at its Mix 10 conference. But those details already have begun to leak out. Not surprisingly, Silverlight is at the crux of Microsoft's development platform. XNA, Microsoft's game-development platform, also is part of the puzzle.
Microsoft officials promised more details about the company's Windows Phone 7 development strategy would be revealed in mid-March at its Mix 10 conference. But those details already have begun to leak out.
Not surprisingly, Silverlight is at the crux of Microsoft's development platform. XNA, Microsoft's game-development platform, also is part of the puzzle.
According to documents posted to the XDA Developers Forum and surfaced more widely by WMPoweruser.com, Microsoft will make available a limited set native application programming interfaces (APIs), with the the real focus on managed APIs (meaning .Net-based). The primary tools for developing for the Windows Phone 7 OS will be Visual Studio 2010 and Microsoft Expression Blend (a design tool for Silverlight and .Net), according to the docs.
The XNA Framework, an implementation of the .Net, and its associated tools, also are likely to be part of the mix. Given the XNA Game Studio already supports Xbox 360, as well as the Zune media player, -- and Windows Phone 7 borrows so liberally from the Zune HD, in terms of its user interface) -- it makes sense XNA tools will support Windows Phone 7. For the record: Microsoft officials have declined to say whether Zune HD apps and games will run on Windows Phone 7 -- and whether new Windows Phone 7 apps will run on Zune HDs.
I've heard a few more specifics from a couple of my contacts who've asked me to keep them anonymous. One described Microsoft's Windows Phone 7 planned developer pitch as follows:
"The dev platform is Silverlight 3, plus elements of 4, using Blend and a Visual Studio add-in. The kicker is that while it is XAML-like, it is not pure XAML (Extensible Application Markup Language). This is actually OK, as it keeps the footprint nice and small.
"In theory you can make an entire app inside of Blend, but I think you will need Visual Studio to hook it all together in C#. In the war vs. Apple for apps, every .NET developer just became a Phone developer."
Microsoft has yet to announce officially (or make available to external testers) the promised add-on(s) for Visual Studio 2010 that will support Windows Phone development. One of my sources said there will be one tool that will be integrated with the Visual Studio 1020 integrated development environment (IDE) and another that will be available as standalone install. Microsoft officials have said they'll have more to say about mobile-development support for Visual Studio 2010 some time this year. (Mix 10 is my guess.)
WMPoweruser points to the newly leaked documents (which Microsoft isn't confirming are real, but sure look as though they are) as proving that Windows Phone 7 will enable multitasking. I'm still not 100 percent convinced of this, as I've heard from my contacts that Microsoft will be playing fast and loose with what "multitasking" means with Windows Phone 7 so as to be able to claim that's the case. (The aforementioned source gave me a pretty definite 'no' when I asked whether Windows Phone 7 would support multitasking to the same degree that Windows Mobile 6.x devices do.)
Another developer issue that still remains murky is whether and how easily the existing Windows Mobile 6.x application base (1,245 apps in the Windows Marketplace for Mobile store, plus countless custom apps) will be able to run on Windows Phone 7 devices. It's obvious because of user inteface differences, existing apps will need to be modified to some degree to work. But Microsoft officials also have refused to provide details about the backward-compatibility story, saying more will be shared at the Mix show.
On a related note, for those developers still interested in writing apps for the Windows Mobile 6.x platform (for whatever reasons), Microsoft released this week a developer toolkit for Windows Mobile 6.5.3.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Ok, and every Java developer "just" became an Android developer.
more to learning to program a phone than the
programming language.
An oversimplification, yes, but...
Besides, Java and .NET are both designed to be less interested in the core platform as they are interested in the programming platform (ignoring, of course, that .NET is inherently a Windows development platform and not agnostic the way Java is).
.NET is just Microsoft's implementation of the standard CLR ...
Novell implements the CLR on Linux via Mono.
Others implement the CLR for other platforms and architectures. GemAlto, for example, implements the CLR to run on a smart card.
The CLR is platform and implementation agnostic and, depending on what external assemblies your code consumes, may in fact be fully interoperable with other vendors' assemblies.
Totally wrong
>>(ignoring, of course, that .NET is inherently a Windows development platform and not agnostic the way Java is).
CLI is ECMA/ISO standard and C# is also ECMA/ISO standard. Derivative of CLI is CLR and CLR is available for a while on Mac, Linux and SmartCards. .NET has become open standard long before Java has become.
--Ram--
Actually you're wrong...
And its also important to note that while theres Mono on Linux (don't know about the Mac scene) its still not completely write once run anywhere. For instance if you write your GUI using Swing it run relatively anywhere at least in the PC realm. You can't take a WinForms GUI and run it on Mono. I believe there are other Windows specific components as well. The only thing thats really common is the C# language.
A little different...
It may be the case with Android that they do something similar. If so then I think that is a reasonable case to make. Not being a Java developer any more, the Android story isn't really that interesting to me.
little correction
Such as:
no generational GC
Static construction blocks all .Net threads until construction is complete
Many Many classes/methods/namespaces don't exist in .NetCF
Code is pitched if app is backgrounded
there is no pre-compiler (like ngen) so everything is IL and JIT compiled as needed
debugging tool set is weak at best.
Think of .NetCF as .Net spec compliant but it is just a wafer thin slice off the top of the spec in implementation.
Not as easy as just port and play that is for sure.
Don't jump the gun ...
Actually.... it might be CoreCLR...
IMHO Windows Phone 7 [i]Series[/i] (I have highlighted what I think is essential) would lean more on a CoreCLR implementation similar to Silverlight 2.0 and 3.0, but with a more extensive set of classes like SL 4.0.
With that said, WP7S UI might as well be just a Silverlight shell in substitution to the explorer.exe app.
As for multitasking, everybody knows Mac OS X is preemptive while Win95 and Mac OS was cooperative. So theoretically the iPhone would multitask. Wrong!!! The OS can but the app framework is built so the OS kills the apps after exit. Same could apply to WP7S. This will be used so no errant process are left sucking RAM since most SmartPhones have 1Gb of RAM or less.
CoreCLR
No matter how you slice it, Windows Phone does NOT run .NetFX
Other than interface stuff, .NetCF 3.7 has no generational GC, still blocks all threads on static construction etc etc etc. Just like .NetCF 3.5
Don't get me wrong, silverlight is cool to have on the device. I'm a bit taken back that it isn't a pre-emptive OS and there is no enterprise goo put in, like domain join etc, but maybe later.
Why would WinPhone7 NOT be pre-emptive
MS have already stated that apps will still be able to play music in the background and respond to push notifications, for example.
I hope like hell this doesn't get abused by every WinPhone app phoning home and requesting a push notification that their service is still up and running ever 60s.
In all reality, so long as your app is paged back in seamlessly and quickly when required, most apps won't care if they're suspended anyhow.
What apps do you feel MUST stay up and running at full speed in the background on a phone ... other than phone, SMS, Email and music?
it isn't
I don't feel any app MUST stay up and running. But I do think this is a step backwards. Although iPhone has the same issue with multi-tasking.
I personally see the consumer device as an eventual replacement of a laptop. To do that the tech can't go backwards and needs to implement enterprise connectivity. phone is just one type of enterprise connectivity.
@TardHugger: Read my post again ...
Specifically: [WinPhone7 is] based on WinCE 6+ and WinCE has pre-emptively multi-tasked since v1.
The OS *does* multi-task - that's how it managed to handle incoming mail via push-sync while you're doing something else.
Wait for MIX2010 - you'll find more FACTS there.
That was story with Windows Mobile
--Ram--
Get a clue!
Seriously, it's not .NET platform developers target, not a phone or an operating system or a web platform. There is less that's unique to developing a .NET application that targets a particular piece of hardware than for other programming languages/frameworks.
As a WinForms/ASP.NET developer, I was able to begin developing a Windows Mobile 6 application after only a few minutes of tinkering with no prior experience.
This is just another example why .NET is by far the best development platform available.
Yea that attitude pretty much ensures WinMo apps will suck...
All that to say this. If you know Java then yes you can develop for Android without a problem. You just need to read up on the Android specific API's. That doesn't mean you have thought about UI design for the form factors you will encounter. It doesn't mean you have thought about the amount of processing power or RAM you have even though MS has set minimum limits. It doesn't mean you have thought about what it means for your application to hog resources and potentially get in the way of the primary function of the device which is being a phone and potentially causing phone calls to be missed for example.
Its not a knock on .Net at all by the way. Its really a knock on the way MS tries to market this stuff as being so easy to switch from platform to the next. The API may not change but concerns do and that obstacle will never be removed. So yes I do believe if they keep this marketing up the first batch of WinMo7 apps will contain alot of garbage just as many other platforms that have given quick and easy access to inexperienced developers have had to deal with their initial round of garbage code....nothing more nothing less.
Webforms aren't that much different...
So some inexperience developers throw out a few crappy applications...well...sometimes...that's how you get some experience. I think that the exposure to the development community can only be a good thing in the long run. I'm more concerned with MS's inability to develop a phone OS that stays relevant.
Who said I like JSP?
You are Completely Wrong
--Ram--
LMAO...you didn't read a thing I said did you?
"You need to understand the architecture of the platform first"
Thats pretty much true no matter what. MS with its development platforms tries to make that an incorrect statement and most times it doesn't work out. As a matter of fact I was just reading a blog from a Softie on developing without understanding.
http://www.hanselman.com/blog/CargocultProgramming.aspx
Yet ironically thats exactly what MS is encouraging here and what some of you seem to think is the right way to go.