rhm said:
Clint said:
*snip*

I'm not sure why you think API concerns are only relevant if they affect niners commenting in this exact thread - you realise that most developers will just vote with their feet and not develop and not even tell you why they're not going to develop for WP7?


As for the whole managed code thing, the performance argument 'for' is largely irrelevant (with some caveats I'll get to later). The reliability argument Charles raises 'against' is completely irrelevant: WinMo 5 could be made pretty unstable by 3rd party apps and I don't know why (uncontrolled memory allocation or whatever?), but that reflects more on WinMo than it does on native code development in general as iPhone OS does not have a problem with 3rd party apps crashing the phone. Not only that, but there's an assumption in the statement that Microsoft doesn't write native code that crashes and I bet there will be plenty of bugs found in IE once the thing ships.


The number 1 issue by far with not providing native APIs is the porting of games. Microsoft has been showing the money to developers of popular iPhone games and if anyone is biting, they're not saying. Who wants to re-write a whole app in C# to a different graphics API for a platform that hasn't yet shipped and nobody knows if it will be sucessful or not? Even if you're already exhausted the much more attractive option of porting to Android, the option to start on a new game is going to be more attractive.

The performance of managed code is usually a canard, but one area where it has an impact is in numerical processing, esp. where the hardware provides facilities that aren't made available to the managed developer. The ARMv7 architecture provides a vector processing unit, similar to the Intel SSE extensions, and under iPhone OS you have a framework called Accelerate consisting of 3 libraries that allows you to do DSP and linear algebra very easily. Does WP7 provide anything similar? As far as I can tell, no. And because there's no unmanaged code, you can't write your own ARM code to do the same.

So while I'm sure there will be virtual instrument audio apps on WP7, all the computation on arrays in C# means they will be slow and a massive battery drain. Of course there are also many image processing applications for these vector operations as well and since XNA has been crippled on WP7 by not allowing custom shaders, you can't get around it with that either.


Talking of audio apps, on iPhone OS you can now gain access to the raw audio of music files played from the user's iPod library as long as they are not DRM protected. The use case for this is virtual DJ apps, guitar hero type games and the like. WP7 only provides play/stop APIs for the user's music library.


WP7 doesn't provide (again as far as I can tell, feel free to correct me) access to the camera data in real time. Although you can probably hack UI elements infront of the "take a picture" component (it's hard to tell without an actual phone), this will put a crimp in AR apps. AR apps are also a good example of why splitting Silverlight and XNA is stupid - you'll almost certainly have to write your AR app in Silverlight (not even sure you have access to the camera in an XNA app), and yet you want to draw stuff in 3D.


OK, here's one that does actually affect me (happy now Clint?): Access to the calendar isn't available. Combine this with the fact that you not only don't have background tasks (not even the weak version iPhone OS supports), but you've also removed the API from WinMo that allowed you to schedule a task to start at a specific time in the future. This means you can have a task list app, but you can't let users set reminders have have them be notified when the time arrives.

If you want the bother of setting up a server, having the app call out to the server when the user sets a reminder and then have it send a notification at the appropriate time, you can work around it that way, but that's no good if the user is outside cell reception at the appointment time and seems like a lot of faff to do something simple that the phone could do internally very easily. It's also what iPhone developers were having to do a year ago. Thankfully iOS 4 provides for local notifications so you can set a message to appear to the user at a specific time in the future when your app isn't running. They do also allow you to add events to the calendar, but local notifications are more useful in this scenario because they provide a button on the dialog to launch the app.

I could also bang on about the very restricted access to Contact information or the limited ability to start the user off dialling, composing an SMS or email, but they don't affect me, although they will affect many other developers. iPhone OS lets you read and write contacts and there haven't been any complaints that I'm aware of of apps abusing this. It does have restrictions on sending SMSs and initiating phone calls, but what's weird is that WinMo allowed an app to do pretty much anything and there weren't really any complaints there either.


There's also the lack of any on-device data storage facility beyond saving files in isolated storage. iPhone OS has shipped with SQLite since day one and since 3.0 has come with a fast, lightweight object persistence library called Core Data. WP7 doesn't even include SQL CE. Why, who knows? Maybe the WP7 team only envisages torch/fart/tip-calculator apps being written - those are the things that Silverlight makes very easy.

Irrelevant? Really? WP7 is making a bet on a "closed" platform model, on .NET. The argument for native support is moot. It's not going to be supported in V1. WP7 team believes SL + XNA should provide a rich set of capabilities for application developers targetting WP7 who also already use VS and .NET.... It's not rocket science. The company is making a bet on managed code + mobile devices. It could be that managed code will find it's soul mate in this context. Who knows? The phone isn't out yet..... Let's give this a chance. Why not?

 

C