It seems that a lot of APIs are not in the first release and probably never will. I wonder what other limitations there are. Has anyone done some WP7 development and want's to share his/her experience? Has anyone experience in programming iPhone and/or Android and can speak about the advantages/disadvantages of the verious platforms?

Both Android and iPhone have constantly added in new APIs.

Clint said:

Build features or ship it.  Would you want it delayed?  New APIs and controls can be added after the fact. 

 

Both Android and iPhone have constantly added in new APIs.

Whatever the reason, for a platform that's shipping 2+ years after the competition, WP7's APIs are weak sauce. In many ways, both Silverlight and XNA are nice things to program, but you run up against the walls of that garden pretty quickly. Limited access to a lot of things that are taken for granted on iOS; the bizarre and unexplained dichotomy between Silverlight and XNA; no true 3d in Silverlight and no useful UI controls in XNA will make chosing one or the other tricky for some classes of app; no programmable shaders in XNA even though the hardware will support them; and of course no native code, meaning that porting games from iOS is off the agenda for most developers.

CreamFilling512 said:

Honestly, I think it looks fine for a V1 release, easily covers the 90% case.

Honestly, I think that's what's so awful. They had all this time to see what the competition is doing and prepare to leapfrog them, and what do they come out with? Something that does almost everything you can do with competing phones.

Bas said:

CreamFilling512 said:

*snip*

Honestly, I think that's what's so awful. They had all this time to see what the competition is doing and prepare to leapfrog them, and what do they come out with? Something that does almost everything you can do with competing phones.

Microsoft owns the best development platform in the world. That's why it's going to be awesome.

Maddus Mattus said:

Bas said:

*snip*

Microsoft owns the best development platform in the world. That's why it's going to be awesome.

Oh, the platform is awesome. Microsofts unwillingness to do more than the bare minimum in the mobile space is what isn't.

Bas said:

CreamFilling512 said:

*snip*

Honestly, I think that's what's so awful. They had all this time to see what the competition is doing and prepare to leapfrog them, and what do they come out with? Something that does almost everything you can do with competing phones.

I know what you mean, but give them some slack.

They started from a white piece of paper for Windows Phone 7 , so it just simple can't be done to leapfrog other platform. Because a lot of the API's build on the underlying platform. They choose to get the 90% case as perfect as possible and ship that.

Then with the power of Silverlight and XNA I'm pretty sure if the basis is stable they can easily leapfrog ahead of competition. XNA and Silverlight alow rapid development, in contract to objective C and C++ / Java the other platform are build on.

CKurt said:

Bas said:

*snip*

I know what you mean, but give them some slack.

 

They started from a white piece of paper for Windows Phone 7 , so it just simple can't be done to leapfrog other platform. Because a lot of the API's build on the underlying platform. They choose to get the 90% case as perfect as possible and ship that.

 

Then with the power of Silverlight and XNA I'm pretty sure if the basis is stable they can easily leapfrog ahead of competition. XNA and Silverlight alow rapid development, in contract to objective C and C++ / Java the other platform are build on.

 

The thing is, Microsoft are telegraphing this as very much a 1.0 release (feels more like a 0.9 to me, but anyway). I'll probably do a few simple Silverlight apps, same as everyone else will - the ease of Silverlight means the marketplace will be flooded with crap from day 1 - but I won't be recommending to anyone to buy a WP7 device.

Unless they are very cheap, there's no reason at all to buy one instead of a newish Andoid phone, or even the >1 year old iPhone 3GS. It's OK saying "what's more important, shipping or improving the APIs?", but I'm pretty sure that's not going to be the marketing message to consumers: Hey, we just wanted to ship a phone, sorry it's all a bit half-baked, but the next version will be great, promise!

Clint said:

Build features or ship it.  Would you want it delayed?  New APIs and controls can be added after the fact. 

 

Both Android and iPhone have constantly added in new APIs.

The iOS is at version 4 while Android is at 2.2. Windows Mobile is at version 7 with this release. I think by now it should have had these APIs.

Shining Arcanine said:

Clint said:

*snip*

The iOS is at version 4 while Android is at 2.2. Windows Mobile is at version 7 with this release. I think by now it should have had these APIs.

Windows Mobile is dead, they started from 0 with the new OS about a 1,5 years ago...

7 is just a name

Bas said:

Maddus Mattus said:

*snip*

Oh, the platform is awesome. Microsofts unwillingness to do more than the bare minimum in the mobile space is what isn't.

Maybe they figure they dont need to do anything

That the mobile devices in 10 years time will have grown so powerfull, they can use Windows 20?

CKurt said:

Bas said:

*snip*

I know what you mean, but give them some slack.

 

They started from a white piece of paper for Windows Phone 7 , so it just simple can't be done to leapfrog other platform. Because a lot of the API's build on the underlying platform. They choose to get the 90% case as perfect as possible and ship that.

 

Then with the power of Silverlight and XNA I'm pretty sure if the basis is stable they can easily leapfrog ahead of competition. XNA and Silverlight alow rapid development, in contract to objective C and C++ / Java the other platform are build on.

 

Give them some slack? Why? They've had all the slack they could have asked for. They've had years to look at what the competition was doing and where they were dropping the ball, and subsequently act upon it. This whole "Doing the bare minimum is good enough because it's a 1.0 release" mentality is horribly frustrating.

As for the platform, the fact that there aren't even any pivot or panorama controls - staples of the metro experience - is just pathetic. Why does this have to come down to some hobbyist on codeplex instead of just offering a native, supported control that's 100% consistent with the ones in the built-in apps? They hammer upon the greatness of the metro experience and then don't even provide people with the tools to actually create applications with a consistent UX? Inexcusable. So much for a great development platform.

Bas said:

CKurt said:

*snip*

Give them some slack? Why? They've had all the slack they could have asked for. They've had years to look at what the competition was doing and where they were dropping the ball, and subsequently act upon it. This whole "Doing the bare minimum is good enough because it's a 1.0 release" mentality is horribly frustrating.

 

As for the platform, the fact that there aren't even any pivot or panorama controls - staples of the metro experience - is just pathetic. Why does this have to come down to some hobbyist on codeplex instead of just offering a native, supported control that's 100% consistent with the ones in the built-in apps? They hammer upon the greatness of the metro experience and then don't even provide people with the tools to actually create applications with a consistent UX? Inexcusable. So much for a great development platform.

I agree with you on one point: They made the decission to reboot Windows Phone 7 to late. And indeed they did. It was to late, but still glad they made it... (Imagine Windows Mobile 7 to look like the leaked screenshots) But lets not keep looking to the past, once they decided to reboot, they made good progress.

En pivot and panorama controls are available on http://phone.codeplex.com , but are not made by hobbyist. They are made by microsoft and released out of band.

• I’m not on the Windows Phone team. This is not the official control, and i don’t know if they have plans for such controls in the future. The developer FAQ seems to suggest something may be coming down the road.
• This is not production code. I am using it as a learning experience for Silverlight, which i’ve started less than 2 weeks ago. I’m still learning about the technology and writing controls : there are lots of areas for improvements in the current implementation (quality and robustness, templates and customization, resource usage, fonts, themes, …).
• This is a pet project i’m working on during my free time, just for fun. For now there’s no plan to turn it into something more than a pet project, although i’d like to continue the effort and perhaps build something i will call the Pivot control.

Stay tuned for more, and remember : this is by no means a Microsoft supported and official project, i’m just a guy trying to learn Silverlight on the Phone. Please use the official controls if/when they are released.

I mean.. my god.

Bas said:

CKurt said:

*snip*

 

I mean.. my god.

Hmmmm, I could have sworn I saw a C9 interview about the controls where they said

"Please use these controls as they are official and will be updated frequently, so you don't need to change code and get better performence with these controls. This will also make different WP7 application, still have the same feel to it, taking advantage of what users allready know"

Looking for the interview right now...

(edit: did not find the interview)

Bas said:

CKurt said:

*snip*

Give them some slack? Why? They've had all the slack they could have asked for. They've had years to look at what the competition was doing and where they were dropping the ball, and subsequently act upon it. This whole "Doing the bare minimum is good enough because it's a 1.0 release" mentality is horribly frustrating.

 

As for the platform, the fact that there aren't even any pivot or panorama controls - staples of the metro experience - is just pathetic. Why does this have to come down to some hobbyist on codeplex instead of just offering a native, supported control that's 100% consistent with the ones in the built-in apps? They hammer upon the greatness of the metro experience and then don't even provide people with the tools to actually create applications with a consistent UX? Inexcusable. So much for a great development platform.

There has been an official announcement that a Pivot and Panorama control will be released in a few weeks.

Of course we all appreciate the time and energy Microsoft puts into making WP7 a worthy development platform, but on the other hand it's easy to get jealous about iOS and Android, since they are already established and a couple of iterations ahead. I really hope the pace of updates to WP7 is kept up and we see regular new releases like with Silverlight. I guess everybody agrees that there is only one chance to do it right. And I really would hate to switch to Java and/or Objective-C

Assuming this is true, I wonder if it's just a feature cut dictated by the looming deadlines, or if there is some deeper reason (security? privacy?) that I cannot grasp. For sure it is going to make using Live ID less appealing...

rhm said:

CKurt said:

*snip*

The thing is, Microsoft are telegraphing this as very much a 1.0 release (feels more like a 0.9 to me, but anyway). I'll probably do a few simple Silverlight apps, same as everyone else will - the ease of Silverlight means the marketplace will be flooded with crap from day 1 - but I won't be recommending to anyone to buy a WP7 device.

 

Unless they are very cheap, there's no reason at all to buy one instead of a newish Andoid phone, or even the >1 year old iPhone 3GS. It's OK saying "what's more important, shipping or improving the APIs?", but I'm pretty sure that's not going to be the marketing message to consumers: Hey, we just wanted to ship a phone, sorry it's all a bit half-baked, but the next version will be great, promise!

I would be happy just to have the hardware released. It is completely within the realm of possibility that this could be vaporware or even worse, another dead branch on the Microsoft platform tree, along with the Zune HD. I hope this three-screens-and-a-cloud thing isn't a shell game.

Speaking of games, did Steve Ballmer just say that there will Silverlight, Visual 2010 support for Windows Mobile 6.5x?

-Josh

CKurt said:

Shining Arcanine said:

*snip*

Windows Mobile is dead, they started from 0 with the new OS about a 1,5 years ago...

 

7 is just a name

That sounds like what Microsoft did with Windows Vista. Do you know why they did it with Windows Mobile?

Shining Arcanine said:

CKurt said:

*snip*

That sounds like what Microsoft did with Windows Vista. Do you know why they did it with Windows Mobile?

So they can wipe out the competition with the successor of WP7, like they did with the successor of Vista?

