Coffeehouse Thread

108 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Disappointed about WP7 APIs

Back to Forum: Coffeehouse
  • User profile image
    Sven Groot

    Charles said:
    Sven Groot said:
    *snip*

    Then charge 2.50 USD to download it and use the cumulative income to pay for the yearly fee and also provide you with some cash for good sushi and sake. Smiley

    C

    Because the current WM version is free?

    Because the equivalent iPhone app is free?

    Because the dictionary files I'm using are free?

     

    Also note that this is entirely dependent on WP7 having built-in Japanese handwriting recognition (I know the beta at least has Japanese font support now, but that by itself is not enough). I could hypothetically make my Japanese input panel (which is currently a SIP under Windows Mobile, so it can be used with any application) part of the dictionary application, but I didn't write the handwriting recognition algorithm I use for that, and the code I based it on is GPL, so if I include it in the dictionary the entire dictionary automatically becomes GPL.

  • User profile image
    Charles

    Sven Groot said:
    Charles said:
    *snip*

    Because the current WM version is free?

    Because the equivalent iPhone app is free?

    Because the dictionary files I'm using are free?

     

    Also note that this is entirely dependent on WP7 having built-in Japanese handwriting recognition (I know the beta at least has Japanese font support now, but that by itself is not enough). I could hypothetically make my Japanese input panel (which is currently a SIP under Windows Mobile, so it can be used with any application) part of the dictionary application, but I didn't write the handwriting recognition algorithm I use for that, and the code I based it on is GPL, so if I include it in the dictionary the entire dictionary automatically becomes GPL.

    Fair enough. You provide an interesting scenario: paying to provide free apps. I don't know the details of the Marketplace model. Apparently, you do.


    C

  • User profile image
    Sven Groot

    Charles said:
    Sven Groot said:
    *snip*

    Fair enough. You provide an interesting scenario: paying to provide free apps. I don't know the details of the Marketplace model. Apparently, you do.


    C

    I'm not familiar with the exact details myself, but as far as I understand it, you have to pay the fee to publish apps on the marketplace, regardless of what they cost. And also, I believe it's not possible for me to just put the app on my website and have the users download it from there.

  • User profile image
    Sven Groot

    Charles said:
    Sven Groot said:
    *snip*

    Fair enough. You provide an interesting scenario: paying to provide free apps. I don't know the details of the Marketplace model. Apparently, you do.


    C

    The whole thing just became a moot point. I installed the developer tools beta, and there's no sign of any way to change input languages. There's not even any space on the keyboard for a button to cycle between input languages like the iPhone has, which leads me to believe that WP7 will be able to input text only in one language, probably linked to the UI language.

     

    This makes it impossible for me to develop a usable Japanese dictionary. It also means that I definitely won't be getting a WP7 device (even if they are released in Japan, which I'm not too sure of). For me a phone is only an option if: 1. I can buy one in Japan yet still use English UI, and 2. even with English UI, I can still read and input Japanese text.

     

    Its ability to do that is the primary reason why I picked an iPhone when I last got a new phone. WM6.x actually fails on both these criteria. I was hoping WP7 would do better but it seems unlikely at this point.

  • User profile image
    Charles

    Sven Groot said:
    Charles said:
    *snip*

    The whole thing just became a moot point. I installed the developer tools beta, and there's no sign of any way to change input languages. There's not even any space on the keyboard for a button to cycle between input languages like the iPhone has, which leads me to believe that WP7 will be able to input text only in one language, probably linked to the UI language.

     

    This makes it impossible for me to develop a usable Japanese dictionary. It also means that I definitely won't be getting a WP7 device (even if they are released in Japan, which I'm not too sure of). For me a phone is only an option if: 1. I can buy one in Japan yet still use English UI, and 2. even with English UI, I can still read and input Japanese text.

     

    Its ability to do that is the primary reason why I picked an iPhone when I last got a new phone. WM6.x actually fails on both these criteria. I was hoping WP7 would do better but it seems unlikely at this point.

    I'll ask somebody who knows.

     

    C

  • User profile image
    jaimer

    Sven Groot said:
    Charles said:
    *snip*

    The whole thing just became a moot point. I installed the developer tools beta, and there's no sign of any way to change input languages. There's not even any space on the keyboard for a button to cycle between input languages like the iPhone has, which leads me to believe that WP7 will be able to input text only in one language, probably linked to the UI language.

     

    This makes it impossible for me to develop a usable Japanese dictionary. It also means that I definitely won't be getting a WP7 device (even if they are released in Japan, which I'm not too sure of). For me a phone is only an option if: 1. I can buy one in Japan yet still use English UI, and 2. even with English UI, I can still read and input Japanese text.

     

    Its ability to do that is the primary reason why I picked an iPhone when I last got a new phone. WM6.x actually fails on both these criteria. I was hoping WP7 would do better but it seems unlikely at this point.

    hi Sven,

    For the release this year we are only supporting EFIGS ( English, French, Italian, German and Spanish) .. 

    We are of course going to add more languages soon after the release..

     

    Cheers,

    Jaime

     

  • User profile image
    jaimer

    Charles said:
    Sven Groot said:
    *snip*

    Fair enough. You provide an interesting scenario: paying to provide free apps. I don't know the details of the Marketplace model. Apparently, you do.


    C

    btw,  the $99 developer registration is waived for students..  

     

     

  • User profile image
    Charles

    Jaime Rodriguez said:
    Charles said:
    *snip*

    btw,  the $99 developer registration is waived for students..  

     

     

    Awesome. Smiley

     

    Thanks for the info, Jaime!

    C

     

  • User profile image
    Sven Groot

    Jaime Rodriguez said:
    Sven Groot said:
    *snip*

    hi Sven,

    For the release this year we are only supporting EFIGS ( English, French, Italian, German and Spanish) .. 

    We are of course going to add more languages soon after the release..

     

    Cheers,

    Jaime

     

    But does that mean that I can buy a phone anywhere in the world, and switch the UI to any of those languages? And that regardless of the UI language, I can still input any other language?

     

    If I buy a phone in (e.g.) the US, does it have only the English UI or can I set it to French, Italian, etc. and whatever languages you end up supporting after release? Can I input text using the French autocorrect dictionary even if my UI language is set to English? Once there is support for Japanese, will I be able to input Japanese even if my UI language is English?

     

    I bought my current iPhone 3G in Japan, yet I could switch the UI to English (I can also set it to Dutch if I want to). And although the UI is set to English, I can still read and write Japanese e-mail and SMS. In fact, I have 4 different keyboards set up, which I can cycle through easily even while typing a message: English, Dutch (for the autocorrect dictionary), Japanese romaji (type in roman characters, automatically convert to kana/kanji), and Emoji (a Japanese standard for smilies in phone e-mail and SMS). I need all four of those. I need to switch between all of those freely without changing the UI language.

     

    Will WP7 allow me to do that once the appropriate language support is available? That's the big question that I can't find an answer to.

  • User profile image
    rhm

    Clint said:
    rhm said:
    *snip*

    XNA is designed for games.  http://forums.xna.com/forums/p/2396/68400.aspx may have your answer if you want to leverage controls.

     

    What things are you missing that prevent you from creating an application?  Give me a list plus usage examples.

    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.

  • User profile image
    W3bbo

    Clint said:
    W3bbo said:
    *snip*

    so the lack of these c/c++ libraries is stopping you from building apps?

    Straw-man fallacy:

     

    "so the lack of these c/c++ libraries is stopping you from building apps?"

     

    I never said the lack of C/C++ code reuse was stopping me from building WP7 applications. I said it was stopping me, and tens of thousands of developers, from building whole classes of applications.

     

    Here is a list of applications that you can make for Android and iOS which you cannot do on WP7 because of this:

    • Augmented Reality
    • Musical instruments (proper ones, not cheap "press piano key, play("noteDFlat.wav");"-style applications)
    • Video editing
    • Sound-effect programs using DSP
    • Developing alternatives to system features, such as Input editors (remember how WM had a load of cool alternatives to the soft keyboard?)
    • Robotics applications (lots of robotics projects used to be powered by PocketPC devices using the device's host USB controller. In one project I'm working on we decided to go with using an ASUS Netbook because of the uncertaintly over using Windows CE as a viable robotics controller).
    • I could go on...

     

    ...if you actually can build these with the current API framework with Silverlight or XNA, I'd sincerely like to hear your work-arounds.

  • User profile image
    BitFlipper

    W3bbo said:
    Clint said:
    *snip*

    Straw-man fallacy:

     

    "so the lack of these c/c++ libraries is stopping you from building apps?"

     

    I never said the lack of C/C++ code reuse was stopping me from building WP7 applications. I said it was stopping me, and tens of thousands of developers, from building whole classes of applications.

     

    Here is a list of applications that you can make for Android and iOS which you cannot do on WP7 because of this:

    • Augmented Reality
    • Musical instruments (proper ones, not cheap "press piano key, play("noteDFlat.wav");"-style applications)
    • Video editing
    • Sound-effect programs using DSP
    • Developing alternatives to system features, such as Input editors (remember how WM had a load of cool alternatives to the soft keyboard?)
    • Robotics applications (lots of robotics projects used to be powered by PocketPC devices using the device's host USB controller. In one project I'm working on we decided to go with using an ASUS Netbook because of the uncertaintly over using Windows CE as a viable robotics controller).
    • I could go on...

     

    ...if you actually can build these with the current API framework with Silverlight or XNA, I'd sincerely like to hear your work-arounds.

    Well, you definitely raise some good points (and so does rhm). Some of the points seems to be related to performance issues (Musical instruments, DSP, etc). Others seem to relate to lack of APIs (USB controller, alternative keyboard, etc).

     

    For the performance issues, I guess we'd need to wait for hardware to see how much of a speed difference there really is. I already ported a pitch detection algorithm (using a heavily modified auto-correlation method) to WP7, and at least in the emulator I am getting acceptable performance, and I expect this to be better on actual hardware. Double-precision floating point performance will supposedly be good, even better that single precision. As far as the ARMv7 vector processing goes, it is possible that an API can be added at some point to expose this, right?

     

    I think we have to keep in mind that this is v1.0 and that the iPhone v1.0 didn't even have any way to write apps for it at all (well, there was that whole web-app thing). MS made it very clear that they are continuously adding APIs and features, Bluetooth and Flash being examples of this.

     

    BTW, you can mix some aspects of Silverlight and XNA, so picking SL for instance doesn't mean you can't use parts of XNA.

     

    I am surprised though that MS chose to make some of the same mistakes that Apple made, like lack of copy&paste, no multitasking, no side-loading. Apple fixed the first two, but how much outcry (bad press) did it take to get it fixed? Why not learn from those mistakes and do it right the first time around? For the app store, why not have an "official" app store, and also allow additional 3rd party stores with the understanding that there will be no guarantee that apps from those stores won't screw up your phone (malware, etc). Kinda like signed vs unsigned drivers - we know it can screw up our systems but we are willing to take the risk. And some healthy competition between app stores can only be good for everyone.

  • User profile image
    Ian2

    Jaime Rodriguez said:
    Charles said:
    *snip*

    btw,  the $99 developer registration is waived for students..  

     

     

    Ha!  My wife asked 'who is Jamie Rodriguez' this morning (I had your 'migrating apps' doc sticking out under a pile of magazines).  Great to see you posting here!

  • User profile image
    Charles

    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

  • User profile image
    Shining Arcanine

    Charles said:
    rhm said:
    *snip*

    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

    It looks to me that Microsoft is not making a bet on managed code so much as it is trying to fabricate a new platform into which it can lock developers before the rest of the world becomes compatible with its existing platform. Then after that, the new platform will mature, at which point the cycle will repeat.

     

    Microsoft has been advertising .NET as the greatest thing ever since around 2002, but I would not be surprised if Microsoft switches to a purely functional programming model in about 10 years and then proceeds to advertise that it is the greatest thing ever to get the world to switch, not because it necessarily is the greatest thing ever, but because Microsoft is trying to continually lock people into a platform that allows them to indefinitely charge fees at their discretion.

     

    I know that I am affirming the consequent by saying this, but everything Microsoft has done has been consistent with such an intention. Considering that the law of gravity is an affirmation of the consequent, I think that this kind of reasoning can be useful when a large number of observations are all consistent with it, which is true in both the case of Microsoft and the case of gravity.

     

    I think the resistance Microsoft has faced in terms of new versions of Windows demonstrates that people want stable APIs and mature programming models, that are supported by more companies than just Microsoft.

  • User profile image
    ZippyV

    Charles said:
    rhm said:
    *snip*

    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

    We need native code to get other browsers on WP7. The built-in browser is not up to par with the current standards and is therefore useless.

  • User profile image
    Shining Arcanine

    ZippyV said:
    Charles said:
    *snip*

    We need native code to get other browsers on WP7. The built-in browser is not up to par with the current standards and is therefore useless.

    Strictly speaking, native code is not necessary for such a thing, but it would mean that you would have to write your browser from scratch and it will be difficult to predict how it will perform. Either that, or someone will need to figure out a way to compile native code into MSIL.

  • User profile image
    rhm

    Charles said:
    rhm said:
    *snip*

    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

    Irrelevant, yes. You said:-

     

    "I actually think the idea behind focusing on a managed sandbox app model in this case is...

     

    b) you won't be able to crash the device with your buggy code since you won't be working at the memory level directly, etc..."

     

    50+ million iPhones says this is a false argument. There are lots of apps that crash, none of them take down the phone. Moreover, even if running unmanaged 3rd party code was a security or stability issue, it hardly warrants browser-style security given that the app store requirements mean that for stability concerns you can remove the app (not only from the store but apparently remote-delete it from people's phones) and for security concerns, you have the developer's name and address. But like I said, it's not a concern if your OS has good underpinnings.

     

    As for the subject of native code being moot, it might be now, but I wouldn't sound so glib about it given that what it means is you are metaphorically sticking your fingers up at developers experienced on other mobile platforms, including your own previous phone OS, in favour of generic .NET developers, most of whom spend their days writing web-related code. Now I'm sure devs will pick up WP7 development quickly enough to bang out millions of task list managers, tip calculators, branded RSS readers and other junk that fills app stores everywhere, but it's the games that make up the bulk of sales and Microsoft could have had hundreds ported over, but no, instead generic .NET developers are going to use XNA - an environment that's so far only attracted the attention of hobbyists (and then only because it's the only way to get code on an XBox without a publisher contract or big bucks to drop on a dev kit) and with little or no game development experience, will create what?

     

    "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?"

     

    Managed code already found it's soul mate on mobile devices about 10 years ago - it's called Java MIDP. For what it's worth, I'd prefer to do my iPhone development in C# - W3bbo is the one who's desperate to use native code - I'm just pointing out that the decision is not without consequences as far as games are concerned. I mainly entered this thread because it's about disappointment at the API surface of WP7 overall and I share that disappointment. It's not even where other platforms were 2 years ago - and while there are some things that have been left out probably for reasons of not having the resources to build them in version 1, there are other things where it's clear they were done for nanny-state reasons.

     

    And also, you can say "we couldn't get everything in, it's a version 1 product" to developers, but what about consumers. I couldn't recommend WP7 to anyone to actually buy based on it's capabilities unless it's very cheap. At the same time, how do we know this isn't another experiment that's going to be abandoned like Kin or left to rot like Zune HD (supported dropped in XNA4)?

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.