Sounds like a good strategy to me!

JoshRoss said:

rhm said:

*snip*

I would be happy just to have the hardware released. It is completely within the realm of possibility that this could be vaporware or even worse, another dead branch on the Microsoft platform tree, along with the Zune HD. I hope this three-screens-and-a-cloud thing isn't a shell game.

 

Speaking of games, did Steve Ballmer just say that there will Silverlight, Visual 2010 support for Windows Mobile 6.5x?

 

-Josh

There's hardware released right now, if you can get your hands on it. I can't, for the life of me, see how WP7 could be considered vapourware at this point...

And Ballmer was clearly referring to Windows Embedded Compact 7, not Windows Mobile 6.5.x.

PaoloM said:

JoshRoss said:

*snip*

There's hardware released right now, if you can get your hands on it. I can't, for the life of me, see how WP7 could be considered vapourware at this point...

 

And Ballmer was clearly referring to Windows Embedded Compact 7, not Windows Mobile 6.5.x.

Windows Embedded Compact 7? Do we really need another poorly named platform? The product names should reflect the lineage of the product. It looks like Windows Embedded CE 6.0 R3 supports silverlight, while 6.5 does not. Why do all these myriad of operating systems have to be called Windows? (This is another rhetorical question.)

Anyways, trying to stay on topic... Martin, just be glad you don't have to target a platform that may or may not be depreciated depending on whether or not a crow sits on a donkey.

-Josh

PaoloM said:

Shining Arcanine said:

*snip*

So they can wipe out the competition with the successor of WP7, like they did with the successor of Vista?

 

Sounds like a good strategy to me!

Has it? I think that Microsoft is too busy with its own forced obsolescence initiative to worry about its competitors. After all, it has been trying to kill Windows XP for a few years now as part of it and that has not worked very well. In the mean time, Mac OS X has been siphoning significant marketshare from Windows and other UNIX-like operating systems have been growing in popularity too, although they have been growing at a slower rate than Mac OS X.

rhm said:

Clint said:

*snip*

Whatever the reason, for a platform that's shipping 2+ years after the competition, WP7's APIs are weak sauce. In many ways, both Silverlight and XNA are nice things to program, but you run up against the walls of that garden pretty quickly. Limited access to a lot of things that are taken for granted on iOS; the bizarre and unexplained dichotomy between Silverlight and XNA; no true 3d in Silverlight and no useful UI controls in XNA will make chosing one or the other tricky for some classes of app; no programmable shaders in XNA even though the hardware will support them; and of course no native code, meaning that porting games from iOS is off the agenda for most developers.

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.

JoshRoss said:

PaoloM said:

*snip*

Windows Embedded Compact 7? Do we really need another poorly named platform? The product names should reflect the lineage of the product. It looks like Windows Embedded CE 6.0 R3 supports silverlight, while 6.5 does not. Why do all these myriad of operating systems have to be called Windows? (This is another rhetorical question.)

 

Anyways, trying to stay on topic... Martin, just be glad you don't have to target a platform that may or may not be depreciated depending on whether or not a crow sits on a donkey.

 

-Josh

Why are you confusing Windows Embedded with Windows Mobile?

Shining Arcanine said:

PaoloM said:

*snip*

Has it? I think that Microsoft is too busy with its own forced obsolescence initiative to worry about its competitors. After all, it has been trying to kill Windows XP for a few years now as part of it and that has not worked very well. In the mean time, Mac OS X has been siphoning significant marketshare from Windows and other UNIX-like operating systems have been growing in popularity too, although they have been growing at a slower rate than Mac OS X.

Oh yes. While Apple is busy diverting resources and effort into the iOS devices, Windows 7 is selling seven copies each second.

I'm not saying that Apple is doing badly, au contraire, but Linux is pretty much dead on the desktop and reeling back on the server, and OS/X is dramatically failing to capitalize on the runaway success of the iPhone and iPad.

Vista was a necessary technological step to pave the way for the current Windows generation. And still managed to outsold every other OS on the market.

PaoloM said:

Shining Arcanine said:

*snip*

Oh yes. While Apple is busy diverting resources and effort into the iOS devices, Windows 7 is selling seven copies each second.

 

I'm not saying that Apple is doing badly, au contraire, but Linux is pretty much dead on the desktop and reeling back on the server, and OS/X is dramatically failing to capitalize on the runaway success of the iPhone and iPad.

 

Vista was a necessary technological step to pave the way for the current Windows generation. And still managed to outsold every other OS on the market.

Good point, though you're assuming that a future iOS devices won't be laptops. I don't think Apple would be daft enough to take MS on from the desktop end where they're strongest. Chances are they'll go for the soft underbelly; the mobile market where MS doesn't seem to know what it's doing.  Gain a foothold there, then start on the desktop when they have thousands of developers and and millions of iPhone users who are already familiar with the iOS.

I am sure that they have had to do a LOT of optimizing to get silverlight to run quickly on a 1ghz processor.  And... I am very glad they did, because developing in silverlight is definitely a lot nicer then developing in the cryptic java based mvc model offered by google, or the objective c that apple is so proud of...

That being said, I know how frusterating it can be when you hit a wall, and lets face it we allways do when developing an application!

PaoloM said:

JoshRoss said:

*snip*

Why are you confusing Windows Embedded with Windows Mobile?

My point exactly! There is no need for any of this confusion. It is marketing gone wild! Which coincidentally, sounds more fun that it actually turns out to be. I would love to have the job of the guy, gal, or committee, that names products. Just give me the $125k or so a year and I will randomly append technobabble together, and prefix it with Windows and suffix it with a bigger integer than some other product that I have recently named. How does Windows Embedded Lite for Small Handheld Kitchen Appliances 6.9.2 sound? If you buy it now, I'll throw in this nut chopper, a $39 value, yours for absolutely free, just pay shipping and handling charges.

-Josh

JoshRoss said:

PaoloM said:

*snip*

My point exactly! There is no need for any of this confusion. It is marketing gone wild! Which coincidentally, sounds more fun that it actually turns out to be. I would love to have the job of the guy, gal, or committee, that names products. Just give me the $125k or so a year and I will randomly append technobabble together, and prefix it with Windows and suffix it with a bigger integer than some other product that I have recently named. How does Windows Embedded Lite for Small Handheld Kitchen Appliances 6.9.2 sound? If you buy it now, I'll throw in this nut chopper, a $39 value, yours for absolutely free, just pay shipping and handling charges.

 

-Josh

I concur on the confusion.

PaoloM said:

Shining Arcanine said:

*snip*

Oh yes. While Apple is busy diverting resources and effort into the iOS devices, Windows 7 is selling seven copies each second.

 

I'm not saying that Apple is doing badly, au contraire, but Linux is pretty much dead on the desktop and reeling back on the server, and OS/X is dramatically failing to capitalize on the runaway success of the iPhone and iPad.

 

Vista was a necessary technological step to pave the way for the current Windows generation. And still managed to outsold every other OS on the market.

Are you sure that those are all Windows 7 sales? Many companies today seem to be buying Windows 7 licenses because it allows them to obtain more copies of Windows XP. Micorsoft is more than happy to advertise such sales as being Windows 7 sales, but in reality, the only thing that was being purchased was Windows XP.

Not to mention, the 7 copies a second is not a constant rate. It is likely represents some average over time, most likely picked in such a way that the figure was as high as possible. I consider it highly improbable that the graph of sales per second with respect to time is  y = [0.65, 0.75).

gogogadget said:

Android started out with a lot broader API then apple, but the platform is only now becoming stable.  I'd rather have fewer features, but have them actually not crash the phone.  You know, do it right or not at all.  They are probably finding that things like the blur effect are not implemented in an efficient enough manner to run on a 1ghz machine.  Keep in mind that as powerfull as these phones are today they are only roughly equivelant to a 10 year old desktop in computing power. 

 

I am sure that they have had to do a LOT of optimizing to get silverlight to run quickly on a 1ghz processor.  And... I am very glad they did, because developing in silverlight is definitely a lot nicer then developing in the cryptic java based mvc model offered by google, or the objective c that apple is so proud of...

 

That being said, I know how frusterating it can be when you hit a wall, and lets face it we allways do when developing an application!

I believe that google offers two models for GUI programming on Android. They offer a tradditional MVC model, or a XML-based model:

http://developer.android.com/resources/tutorials/hello-world.html

They also support native code development in C/C++:

http://developer.android.com/sdk/ndk/index.html

They even support "codeless development":

http://arstechnica.com/open-source/news/2010/07/google-demos-codeless-android-development-tool-for-students.ars

While I am certain that Apple's iPhone requires all code to be written in Objective-C for Apple specific APIs, I am not certain about Windows Mobile 7. Does it require that you do programming with Silverlight, or does it offer other options?

The number of days between press conferences if MS was to hold one every time they sold 1 million copies of Windows 7.

BitFlipper said:

1.6

The number of days between press conferences if MS was to hold one every time they sold 1 million copies of Windows 7.

It isn't a fair to compare sales of a physical device that people buy because it's desireable to sales of software pre-loaded on computers that people buy without really having much say in the matter.

I'd much prefer to see the results of a neutral un-biased customer satisfaction survey instead.

W3bbo said:

BitFlipper said:

*snip*

It isn't a fair to compare sales of a physical device that people buy because it's desireable to sales of software pre-loaded on computers that people buy without really having much say in the matter.

 

I'd much prefer to see the results of a neutral un-biased customer satisfaction survey instead.

So these same people could not choose a Mac when they decided to buy a computer?

Besides, my point is just to show how ridiculous it is that Apple holds a press conference every time they sell 1 million of a product.

BitFlipper said:

W3bbo said:

*snip*

So these same people could not choose a Mac when they decided to buy a computer?

 

Besides, my point is just to show how ridiculous it is that Apple holds a press conference every time they sell 1 million of a product.

Man, this thread has really wound down a rabbit hole.... So, what are the issues you're having with WP7 APIs? Please elaborate.

C

BitFlipper said:

1.6

The number of days between press conferences if MS was to hold one every time they sold 1 million copies of Windows 7.

Pizza.

What I am eating right now.

Charles said:

BitFlipper said:

*snip*

Man, this thread has really wound down a rabbit hole.... So, what are the issues you're having with WP7 APIs? Please elaborate.

C

Whilst my disappointment about there not being a native API is well-known, I'd like to justify it with the following bullet points. I would appreciate an "officially supported approach" response to the scenarios I propose:

• Running native code allows for raw access to the hardware and to invoke and work with pieces of the system directly. I made a post about how a guy I knew wrote software that set up Wi-Fi based iTunes synchronisation. These kinds of utilities are impossible to achieve in a sandboxed environment. Does Microsoft believe we'll (both users and developers) be satisfied with applications that cannot do anything more than "take in information, process it, and present it to the user"?
• The inability to run native binaries means we cannot port over classic games like Doom, Quake, or many other open-source applications already available for other platforms. It also means we cannot use preexisting C++ libraries like OpenCV or GMP. "Compiling C++ to CIL" is not an option because only Verifiable CIL is allowed. Right now the only real C# vision library is AForge, which whilst good, is nothing compared to OpenCV, and things like this mean that we won't see any "cool" Augmented Reality projects for WP7 because the effort involved in porting over OpenCV to C# would be tremendous.
• High-performance applications would be impossible to work with. Painting programs, for example, do lots of pixel work which requires pointer arithmetic in order to not lag, but that's verboten.
• Lack of competition: I feel it's unfair that Microsoft gets to develop their applications using native code (IE, Word/Excel, PIM, etc) but we become second-class citizens. How will this foster a true "partner" spirit between Microsoft and ISVs?

I'll play along with WP7 for the basic app: the usual sort that does the usual "information processing" tasks, but if Microsoft wants to see innovative and eye-catching applications they're going to have to make it possible to run native code.

I feel the restriction on non-verifiable code is stupid: CLR programs run in a sandbox anyway and it won't stop programs from magically crashing, yet it makes certain classes of applications extremely difficult, if not impossible, to implement, such as (as I said) painting or image processing applications.

W3bbo said:

Charles said:

*snip*

Whilst my disappointment about there not being a native API is well-known, I'd like to justify it with the following bullet points. I would appreciate an "officially supported approach" response to the scenarios I propose:

 

• Running native code allows for raw access to the hardware and to invoke and work with pieces of the system directly. I made a post about how a guy I knew wrote software that set up Wi-Fi based iTunes synchronisation. These kinds of utilities are impossible to achieve in a sandboxed environment. Does Microsoft believe we'll (both users and developers) be satisfied with applications that cannot do anything more than "take in information, process it, and present it to the user"?
• The inability to run native binaries means we cannot port over classic games like Doom, Quake, or many other open-source applications already available for other platforms. It also means we cannot use preexisting C++ libraries like OpenCV or GMP. "Compiling C++ to CIL" is not an option because only Verifiable CIL is allowed. Right now the only real C# vision library is AForge, which whilst good, is nothing compared to OpenCV, and things like this mean that we won't see any "cool" Augmented Reality projects for WP7 because the effort involved in porting over OpenCV to C# would be tremendous.
• High-performance applications would be impossible to work with. Painting programs, for example, do lots of pixel work which requires pointer arithmetic in order to not lag, but that's verboten.
• Lack of competition: I feel it's unfair that Microsoft gets to develop their applications using native code (IE, Word/Excel, PIM, etc) but we become second-class citizens. How will this foster a true "partner" spirit between Microsoft and ISVs?

I'll play along with WP7 for the basic app: the usual sort that does the usual "information processing" tasks, but if Microsoft wants to see innovative and eye-catching applications they're going to have to make it possible to run native code.

 

I feel the restriction on non-verifiable code is stupid: CLR programs run in a sandbox anyway and it won't stop programs from magically crashing, yet it makes certain classes of applications extremely difficult, if not impossible, to implement, such as (as I said) painting or image processing applications.

I'm more concerned over the "develop in Silverlight" garbage. Silverlight is basically a gimped version of .NET, a huge step back in everyway. For some reason the prospect of having less functionality and tooling available exictes people to no end. It has a cool name and abstract logo!

Charles said:

BitFlipper said:

*snip*

Man, this thread has really wound down a rabbit hole.... So, what are the issues you're having with WP7 APIs? Please elaborate.

C

LOL, ok sorry.  Will try to stay on topic...

For me, the two I noticed:

Lack of ComboBox Control

I was surprized to find there is no combo box control. From the MSDN forums, the reason given was that it doesn't "fit in with the Metro design". Except in the emulator if you go to Settings, you'll find at least 3 different ways that the designers came up with to work around the fact that there is no combo box:

1. Click on "theme", and the control expands, pushing down the controls below it in order to expose the available selections.
2. Click on "region & language", and you get options where if you click them, you go to a completely different page that lists the available options.
3. Although this option no longer seems to take you anywhere after upgrading to the beta, previously selecting "date & time", then toggling one of the options (forgot which one exactly) caused some additional options to be exposed. If you then selected some of them, you got one of those "one-arm-bandid" type spin wheel controls.

So just in that area of the UI alone, there is a huge amount of inconsistency already. I don't know how app developers are supposed to be consistent when the basic, built-in UI is already all over the place. MS better fix it soon because we will end up with a multitude of combo box implementations, each looking and working in a different way.

Microsophone input Sample Rate

Not really a big issue for most people, but you can't set the sample rate on the mic input. This is a problem for me since I want to develop an app that detects the pitch of an incoming voice. This calculation is pretty complicated, and the higher the sample rate, the more CPU cycles you use processing the signal. Since the highest that a person's voice can typically go is ~1.6KHz, the highest sample rate I really need is about 3.2KHz.  Except I'm stuck at a fixed sample rate. In the pre-beta emulator, this was 44.1KHz. For the beta, this is 16KHz. The beta is better (for my purposes, anyway), but still 5 times what I need. Supposedly the way this works is that WP7 will detect the highest sample rate the hardware supports, and then use that. There are no plans to make this an app-settable value as far as I know.

W3bbo said:

Charles said:

*snip*

Whilst my disappointment about there not being a native API is well-known, I'd like to justify it with the following bullet points. I would appreciate an "officially supported approach" response to the scenarios I propose:

 

• Running native code allows for raw access to the hardware and to invoke and work with pieces of the system directly. I made a post about how a guy I knew wrote software that set up Wi-Fi based iTunes synchronisation. These kinds of utilities are impossible to achieve in a sandboxed environment. Does Microsoft believe we'll (both users and developers) be satisfied with applications that cannot do anything more than "take in information, process it, and present it to the user"?
• The inability to run native binaries means we cannot port over classic games like Doom, Quake, or many other open-source applications already available for other platforms. It also means we cannot use preexisting C++ libraries like OpenCV or GMP. "Compiling C++ to CIL" is not an option because only Verifiable CIL is allowed. Right now the only real C# vision library is AForge, which whilst good, is nothing compared to OpenCV, and things like this mean that we won't see any "cool" Augmented Reality projects for WP7 because the effort involved in porting over OpenCV to C# would be tremendous.
• High-performance applications would be impossible to work with. Painting programs, for example, do lots of pixel work which requires pointer arithmetic in order to not lag, but that's verboten.
• Lack of competition: I feel it's unfair that Microsoft gets to develop their applications using native code (IE, Word/Excel, PIM, etc) but we become second-class citizens. How will this foster a true "partner" spirit between Microsoft and ISVs?

I'll play along with WP7 for the basic app: the usual sort that does the usual "information processing" tasks, but if Microsoft wants to see innovative and eye-catching applications they're going to have to make it possible to run native code.

 

I feel the restriction on non-verifiable code is stupid: CLR programs run in a sandbox anyway and it won't stop programs from magically crashing, yet it makes certain classes of applications extremely difficult, if not impossible, to implement, such as (as I said) painting or image processing applications.

"Running native code allows for raw access to the hardware"

Er, no. Not unless you're allowed to write drivers. The only difference between native code and managed code is that the latter is inherently portable. Any other difference comes down to what API's you expose and there is no guarantee that a native code API would expose any more than you currently get.

"The inability to run native binaries means we cannot port over classic games like Doom, Quake, or many other open-source applications already available for other platforms"

Stretching the point somewhat. It's a phone. The vast majority of those titles would need major reworking to be viable titles on any phone anyway (if they ever would be). And, as Apple have shown, if it's worth doing people will rewrite them.

"Painting programs, for example, do lots of pixel work which requires pointer arithmetic in order to not lag"

Seriously? You think there is going to be major calls for painting applications? Again, it's a phone. And Silverlight does have the ability to support custom pixel shaders and the perf differences between native/JITted code are not nearly as vast as some people want to believe.

"How will this foster a true "partner" spirit between Microsoft and ISVs"

By guaranteeing that an app written for WP7 will work on every single Windows Phone released from now on? By assuring developers they won't have to  re-release/rework titles when WP8 comes along (think side-by-side VMs)? By eradicating hardware dependency from the equation entirely, allowing future WP-like devices to use whatever CPU architecture is appropriate, entirely transparently?

W3bbo said:

Charles said:

*snip*

Whilst my disappointment about there not being a native API is well-known, I'd like to justify it with the following bullet points. I would appreciate an "officially supported approach" response to the scenarios I propose:

 

• Running native code allows for raw access to the hardware and to invoke and work with pieces of the system directly. I made a post about how a guy I knew wrote software that set up Wi-Fi based iTunes synchronisation. These kinds of utilities are impossible to achieve in a sandboxed environment. Does Microsoft believe we'll (both users and developers) be satisfied with applications that cannot do anything more than "take in information, process it, and present it to the user"?
• The inability to run native binaries means we cannot port over classic games like Doom, Quake, or many other open-source applications already available for other platforms. It also means we cannot use preexisting C++ libraries like OpenCV or GMP. "Compiling C++ to CIL" is not an option because only Verifiable CIL is allowed. Right now the only real C# vision library is AForge, which whilst good, is nothing compared to OpenCV, and things like this mean that we won't see any "cool" Augmented Reality projects for WP7 because the effort involved in porting over OpenCV to C# would be tremendous.
• High-performance applications would be impossible to work with. Painting programs, for example, do lots of pixel work which requires pointer arithmetic in order to not lag, but that's verboten.
• Lack of competition: I feel it's unfair that Microsoft gets to develop their applications using native code (IE, Word/Excel, PIM, etc) but we become second-class citizens. How will this foster a true "partner" spirit between Microsoft and ISVs?

I'll play along with WP7 for the basic app: the usual sort that does the usual "information processing" tasks, but if Microsoft wants to see innovative and eye-catching applications they're going to have to make it possible to run native code.

 

I feel the restriction on non-verifiable code is stupid: CLR programs run in a sandbox anyway and it won't stop programs from magically crashing, yet it makes certain classes of applications extremely difficult, if not impossible, to implement, such as (as I said) painting or image processing applications.

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

a) there are many programmers today who are comfortable with the .NET model and the supporting tools are rather mature and capable,

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

c) we're trying to make programming apps on WP7 more accessible to lower-skilled developers/hobbyists, rather than focusing primarily on the professional and highly-skilled engineers

WP7 will be the best PC phone Microsoft has ever released. We're navigating through uncharted waters as far as we're concerned: WP7 aims to employ simplified experience from the app model to the UI.... In some sense, this is not our typical behavior, so I am happy we're breaking out of our comfortable straightjacket and taking a chance here.

I am a big fan of native code, as is Microsoft, of course. Not supporting it as a platform tool for building WP7 apps doesn't mean WP7 isn't useful for pro developers... The number of scenarios that are possible to write with .NET (SL/XNA) are many, not few.

Watch the C9 Live @ TechED NA for the official response regarding no-native on WP7 (Carmine007 asks "why are you forcing developers to use managed code..."): http://channel9.msdn.com/posts/NicFill/Ch9Live-at-TechEd-NA-2010-Talking-WP7-with-Brandon-Watson--Peter-Torr/

C

Bass said:

W3bbo said:

*snip*

I'm more concerned over the "develop in Silverlight" garbage. Silverlight is basically a gimped version of .NET, a huge step back in everyway. For some reason the prospect of having less functionality and tooling available exictes people to no end. It has a cool name and abstract logo!

Actually I think it is the opposite. Many people find Silverlight to be an ideal environment to develop the type of "sandboxed" apps you will find on a phone. While I agree that the loss of native code development is a problem for some, I really have to wonder how much really. If Silverlight gives you everything you need, why would you need to P/Invoke? Yes you will lose some performance benefits since you can't do native pointer arithmetic, but have you done tests on actual hardware to see how much of a problem it really is? How large will this graphic be that you will be manipulating on your phone? No, really?

You obviously have issues with Silverlight and probably with .Net in general. That doesn't mean everyone else have these issues.

I saw a slide show somewhere (ok, I saw it here) where someone did a side-by-side comparison of building a basic app for iPhone and WM7. It's like day and night. WP7 development is much cleaner and faster. Quite eye-opening for someone like me that have not done any iPhone development.

AndyC said:

W3bbo said:

*snip*

"Running native code allows for raw access to the hardware"

 

Er, no. Not unless you're allowed to write drivers. The only difference between native code and managed code is that the latter is inherently portable. Any other difference comes down to what API's you expose and there is no guarantee that a native code API would expose any more than you currently get.

 

"The inability to run native binaries means we cannot port over classic games like Doom, Quake, or many other open-source applications already available for other platforms"

 

Stretching the point somewhat. It's a phone. The vast majority of those titles would need major reworking to be viable titles on any phone anyway (if they ever would be). And, as Apple have shown, if it's worth doing people will rewrite them.

 

"Painting programs, for example, do lots of pixel work which requires pointer arithmetic in order to not lag"

 

Seriously? You think there is going to be major calls for painting applications? Again, it's a phone. And Silverlight does have the ability to support custom pixel shaders and the perf differences between native/JITted code are not nearly as vast as some people want to believe.

 

"How will this foster a true "partner" spirit between Microsoft and ISVs"

 

By guaranteeing that an app written for WP7 will work on every single Windows Phone released from now on? By assuring developers they won't have to  re-release/rework titles when WP8 comes along (think side-by-side VMs)? By eradicating hardware dependency from the equation entirely, allowing future WP-like devices to use whatever CPU architecture is appropriate, entirely transparently?

"The only difference between native code and managed code is that the latter is inherently portable. Any other difference comes down to what API's you expose and there is no guarantee that a native code API would expose any more than you currently get."

Managed APIs for doing things tend to simply be wrappers around native APIs, so the range of functionality possible with managed applications will always be a subset of what native code can do.

I wouldn't be arguing this point if P/Invoke was allowed, since then Managed apps can call native APIs (albiet with some overhead), but as some people have already pointed out some things (e.g. controlling the flashlight or device-specific hardware provided by OEMs) really are just impossible.

"And, as Apple have shown, if it's worth doing people will rewrite them."

Apple hasn't shown anything. You don't need to rewrite anything either: You can use the same C/C++ libraries on the desktop as you can on the iPhone. Doom has been ported to the iPhone, not rewritten, as has Quake 3. Biiig difference.

You ignored my point about libraries simply too big for a small team to rewrite, such as OpenCV. Yet if this library was available we'd see a whole load of innovative camera-based applications such as augmented reality. As things stand, we won't see anything like this, ever, on WP7.

"Seriously? You think there is going to be major calls for painting applications? Again, it's a phone. And Silverlight does have the ability to support custom pixel shaders and the perf differences between native/JITted code are not nearly as vast as some people want to believe."

There are a large number of popular finger-painting applications on the iPhone and iPad. Then there'a also photo-processing applications and applications that process real-time video. .NET on Windows can sort-of get away with this because the GDI+ System.Drawing API is fast enough for many tasks, but it doesn't exist under Silverlight-on-WP7.

Pixel Shaders aren't the same thing, and you can't do everything with them either.

"By guaranteeing that an app written for WP7 will work on every single Windows Phone released from now on?"

Funny that, I've got applications developed for Pocket PC 2000 that run perfectly fine on my Windows Mobile device. You're basing your argument on the assumption that there are viable alternatives to ARM when there aren't.

Charles said:

W3bbo said:

*snip*

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

 

a) there are many programmers today who are comfortable with the .NET model and the supporting tools are rather mature and capable,

 

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

 

c) we're trying to make programming apps on WP7 more accessible to lower-skilled developers/hobbyists, rather than focusing primarily on the professional and highly-skilled engineers

 

WP7 will be the best PC phone Microsoft has ever released. We're navigating through uncharted waters as far as we're concerned: WP7 aims to employ simplified experience from the app model to the UI.... In some sense, this is not our typical behavior, so I am happy we're breaking out of our comfortable straightjacket and taking a chance here.

 

I am a big fan of native code, as is Microsoft, of course. Not supporting it as a platform tool for building WP7 apps doesn't mean WP7 isn't useful for pro developers... The number of scenarios that are possible to write with .NET (SL/XNA) are many, not few.

 

Watch the C9 Live @ TechED NA for the official response regarding no-native on WP7 (Carmine007 asks "why are you forcing developers to use managed code..."): http://channel9.msdn.com/posts/NicFill/Ch9Live-at-TechEd-NA-2010-Talking-WP7-with-Brandon-Watson--Peter-Torr/

 

C

"a) there are many programmers today who are comfortable with the .NET model and the supporting tools are rather mature and capable"

That's a fine observation, but there are also many more programmers today who are comfortable with the C/C++ model and the supporting tools are even more mature and capable.

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

That's a weak argument, Windows CE has always been a pre-emptively multitasking OS. user-mode applications cannot crash the device. If a native application dereferences a null pointer it will crash just as well as it would on desktop Windows, but the system will continue running happilly enough. Removing pointer arithmetic doesn't stop programs from crashing.

"c) we're trying to make programming apps on WP7 more accessible to lower-skilled developers/hobbyists, rather than focusing primarily on the professional and highly-skilled engineers"

For the very golden nuggets you'll find by adopting that policy you'll have to wade through a huge amount of really awful applications with no conceivable utility. I hypotheise that Microsoft has already effectively doomed the Marketplace by not adopting minimum quality standards. I thought Windows Phone 7 was about creating a first-class mobile experience unlike the hodgepodge of Windows Mobile, but by lowering standards like this you're only bringing us back to those awful programs spamming PocketGear et al.

I'll also like to remind everyone that Microsoft has never won a D&AD award, yet their competitors have. Go figure.

"WP7 will be the best PC phone Microsoft has ever released. We're navigating through uncharted waters as far as we're concerned: WP7 aims to employ simplified experience from the app model to the UI.... In some sense, this is not our typical behavior, so I am happy we're breaking out of our comfortable straightjacket and taking a chance here."

Contradiction there. A "PC" lets you do what you want to do with it, free of any first-party control, if you wanted that then you went with Nintendo. WP7 is worse than Apple in this regard, and no-one considers the iPhone a "PC phone". WP7 devices are halfway between Smartphone and Feature Phone.

"I am a big fan of native code, as is Microsoft, of course. Not supporting it as a platform tool for building WP7 apps doesn't mean WP7 isn't useful for pro developers... The number of scenarios that are possible to write with .NET (SL/XNA) are many, not few."

I never said that .NET had "few" scenarios, just that the more adventurous and innovative "out of the box" applications are only really possible with native code given the state of the entire developer ecosystem right now (e.g.... again, OpenCV).

W3bbo said:

AndyC said:

*snip*

"The only difference between native code and managed code is that the latter is inherently portable. Any other difference comes down to what API's you expose and there is no guarantee that a native code API would expose any more than you currently get."

 

Managed APIs for doing things tend to simply be wrappers around native APIs, so the range of functionality possible with managed applications will always be a subset of what native code can do.

 

I wouldn't be arguing this point if P/Invoke was allowed, since then Managed apps can call native APIs (albiet with some overhead), but as some people have already pointed out some things (e.g. controlling the flashlight or device-specific hardware provided by OEMs) really are just impossible.

 

"And, as Apple have shown, if it's worth doing people will rewrite them."

 

Apple hasn't shown anything. You don't need to rewrite anything either: You can use the same C/C++ libraries on the desktop as you can on the iPhone. Doom has been ported to the iPhone, not rewritten, as has Quake 3. Biiig difference.

 

You ignored my point about libraries simply too big for a small team to rewrite, such as OpenCV. Yet if this library was available we'd see a whole load of innovative camera-based applications such as augmented reality. As things stand, we won't see anything like this, ever, on WP7.

 

"Seriously? You think there is going to be major calls for painting applications? Again, it's a phone. And Silverlight does have the ability to support custom pixel shaders and the perf differences between native/JITted code are not nearly as vast as some people want to believe."

 

There are a large number of popular finger-painting applications on the iPhone and iPad. Then there'a also photo-processing applications and applications that process real-time video. .NET on Windows can sort-of get away with this because the GDI+ System.Drawing API is fast enough for many tasks, but it doesn't exist under Silverlight-on-WP7.

 

Pixel Shaders aren't the same thing, and you can't do everything with them either.

 

"By guaranteeing that an app written for WP7 will work on every single Windows Phone released from now on?"

 

Funny that, I've got applications developed for Pocket PC 2000 that run perfectly fine on my Windows Mobile device. You're basing your argument on the assumption that there are viable alternatives to ARM when there aren't.

 

 

 

Actually to add to this, Android and iPhone use the same exact graphics library: OpenGL ES. Which makes porting between them trivial.

Porting a full blown OpenGL app to OpenGL ES is trivial as well. That's how iPhone got AAA games so quickly.

Bass said:

W3bbo said:

*snip*

Actually to add to this, Android and iPhone use the same exact graphics library: OpenGL ES. Which makes porting between them trivial.

 

Porting a full blown OpenGL app to OpenGL ES is trivial as well. That's how iPhone got AAA games so quickly.

And the surprising thing is that OpenGL ES worked fine on Windows Mobile 5. What a shame we can't use this.

W3bbo said:

Bass said:

*snip*

And the surprising thing is that OpenGL ES worked fine on Windows Mobile 5. What a shame we can't use this.

I wouldn't be suprised if XNA on most WinMo7 phones is just a wrapper around OpenGL ES anyway.

W3bbo said:

AndyC said:

*snip*

"The only difference between native code and managed code is that the latter is inherently portable. Any other difference comes down to what API's you expose and there is no guarantee that a native code API would expose any more than you currently get."

 

Managed APIs for doing things tend to simply be wrappers around native APIs, so the range of functionality possible with managed applications will always be a subset of what native code can do.

 

I wouldn't be arguing this point if P/Invoke was allowed, since then Managed apps can call native APIs (albiet with some overhead), but as some people have already pointed out some things (e.g. controlling the flashlight or device-specific hardware provided by OEMs) really are just impossible.

 

"And, as Apple have shown, if it's worth doing people will rewrite them."

 

Apple hasn't shown anything. You don't need to rewrite anything either: You can use the same C/C++ libraries on the desktop as you can on the iPhone. Doom has been ported to the iPhone, not rewritten, as has Quake 3. Biiig difference.

 

You ignored my point about libraries simply too big for a small team to rewrite, such as OpenCV. Yet if this library was available we'd see a whole load of innovative camera-based applications such as augmented reality. As things stand, we won't see anything like this, ever, on WP7.

 

"Seriously? You think there is going to be major calls for painting applications? Again, it's a phone. And Silverlight does have the ability to support custom pixel shaders and the perf differences between native/JITted code are not nearly as vast as some people want to believe."

 

There are a large number of popular finger-painting applications on the iPhone and iPad. Then there'a also photo-processing applications and applications that process real-time video. .NET on Windows can sort-of get away with this because the GDI+ System.Drawing API is fast enough for many tasks, but it doesn't exist under Silverlight-on-WP7.

 

Pixel Shaders aren't the same thing, and you can't do everything with them either.

 

"By guaranteeing that an app written for WP7 will work on every single Windows Phone released from now on?"

 

Funny that, I've got applications developed for Pocket PC 2000 that run perfectly fine on my Windows Mobile device. You're basing your argument on the assumption that there are viable alternatives to ARM when there aren't.

 

 

 

"Managed APIs for doing things tend to simply be wrappers around native APIs, so the range of functionality possible with managed applications will always be a subset of what native code can do."

No. That may be true on Windows, where there was a well established native API with a managed stack then added at a much later date, there is simply no reason that it has to be true on an entirely new platform, which is what Windows Phone 7 is.  It's a bit like suggesting that GDI shouldn't be there on Win32, because previous platforms allowed you to directly manipulate the graphics hardware. Nonsense.

"You're basing your argument on the assumption that there are viable alternatives to ARM when there aren't."

And you're basing your argument on the assumption that Intel will simply cede the mobile market. Whether there are viable alternatives to ARM today is largely irrelevant. And if anyone knows the burden of tying a platform too tightly to the underlying architecture, it's Microsoft (see every attempt to ditch x86).

W3bbo said:

Charles said:

*snip*

"a) there are many programmers today who are comfortable with the .NET model and the supporting tools are rather mature and capable"

 

That's a fine observation, but there are also many more programmers today who are comfortable with the C/C++ model and the supporting tools are even more mature and capable.

 

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

 

That's a weak argument, Windows CE has always been a pre-emptively multitasking OS. user-mode applications cannot crash the device. If a native application dereferences a null pointer it will crash just as well as it would on desktop Windows, but the system will continue running happilly enough. Removing pointer arithmetic doesn't stop programs from crashing.

 

"c) we're trying to make programming apps on WP7 more accessible to lower-skilled developers/hobbyists, rather than focusing primarily on the professional and highly-skilled engineers"

 

For the very golden nuggets you'll find by adopting that policy you'll have to wade through a huge amount of really awful applications with no conceivable utility. I hypotheise that Microsoft has already effectively doomed the Marketplace by not adopting minimum quality standards. I thought Windows Phone 7 was about creating a first-class mobile experience unlike the hodgepodge of Windows Mobile, but by lowering standards like this you're only bringing us back to those awful programs spamming PocketGear et al.

 

I'll also like to remind everyone that Microsoft has never won a D&AD award, yet their competitors have. Go figure.

 

"WP7 will be the best PC phone Microsoft has ever released. We're navigating through uncharted waters as far as we're concerned: WP7 aims to employ simplified experience from the app model to the UI.... In some sense, this is not our typical behavior, so I am happy we're breaking out of our comfortable straightjacket and taking a chance here."

 

Contradiction there. A "PC" lets you do what you want to do with it, free of any first-party control, if you wanted that then you went with Nintendo. WP7 is worse than Apple in this regard, and no-one considers the iPhone a "PC phone". WP7 devices are halfway between Smartphone and Feature Phone.

 

"I am a big fan of native code, as is Microsoft, of course. Not supporting it as a platform tool for building WP7 apps doesn't mean WP7 isn't useful for pro developers... The number of scenarios that are possible to write with .NET (SL/XNA) are many, not few."

 

I never said that .NET had "few" scenarios, just that the more adventurous and innovative "out of the box" applications are only really possible with native code given the state of the entire developer ecosystem right now (e.g.... again, OpenCV).

Pointer arthimetic isn't the only knife... Yes, I understand that the applications will be running in an application environment. Point is, there will be no direct access to the hardware from third party code.

Strictly defining the application/os boundaries, supporting only a very limited hardware configuration,focusing squarely on user experience, providing high level programming abstractions (that are also powerful and enable a plethora of very useful application scenarios for developers and then users of the device).

By PC, I mean Personal Computing. There's a difference between a personal computer and personal computing (a personal computer enables some form of personal computing...). Modern smartphones are hand-held personal computers that enable a specific personal computing experience including web browsing, downloading and running applications and of course telephony, etc...

Yes. C/C++ and supporting tools (IDEs, text editors, compilers, libraries, etc) are very capable and mature. The point is that, by design, the supported WP7 application framework exposes a rich set of very useful programmable features with the extra benefit of an established managed execution model. There's nothing wrong with democratizing application development: enabling broad adoption of the platform, especially among those who already possess a solid working knowledge of the supported design tools and engineering domains. For those who do not, getting up to speed will be easier than getting up to speed with, say, Objective C or C++. Yes, you could argue that supporting both models would just increase the surface area of developers who would target the platform. I can't argue against that notion, given that is in fact correct. Not sure entering that rabbit hole is useful at this point... That said, read the first paragraph of this reply again.

Suffice it to say that WP7 will provide many, many developers around the world with a reliable and capable platform that does not require them to learn how to use new or foreign tools - they already have the right equipment to design and implement their WP7 applications. Again, that statement also applies to the legions of native developers. Not sure what you want to hear. The WP7 platform that ships will be what it is. I'm really looking forward to it. It will be like nothing else we've delivered in this space. Why don't you give it a fair chance before dismissing its potential based on the application development tools it doesn't support?

Promise and deliver. The new Microsoft.

I want my new phone.

C

W3bbo said:

Charles said:

*snip*

Whilst my disappointment about there not being a native API is well-known, I'd like to justify it with the following bullet points. I would appreciate an "officially supported approach" response to the scenarios I propose:

 

• Running native code allows for raw access to the hardware and to invoke and work with pieces of the system directly. I made a post about how a guy I knew wrote software that set up Wi-Fi based iTunes synchronisation. These kinds of utilities are impossible to achieve in a sandboxed environment. Does Microsoft believe we'll (both users and developers) be satisfied with applications that cannot do anything more than "take in information, process it, and present it to the user"?
• The inability to run native binaries means we cannot port over classic games like Doom, Quake, or many other open-source applications already available for other platforms. It also means we cannot use preexisting C++ libraries like OpenCV or GMP. "Compiling C++ to CIL" is not an option because only Verifiable CIL is allowed. Right now the only real C# vision library is AForge, which whilst good, is nothing compared to OpenCV, and things like this mean that we won't see any "cool" Augmented Reality projects for WP7 because the effort involved in porting over OpenCV to C# would be tremendous.
• High-performance applications would be impossible to work with. Painting programs, for example, do lots of pixel work which requires pointer arithmetic in order to not lag, but that's verboten.
• Lack of competition: I feel it's unfair that Microsoft gets to develop their applications using native code (IE, Word/Excel, PIM, etc) but we become second-class citizens. How will this foster a true "partner" spirit between Microsoft and ISVs?

I'll play along with WP7 for the basic app: the usual sort that does the usual "information processing" tasks, but if Microsoft wants to see innovative and eye-catching applications they're going to have to make it possible to run native code.

 

I feel the restriction on non-verifiable code is stupid: CLR programs run in a sandbox anyway and it won't stop programs from magically crashing, yet it makes certain classes of applications extremely difficult, if not impossible, to implement, such as (as I said) painting or image processing applications.

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

I'd be interested in doing a WP7 version of my Japanese dictionary (assuming I have enough time for it, and assuming WP7 has native Japanese input since I can't develop a SIP for it), but it's currently a completely free, open source app under BSD license. I'd want to keep it that way but I can't afford to pay $99 per year so people can download my app for free.

Sven Groot said:

My biggest disappointment isn't the APIs. It's the fact that the marketplace is apparently the only way to get apps into the hands of consumers, and that putting apps on it costs money.

 

I'd be interested in doing a WP7 version of my Japanese dictionary (assuming I have enough time for it, and assuming WP7 has native Japanese input since I can't develop a SIP for it), but it's currently a completely free, open source app under BSD license. I'd want to keep it that way but I can't afford to pay $99 per year so people can download my app for free.

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.

C

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.

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.

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

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.

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.

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

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

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

Jaime Rodriguez said:

Charles said:

*snip*

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

 

 

Awesome.

Thanks for the info, Jaime!

C

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.

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.

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.

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.

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!

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

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.

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.

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.

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

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.

How do you know? We haven't announced what browser will be in the shipping product...... Speculate all you want. I would recommend that you not listen to the blowhard who wrote the InfoWorld article proclaiming WP7 will fail. He's full of sh#!.

Again, you don't know what version of IE will ship in WP7. Don't base your judgement on what you don't know.

Native code will not be supported in WP7 V1. Can we move on? I've sent plenty of emails regarding this fact. The fact is, this is the fact: no native code. Want me to write that again? I'm tired of typing the same thing.

rhm, WP7's architecture and underlying OS is not the same as iOS. Why are you making comparisons bewtween them? What's the point?

Let's wait until the thing ships, you play with it, build some apps and then send us feedback based on real world usage, not theory, not speculation, not hypothesis. OK?

I'd imagine that if lack of support for native code kills adoption by the developer community, well, you'd think we'd react and deliver accordingly. For now. it's clear the direction is managed-only. Let's see what happens in the real world.

C

Charles said:

ZippyV said:

*snip*

How do you know? We haven't announced what browser will be in the shipping product...... Speculate all you want. I would recommend that you not listen to the blowhard who wrote the InfoWorld article proclaiming WP7 will fail. He's full of sh#!.

 

Again, you don't know what version of IE will ship in WP7. Don't base your judgement on what you don't know.

 

Native code will not be supported in WP7 V1. Can we move on? I've sent plenty of emails regarding this fact. The fact is, this is the fact: no native code. Want me to write that again? I'm tired of typing the same thing.

 

rhm, WP7's architecture and underlying OS is not the same as iOS. Why are you making comparisons bewtween them? What's the point?

 

Let's wait until the thing ships, you play with it, build some apps and then send us feedback based on real world usage, not theory, not speculation, not hypothesis. OK?

 

I'd imagine that if lack of support for native code kills adoption by the developer community, well, you'd think we'd react and deliver accordingly. For now. it's clear the direction is managed-only. Let's see what happens in the real world.

 

C

You're interpreting our criticisms as catastrophist doomsayings for the platform. They aren't. We're just saying that Managed-only restricts our creativity and practical abilities, and only harms itself.

"I'd imagine that if lack of support for native code kills adoption by the developer community, well, you'd think we'd react and deliver accordingly."

It hasn't killed it, just weakened it. There are going to be a lot of developers who think "oh, another platform to target? Sure thing, just write some platform-specific UI frontend on top of my existing C++ codebase and... eh, what?, no C++? screw that then". I feel Microsoft is naive to think developers with applications available for other platforms are going to rewrite everything just for them.

It's chicken and egg: iPhone development is successful because the iPhone was successful, the iPhone was successful because of the iPod and iTMS. WP7 doesn't have that, so WP7 development will be successful based on WP7 development.

Ian2 said:

Jaime Rodriguez said:

*snip*

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!

It's great that he's posting here, but it's too bad he answered a question I didn't ask, and didn't answer the question I actually asked. I guess I won't find out the answer until WP7 is in stores.

Charles said:

ZippyV said:

*snip*

How do you know? We haven't announced what browser will be in the shipping product...... Speculate all you want. I would recommend that you not listen to the blowhard who wrote the InfoWorld article proclaiming WP7 will fail. He's full of sh#!.

 

Again, you don't know what version of IE will ship in WP7. Don't base your judgement on what you don't know.

 

Native code will not be supported in WP7 V1. Can we move on? I've sent plenty of emails regarding this fact. The fact is, this is the fact: no native code. Want me to write that again? I'm tired of typing the same thing.

 

rhm, WP7's architecture and underlying OS is not the same as iOS. Why are you making comparisons bewtween them? What's the point?

 

Let's wait until the thing ships, you play with it, build some apps and then send us feedback based on real world usage, not theory, not speculation, not hypothesis. OK?

 

I'd imagine that if lack of support for native code kills adoption by the developer community, well, you'd think we'd react and deliver accordingly. For now. it's clear the direction is managed-only. Let's see what happens in the real world.

 

C

Charles, it is easy to infer from your post that the browser that ships in Windows Mobile 7 will be Internet Explorer. If you had not said that "you don't know what version of IE will ship in WP7", then Chrome or Firefox could have been possible too, but that comment narrows it to Internet Explorer.

Charles said:

ZippyV said:

*snip*

How do you know? We haven't announced what browser will be in the shipping product...... Speculate all you want. I would recommend that you not listen to the blowhard who wrote the InfoWorld article proclaiming WP7 will fail. He's full of sh#!.

 

Again, you don't know what version of IE will ship in WP7. Don't base your judgement on what you don't know.

 

Native code will not be supported in WP7 V1. Can we move on? I've sent plenty of emails regarding this fact. The fact is, this is the fact: no native code. Want me to write that again? I'm tired of typing the same thing.

 

rhm, WP7's architecture and underlying OS is not the same as iOS. Why are you making comparisons bewtween them? What's the point?

 

Let's wait until the thing ships, you play with it, build some apps and then send us feedback based on real world usage, not theory, not speculation, not hypothesis. OK?

 

I'd imagine that if lack of support for native code kills adoption by the developer community, well, you'd think we'd react and deliver accordingly. For now. it's clear the direction is managed-only. Let's see what happens in the real world.

 

C

This is what we're basing our judgement on:

"The mobile version, yet to be named, is a version between Internet Explorer 7 and 8 according to Microsoft corporate vice president Joe Belfiore. Speaking at MIX 2010 today Belfiore explained that the mobile browser takes HTML rendering code from Internet Explorer 7 which is optimized for low memory situations. Belfiore explained that some features have been back ported from Internet Explorer 8 and joked Microsoft could end up naming it Internet Explorer 7.5.

At present the browser within Windows Phone 7 identifies itself with the following user agent string: Mozilla/4.0 (compatible; MSIE 7.0; Windows Phone OS 7.0; Trident/3.1; IEMobile/7.0). Microsoft's Zune HD device on the other hand runs on IE6: Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile 6.12; Microsoft ZuneHD 4.3). 

"

-- http://www.neowin.net/news/windows-phone-7-browser-is-based-on-internet-explorer-7

Sven Groot said:

Ian2 said:

*snip*

It's great that he's posting here, but it's too bad he answered a question I didn't ask, and didn't answer the question I actually asked. I guess I won't find out the answer until WP7 is in stores.

Sven, sorry that I missed your question. I just re-read the post and I still don't see a question. All I see is a description on preference, with a strong "requirement" the language be japanese..  Since Japanese is not in the first batch of languages, I started there.

Can you please expand the question? 

Interim, this information might help:

The phone does have the ability to customize region & language.  You get a

1) Display language  (with option to select right formats of course, and choice here is EFIGS)

2) System locale (  this is standard system locales, including japanese ) ...

Cheers,

Jaime

jaimer said:

Sven Groot said:

*snip*

Sven, sorry that I missed your question. I just re-read the post and I still don't see a question. All I see is a description on preference, with a strong "requirement" the language be japanese..  Since Japanese is not in the first batch of languages, I started there.

Can you please expand the question? 

Interim, this information might help:

The phone does have the ability to customize region & language.  You get a

1) Display language  (with option to select right formats of course, and choice here is EFIGS)

2) System locale (  this is standard system locales, including japanese ) ...

 

Cheers,

Jaime

The question is twofold:

1. Can you switch display language on WP7 regardless where you bought it? From your previous post it seems the answer is yes.

2. Will you be able to use an input language that doesn't match the currently selected display language?

As an example: if English is my display language, can I type in French (with special characters and the relevant autocorrect dictionary) without changing the display language? Can I easily switch between typing in English and French while I'm writing?

DCMonkey said:

Charles said:

*snip*

This is what we're basing our judgement on:

 

"The mobile version, yet to be named, is a version between Internet Explorer 7 and 8 according to Microsoft corporate vice president Joe Belfiore. Speaking at MIX 2010 today Belfiore explained that the mobile browser takes HTML rendering code from Internet Explorer 7 which is optimized for low memory situations. Belfiore explained that some features have been back ported from Internet Explorer 8 and joked Microsoft could end up naming it Internet Explorer 7.5.

At present the browser within Windows Phone 7 identifies itself with the following user agent string: Mozilla/4.0 (compatible; MSIE 7.0; Windows Phone OS 7.0; Trident/3.1; IEMobile/7.0). Microsoft's Zune HD device on the other hand runs on IE6: Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile 6.12; Microsoft ZuneHD 4.3). 

"

-- http://www.neowin.net/news/windows-phone-7-browser-is-based-on-internet-explorer-7

Even if it's gonna be IE8, that's not good enough. And since IE9 is apparently not out until next year it's not gonna be IE9 either.

Frankly though, I kind of care less about the lack of native code or a decent browser and more about the fact that the managed API doesn't allow direct camera access. AFAIK, you can get realtime location and microphone data... so why no imagery?

Shining Arcanine said:

Charles said:

*snip*

Charles, it is easy to infer from your post that the browser that ships in Windows Mobile 7 will be Internet Explorer. If you had not said that "you don't know what version of IE will ship in WP7", then Chrome or Firefox could have been possible too, but that comment narrows it to Internet Explorer.

It's obvious. The point was, of course, to say that one does not know what the feature set will be of the shipping browser because, regardless of label, it's not out yet. It's like saying Internet Explorer doesn't support AJAX - which is true, if you live in 1995, but not anymore; in fact, Internet Explorer was the browser which introduced it.

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.

It looks to me like Microsoft believes that, at some point in time in the future, managed code execution performance will reach full parity with native code execution performance. The fabled Phoenix compiler infrastructure will compile both C/C++ and IL. Let's see how far it can push the limits of managed code execution performance, be it on current MSIL or some derivative thereof. It's a leap of faith perhaps...

Bas said:

DCMonkey said:

*snip*

Even if it's gonna be IE8, that's not good enough. And since IE9 is apparently not out until next year it's not gonna be IE9 either.

 

Frankly though, I kind of care less about the lack of native code or a decent browser and more about the fact that the managed API doesn't allow direct camera access. AFAIK, you can get realtime location and microphone data... so why no imagery?

Like this?: http://msdn.microsoft.com/en-us/library/microsoft.phone.tasks.cameracapturetask(v=VS.92).aspx"> http://msdn.microsoft.com/en-us/library/microsoft.phone.tasks.cameracapturetask(v=VS.92).aspx

Or were you looking for something more?

DCMonkey said:

Bas said:

*snip*

Like this?: http://msdn.microsoft.com/en-us/library/microsoft.phone.tasks.cameracapturetask(v=VS.92).aspx"> http://msdn.microsoft.com/en-us/library/microsoft.phone.tasks.cameracapturetask(v=VS.92).aspx

 

Or were you looking for something more?

That does this:

"Allows an application to launch the Camera application. Use this to allow users to take a photo from your application."

Bas (and myself) would like to do this:

"Instantiates a Camera instance which allows for the capture of still and moving images, in addition to access to a raw stream of live camera data"

...which is not currently possible.

W3bbo said:

DCMonkey said:

*snip*

That does this:

 

"Allows an application to launch the Camera application. Use this to allow users to take a photo from your application."

 

Bas (and myself) would like to do this:

 

"Instantiates a Camera instance which allows for the capture of still and moving images, in addition to access to a raw stream of live camera data"

 

...which is not currently possible.

Seriously... what do you expect from a v1.0 product?

I think WP7 will take a similar accelerated evolution as Android, but instead of iterating through both hardware & software, WP7 will do more through software. It will come. It might take a year, but they have to deliver to compete.

Minh said:

W3bbo said:

*snip*

Seriously... what do you expect from a v1.0 product?

 

I think WP7 will take a similar accelerated evolution as Android, but instead of iterating through both hardware & software, WP7 will do more through software. It will come. It might take a year, but they have to deliver to compete.

As I've said before, the "it's a v1 product" defense doesn't really wash when you're trying to sell it to consumers as well. Hey, want to buy into an extended public beta test? Sure.

And anyway, how would providing the access W3bbo describes take more effort than what Microsoft have provided with the camera capture 'task'? This is an example of a 'nanny-state' API rather than a 'we didn't have time to implement it' API.

exoteric said:

W3bbo said:

*snip*

It looks to me like Microsoft believes that, at some point in time in the future, managed code execution performance will reach full parity with native code execution performance. The fabled Phoenix compiler infrastructure will compile both C/C++ and IL. Let's see how far it can push the limits of managed code execution performance, be it on current MSIL or some derivative thereof. It's a leap of faith perhaps...

Managed code is pretty fast already. Someone asked earlier if Microsoft couldn't add a managed library that made use of the vector processing unit and of course they could. But they've never added a SIMD math library to the main .NET framework (although the Mono project have Mono.SIMD in theirs), so either they don't see .NET as useful for numerically intensive work, or they expect people to pInvoke C code for that kind of stuff. Of course on the phone you can't pInvoke.

rhm said:

exoteric said:

*snip*

Managed code is pretty fast already. Someone asked earlier if Microsoft couldn't add a managed library that made use of the vector processing unit and of course they could. But they've never added a SIMD math library to the main .NET framework (although the Mono project have Mono.SIMD in theirs), so either they don't see .NET as useful for numerically intensive work, or they expect people to pInvoke C code for that kind of stuff. Of course on the phone you can't pInvoke.

Managed code is fast, in terms of throughput, sure. But I haven't been impressed so far with its real-time and low-latency performance, in-part due to JIT and of course the slow application initialisation times. What's with that anyway?

rhm said:

Minh said:

*snip*

As I've said before, the "it's a v1 product" defense doesn't really wash when you're trying to sell it to consumers as well. Hey, want to buy into an extended public beta test? Sure.

 

And anyway, how would providing the access W3bbo describes take more effort than what Microsoft have provided with the camera capture 'task'? This is an example of a 'nanny-state' API rather than a 'we didn't have time to implement it' API.

Ultimately, MS will only be successful if people buys their V2 phones. I think WP7 is charting the path of the Xbox. Losing big $$$ on the V1 product and kick a$$ in the V2. And I think MS is betting big time on integrating the phones to the cloud. Which none of the big players have (for free) yet.

And I do think MS have a time issue. I remember hearing that they had to reboot the WP7 (was Windows Mobile 7) project. Right now, the Samsung Galaxy S is look really sweet to me... but I'm having trouble pulling the trigger now that WP7 is coming out in late Oct.

Sven Groot said:

jaimer said:

*snip*

The question is twofold:

1. Can you switch display language on WP7 regardless where you bought it? From your previous post it seems the answer is yes.

2. Will you be able to use an input language that doesn't match the currently selected display language?

 

As an example: if English is my display language, can I type in French (with special characters and the relevant autocorrect dictionary) without changing the display language? Can I easily switch between typing in English and French while I'm writing?

So, any chance of getting an answer to my second question?

Minh said:

rhm said:

*snip*

Ultimately, MS will only be successful if people buys their V2 phones. I think WP7 is charting the path of the Xbox. Losing big $$$ on the V1 product and kick a$$ in the V2. And I think MS is betting big time on integrating the phones to the cloud. Which none of the big players have (for free) yet.

 

And I do think MS have a time issue. I remember hearing that they had to reboot the WP7 (was Windows Mobile 7) project. Right now, the Samsung Galaxy S is look really sweet to me... but I'm having trouble pulling the trigger now that WP7 is coming out in late Oct.

They have a good over-the-air update story though.  It's not like what you buy at launch is what you're stuck with.  They can easily add to their app platform in the months after launch.  So V1 phones will become V2 phones. 

Sven Groot said:

Sven Groot said:

*snip*

So, any chance of getting an answer to my second question?

Chances are good.

C

Charles said:

Sven Groot said:

*snip*

Chances are good.

C

Sven,

The SIP has a button for language, and you can toggle across. If I am displaying say french, the default layout is french and the autocorrect is for french... I then click one key to toggle to English and now I can toggle to english.. Again, at this point I can toggle across EFIGS, but when we add Japanese, it will behave same way..

The language does have to be installed/enabled; not sure if there is a better process for doing it, but in my phone what I do is enable the language once and from there on it is available as a choice..

my phone has a hardware keyboard too, and I don't see a language button there, but I am guessing there is a way to do it. If I switch language on SIP and then open keyboard this is persisted so at minimum I can toggle through SIP and type away; again this is likely me.

hth.

Jaime

PS -- to any one who is not getting answers, feel free to post question here, poke me at http://blogs.msdn.com/jaimer  with a pointer to questio. we are being trying to be as transparent as we can, but I might  be missing questions or in some cases we are reading it and trying to learn from it, so we are not altering the conversation much. It is great to see your perception and experiences. Thanks for sharing!!

Shining Arcanine said:

Charles said:

*snip*

Charles, it is easy to infer from your post that the browser that ships in Windows Mobile 7 will be Internet Explorer. If you had not said that "you don't know what version of IE will ship in WP7", then Chrome or Firefox could have been possible too, but that comment narrows it to Internet Explorer.

On Browser,

Yes, the browser in the phone is IE.  It starts with an IE7 foundation, has fixes and improvements, and it became an IE 7.5 or equivalent .

Microsoft is very committed to web standards -- yes, we slept at the wheel for a few years in 2006 or 2007 but we woke up a couple years ago and we are now running as fast as we can to HTML5 with IE9 -. 

After making IE9 available in the desktop, the browser will make it onto the phone .. but I can't disclose the timeline on how soon after we release because we don't yet know it, rest assured we do want to have HTML5 in the phone and will do our best to get it in as soon as we can;   we will have to see how schedules align next year.

With regards to V1 comments.

I  think perception here might be stronger than reality.   I recall the iPhone 1.0 days and we are further ahead from there.  At same time, I do know new phones have features we have chosen not to enable due to security, user experience, or other concerns.  We will have to open these as soon as we can by listening to you (our developers) and our shared user base.  
I don't call the phone a 1.0, but at same time I acknowledge that we don't have all the features that other phones have; in all cases we have more or better features and less (or not so powerful) features.   I am however confident this will change over time;  Silverlight and XNA is a strong foundation, and underneath we have a very powerful, secured and performant OS.  We have a solid foundation to iterate on quickly.  I am super excited about this. Reminds me of Silverlight where 3 years ago I was bummed hating codign to SL 1.0 using Javascript and now 3 years later I am thinking it rocks over its competitors (e.g. Flash)..    We are not as far behind as Silverlight was, so it should not take us 3 years; we will be able to delight users this year, and will be able to take marketshare year over year; this is a big opportunity, and developers who get in early have a chance to cash in..  {unlike other already saturated markets}

Cheers!

Jaime Rodriguez 

[PS-- the above is my personal view, not that of my employer]

jaimer said:

Shining Arcanine said:

*snip*

On Browser,

Yes, the browser in the phone is IE.  It starts with an IE7 foundation, has fixes and improvements, and it became an IE 7.5 or equivalent .

Microsoft is very committed to web standards -- yes, we slept at the wheel for a few years in 2006 or 2007 but we woke up a couple years ago and we are now running as fast as we can to HTML5 with IE9 -. 

After making IE9 available in the desktop, the browser will make it onto the phone .. but I can't disclose the timeline on how soon after we release because we don't yet know it, rest assured we do want to have HTML5 in the phone and will do our best to get it in as soon as we can;   we will have to see how schedules align next year.

 

With regards to V1 comments.

I  think perception here might be stronger than reality.   I recall the iPhone 1.0 days and we are further ahead from there.  At same time, I do know new phones have features we have chosen not to enable due to security, user experience, or other concerns.  We will have to open these as soon as we can by listening to you (our developers) and our shared user base.  
I don't call the phone a 1.0, but at same time I acknowledge that we don't have all the features that other phones have; in all cases we have more or better features and less (or not so powerful) features.   I am however confident this will change over time;  Silverlight and XNA is a strong foundation, and underneath we have a very powerful, secured and performant OS.  We have a solid foundation to iterate on quickly.  I am super excited about this. Reminds me of Silverlight where 3 years ago I was bummed hating codign to SL 1.0 using Javascript and now 3 years later I am thinking it rocks over its competitors (e.g. Flash)..    We are not as far behind as Silverlight was, so it should not take us 3 years; we will be able to delight users this year, and will be able to take marketshare year over year; this is a big opportunity, and developers who get in early have a chance to cash in..  {unlike other already saturated markets}

Cheers!

Jaime Rodriguez 

[PS-- the above is my personal view, not that of my employer]

I in a blog post that IE is tooled so that it can be updated OTA without requiring a full ROM update. Is this true, and if so, are there any other components that can do this?

kettch said:

jaimer said:

*snip*

I in a blog post that IE is tooled so that it can be updated OTA without requiring a full ROM update. Is this true, and if so, are there any other components that can do this?

Whups. Nevermind

jaimer said:

Charles said:

*snip*

Sven,

The SIP has a button for language, and you can toggle across. If I am displaying say french, the default layout is french and the autocorrect is for french... I then click one key to toggle to English and now I can toggle to english.. Again, at this point I can toggle across EFIGS, but when we add Japanese, it will behave same way..

The language does have to be installed/enabled; not sure if there is a better process for doing it, but in my phone what I do is enable the language once and from there on it is available as a choice..

my phone has a hardware keyboard too, and I don't see a language button there, but I am guessing there is a way to do it. If I switch language on SIP and then open keyboard this is persisted so at minimum I can toggle through SIP and type away; again this is likely me.

 

hth.

Jaime

 

PS -- to any one who is not getting answers, feel free to post question here, poke me at http://blogs.msdn.com/jaimer  with a pointer to questio. we are being trying to be as transparent as we can, but I might  be missing questions or in some cases we are reading it and trying to learn from it, so we are not altering the conversation much. It is great to see your perception and experiences. Thanks for sharing!!

 

 

The SIP has a button for language, and you can toggle across. If I am displaying say french, the default layout is french and the autocorrect is for french... I then click one key to toggle to English and now I can toggle to english.. Again, at this point I can toggle across EFIGS, but when we add Japanese, it will behave same way.

Thanks, that's what I wanted to know. None of the screenshots I've seen have shown this button and there's no obvious space for it, so I was afraid there wasn't going to be an option to switch keyboards.

This is important if I ever wish to port my Japanese dictionary over. People who use Japanese dictionaries tend not to be fluent in Japanese so if using the Japanese UI was a requirement for typing in Japanese (once that support gets added) it wouldn't have been an option.

It's also important if you ever want me to buy a WP7 device, since I depend on having English, Dutch and Japanese input available.

For the time being though, I won't be able to port it because I do need some way to type in Japanese. Under Windows Mobile this problem was solved with a custom SIP (because the official Japanese SIP is only available on Japanese devices), but I don't think that'll be possible on WP7.

This leaves me with two options: include the input method in the Japanese dictionary, or just wait until built-in support for Japanese input in WP7 becomes available.

Thanks again.

jaimer said:

Shining Arcanine said:

*snip*

On Browser,

Yes, the browser in the phone is IE.  It starts with an IE7 foundation, has fixes and improvements, and it became an IE 7.5 or equivalent .

Microsoft is very committed to web standards -- yes, we slept at the wheel for a few years in 2006 or 2007 but we woke up a couple years ago and we are now running as fast as we can to HTML5 with IE9 -. 

After making IE9 available in the desktop, the browser will make it onto the phone .. but I can't disclose the timeline on how soon after we release because we don't yet know it, rest assured we do want to have HTML5 in the phone and will do our best to get it in as soon as we can;   we will have to see how schedules align next year.

 

With regards to V1 comments.

I  think perception here might be stronger than reality.   I recall the iPhone 1.0 days and we are further ahead from there.  At same time, I do know new phones have features we have chosen not to enable due to security, user experience, or other concerns.  We will have to open these as soon as we can by listening to you (our developers) and our shared user base.  
I don't call the phone a 1.0, but at same time I acknowledge that we don't have all the features that other phones have; in all cases we have more or better features and less (or not so powerful) features.   I am however confident this will change over time;  Silverlight and XNA is a strong foundation, and underneath we have a very powerful, secured and performant OS.  We have a solid foundation to iterate on quickly.  I am super excited about this. Reminds me of Silverlight where 3 years ago I was bummed hating codign to SL 1.0 using Javascript and now 3 years later I am thinking it rocks over its competitors (e.g. Flash)..    We are not as far behind as Silverlight was, so it should not take us 3 years; we will be able to delight users this year, and will be able to take marketshare year over year; this is a big opportunity, and developers who get in early have a chance to cash in..  {unlike other already saturated markets}

Cheers!

Jaime Rodriguez 

[PS-- the above is my personal view, not that of my employer]

I recall the iPhone 1.0 days and we are further ahead from there.

I don't want to constantly sound negative about this but the fact alone that this needs to be pointed out worries me. The iPhone 1.0 came out years ago, I would expect nothing less than WP7 being better than a phone that is several years old. You might as well say "WP7 is a v1 phone, and already it's better than Alexander Graham Bell's V1 prototype was at the time."

The iPhone 1.0 is history, and with good reason. What matters are the phones that are out now. WP7 needs to be as good or better as the iPhone 4, because that's what it'll be competing with. The fact that it's a 1.0 phone is no excuse: it doesn't mean it's coming out years ago; it's coming out now and needs to compete with current phones.

I mean.. if the best thing to say about the phone's ability to compete with other phones is "Our v1 is better than their ancient v1 phone", then how does that not worry anyone on the WP7 team?

The ability to change over time is great for technology-minded people but meaningless to consumers. When they buy a phone, they buy it on the basis of what it can do when they get it in their hands, not on the basis of what it may possibly be able to do at some undefined time in the future.

jaimer said:

Shining Arcanine said:

*snip*

On Browser,

Yes, the browser in the phone is IE.  It starts with an IE7 foundation, has fixes and improvements, and it became an IE 7.5 or equivalent .

Microsoft is very committed to web standards -- yes, we slept at the wheel for a few years in 2006 or 2007 but we woke up a couple years ago and we are now running as fast as we can to HTML5 with IE9 -. 

After making IE9 available in the desktop, the browser will make it onto the phone .. but I can't disclose the timeline on how soon after we release because we don't yet know it, rest assured we do want to have HTML5 in the phone and will do our best to get it in as soon as we can;   we will have to see how schedules align next year.

 

With regards to V1 comments.

I  think perception here might be stronger than reality.   I recall the iPhone 1.0 days and we are further ahead from there.  At same time, I do know new phones have features we have chosen not to enable due to security, user experience, or other concerns.  We will have to open these as soon as we can by listening to you (our developers) and our shared user base.  
I don't call the phone a 1.0, but at same time I acknowledge that we don't have all the features that other phones have; in all cases we have more or better features and less (or not so powerful) features.   I am however confident this will change over time;  Silverlight and XNA is a strong foundation, and underneath we have a very powerful, secured and performant OS.  We have a solid foundation to iterate on quickly.  I am super excited about this. Reminds me of Silverlight where 3 years ago I was bummed hating codign to SL 1.0 using Javascript and now 3 years later I am thinking it rocks over its competitors (e.g. Flash)..    We are not as far behind as Silverlight was, so it should not take us 3 years; we will be able to delight users this year, and will be able to take marketshare year over year; this is a big opportunity, and developers who get in early have a chance to cash in..  {unlike other already saturated markets}

Cheers!

Jaime Rodriguez 

[PS-- the above is my personal view, not that of my employer]

Silverlight does rock over it's competitors in many ways: control and data templating, layout controls, and of course the biggest thing of all - being able to program in .NET languages. But there things that still need to be improved including typography, and one thing where Silverlight is behind Flash: support for 3d.

Flash's support for 3d only currently extends to a lame retained-mode API (like WPF's), but still, developers have been able to do some interesting stuff with it. In the next release they will add WebGL support, giving a proper immediate-mode 3d API equivalent to OpenGL. Flash 3d apps won't be as performant as native apps, but if history is any gauge, Flash developers will get a lot more out of that little browser plugin that people are expecting.

All Silverlight has is the minimum support necessary for doing 'coverflow' style animations. Silverlight desperately needs to be merged with the XNA framework, or at least the graphics portion of it. XNA developers on the XBox need a way to do GUIs that's better than cooking their own up from low-level primatives, and having the two APIs split on the phone is really going to hurt for certain classes of app: AR, anything involving panorama rendering like Streetview, app that do data visualisation and games that require substantial UI componentry all have a difficult choice to make.

Is this split between Silverlight and XNA because they come from different teams (maybe even different divisions)? Or because Silverlight uses so much of the machine's resources you can't maintain both at the same time on a handheld? I know you won't be able to say anything about future plans, but has merging them even been discussed?

jaimer said:

Charles said:

*snip*

Sven,

The SIP has a button for language, and you can toggle across. If I am displaying say french, the default layout is french and the autocorrect is for french... I then click one key to toggle to English and now I can toggle to english.. Again, at this point I can toggle across EFIGS, but when we add Japanese, it will behave same way..

The language does have to be installed/enabled; not sure if there is a better process for doing it, but in my phone what I do is enable the language once and from there on it is available as a choice..

my phone has a hardware keyboard too, and I don't see a language button there, but I am guessing there is a way to do it. If I switch language on SIP and then open keyboard this is persisted so at minimum I can toggle through SIP and type away; again this is likely me.

 

hth.

Jaime

 

PS -- to any one who is not getting answers, feel free to post question here, poke me at http://blogs.msdn.com/jaimer  with a pointer to questio. we are being trying to be as transparent as we can, but I might  be missing questions or in some cases we are reading it and trying to learn from it, so we are not altering the conversation much. It is great to see your perception and experiences. Thanks for sharing!!

 

 

AFAIK, you can acquire apps only through the marketplace, unless if you're a company.

Can you talk about the experience for hobbyists and researchers? How do we go about distributing apps to our peers without having to use the marketplace (especially when our apps are not meant for a marketplace)?

My school offers a course called "Designing Usable Interfaces" in which they use Android as the platform choice for assignments. The final project is to work in teams to build a complete interface. The teams must submit the apps to be listed on the course website to be shared with everyone else. These apps are by no means production quality and are not suitable for public downloading (there'd be no point). What do you have in place to support this scenario?

MasterPie said:

jaimer said:

*snip*

AFAIK, you can acquire apps only through the marketplace, unless if you're a company.

Can you talk about the experience for hobbyists and researchers? How do we go about distributing apps to our peers without having to use the marketplace (especially when our apps are not meant for a marketplace)?

 

My school offers a course called "Designing Usable Interfaces" in which they use Android as the platform choice for assignments. The final project is to work in teams to build a complete interface. The teams must submit the apps to be listed on the course website to be shared with everyone else. These apps are by no means production quality and are not suitable for public downloading (there'd be no point). What do you have in place to support this scenario?

I read that the Marketplace will have a public and private section for your apps.  The private section will allow you to control who gets to see your app.  Your school could create an account with a private section and only make it accessable to the students.

(Someone please correct me if I am wrong)

JeremyJ said:

MasterPie said:

*snip*

I read that the Marketplace will have a public and private section for your apps.  The private section will allow you to control who gets to see your app.  Your school could create an account with a private section and only make it accessable to the students.

(Someone please correct me if I am wrong)

Ah, neat. One step further, it would be nice if you could link to the marketplace app...sort of treat marketplace as a host.

Then, it wouldn't make so much of a difference having to acquire the app through the marketplace vs through your own medium.

from this article: http://wmpoweruser.com/more-details-on-apps-the-wp7-marketplace/

A little light on the details but at least it is something.

I have a customer who currently distributes an application with a proprietary reference library to their people in the field. The size of the data is over 500MB. They don't always have access to a decent connection. It would be really nice if the marketplace could create an ISO that would allow the application to be loaded onto a connected device. It would still have the right approval, signing, be registered with the marketplace, and be subject to all of the standard rules. Having the deep linking is cool, but what if that link is leaked somehow? Why should they have to download a marketplace client? How do I simplify this for the end user?

Thanks,

Mierk

Jul 20, 2010 at 6:01 AM, jaimer wrote

After making IE9 available in the desktop, the browser will make it onto the phone .. but I can't disclose the timeline on how soon after we release because we don't yet know it, rest assured we do want to have HTML5 in the phone and will do our best to get it in as soon as we can;   we will have to see how schedules align next year.

I think you not only need to invest in the browser, but you probably need to rethink how IE development is managed between desktop and mobile. It doesn't make sense anymore for the IE team to be part of the desktop Windows division, develop for Windows, and only later port to mobile (how I understand it to work currently, correct me if I'm wrong). Mobile should be a priority from the beginning. If anything mobile IE is a lot more important than desktop IE as there are plenty of other browsers on desktop Windows, while Windows Phone, being a minority platform, benefits more from access to a rich standards-based application base to protect against everyone getting locked in to iPhone or Android-exclusive apps.