Related
Applications that were made for Windows Mobile 6 are compatible with Windows Phone 7 Series. The interface of the new mobile operating system has been changed though, so the user interface for these applications will have to be changed as well.
"So there is no reason why programs written for Windows Mobile 6 cannot run on the new version of the OS", said Maarten Sonneveld of Microsoft Netherlands to Tweakers.net. "The interface is complete different though, so the applications will have to be changed somewhat before being ready for Windows Phone 7 Series".
It is still unclear how developers can port their user interfaces to the new version of Windows Mobile. Microsoft will only disclose how applications can be developed and distributed at their developer event Mix2010.
Microsoft announced it’s new OS on Monday afternoon at the Mobile World Congress in Barcelona. The OS is primarily aimed at synchronisation and integration with Microsft-services like Windows Live, Bing, Zune and Xbox Live. Aside from those Windows Phone 7 Series can also synchronise with Google-accounts and facebook.
Click to expand...
Click to collapse
Source
So in summary, while none of the current applications will run on it, the underlying non-UI APIs will be compatible. So if understand correctly, porting would just a case of redeveloping the UI then recompiling, rather than starting completely from scratch. This acts to filter out apps with no more developer support, and promote a consistent UI.
Doesn't sound too bad to me.
That might explain why TomTom was seen on that screenshot of WP7 running on the HD2 (although, it could be a fake!). TomTom takes control of the screen, so uses no WM interface elements. So, it might be able to run full-screen apps/games without changes.
But, who knows...
elyl said:
That might explain why TomTom was seen on that screenshot of WP7 running on the HD2 (although, it could be a fake!). TomTom takes control of the screen, so uses no WM interface elements. So, it might be able to run full-screen apps/games without changes.
But, who knows...
Click to expand...
Click to collapse
I was just thinking the same except if you use the included .net controls, there's no reason that the OS couldn't just reskin them automatically to be at least somewhat more in line with the WP7 styling.
This would be excellent if it's true - and I can't see why it wouldn't be. The UI may be new but why throw away a perfectly good underlying core.
What would also be ideal is if the "multi-tasking" involved an app being set to pause in the background by default, but with a "keep me running" API call available for apps that needed it. I'm sure most apps hog resourses not because they need to but because the developer hasn't really thought about how the rest of the device performs when his app has been left running.
Makes sense, WindowsCE core is still the same
Zaim2 said:
Applications that were made for Windows Mobile 6 are compatible with Windows Phone 7 Series
Click to expand...
Click to collapse
Absolutely wrong statement due to incorrect translation. Original: "De interface van Windows Phone 7 Series is totaal anders, waardoor er in elk geval iets aan de applicaties moet gebeuren voordat ze geschikt zijn voor Windows Phone 7 Series"
Even google translates it correctly:
"The interface of Windows 7 Phone Series is different, which in any case something should happen to the applications before they are suitable for Windows 7 Phone Series".
We have some "ms confidential" documentation dated January 2010 that proves that none of the existing apps would be compatible with WinPhone7. And the only programming suite that is available to "generic" application-writers is Silverlight+XNA. Native apps are prohibited. Only OEMs and MO are allowed to create them (and even they have a set of limitations).
We would not have even source code compatibility - as all our C++ apps have to be converted to .NET.
mamaich said:
We have some "ms confidential" documentation dated January 2010...
Click to expand...
Click to collapse
What the heck? And you say that only now? What else is in there? Any word about how background tasks are handled? Please give us some more information, or maybe, can you upload that documentation?
freyberry said:
maybe, can you upload that documentation?
Click to expand...
Click to collapse
Obviously I cannot. As it would reveal the person who provided it.
Just to prove that such info really exists - see attached screenshots.
I really hope that the community would force MS to change such a dumb idea to limit independent software vendors to create only managed apps. Prohibiting C++ as a developing language, and "hiding" Windows API from programmer would force lots of developers to abandon this platform. The main reason of success of old WinMobile OSes was the ability to recompile "desktop" apps to WinMobile with just a minor set of changes (ANSI->Unicode + some interface changes).
P.S. I don't read PMs.
Obviously I cannot. As it would reveal the person who provided it.
Just to prove that such info really exists - see attached screenshots.
Click to expand...
Click to collapse
Well, there's certainly a way to remove that information. But anyway, what about background tasks? Are third party applications allowed to run in the background?
mamaich said:
Obviously I cannot. As it would reveal the person who provided it.
Just to prove that such info really exists - see attached screenshots.
I really hope that the community would force MS to change such a dumb idea to limit independent software vendors to create only managed apps. Prohibiting C++ as a developing language, and "hiding" Windows API from programmer would force lots of developers to abandon this platform. The main reason of success of old WinMobile OSes was the ability to recompile "desktop" apps to WinMobile with just a minor set of changes (ANSI->Unicode + some interface changes).
P.S. I don't read PMs.
Click to expand...
Click to collapse
Wow, I can't believe noone has picked up on this
freyberry said:
Are third party applications allowed to run in the background?
Click to expand...
Click to collapse
OS itself supports multitasking, see attach. But "Windows Phone OS 7.0 Application Platform" that we'll be forced to use to create apps may force our application to be paused in background. I never programmed Silverlight and XNA and can't tell how multitatsking is made in them.
WinPhone 7 == Zune Phone. Both are based on CE kernel, and they should have lots of common in implementation of multitasking, clipboard, etc.
OS itself supports multitasking, see attach. But "Windows Phone OS 7.0 Application Platform" that we'll be forced to use to create apps may force our application to be paused in background.
Click to expand...
Click to collapse
The question is, can we write applications that are not automatically suspended when sent to the background? What are the policies on this?
It says multiple processes can run at the same time, but it does not say whether they get suspended automatically.
Is there any info on this? Maybe in the "Scheduling" section?
I’m not sure this is a big deal. I can see them saying a lot of native C++ apps may have compatibility issues. I could go either way on it with the limited amount of information I have on this. I’ll have a better opinion at and after MIX
Note that this could be old documentation, and it’s pretty annoying you're leaking confidential documentation. Personally, I hope you get into trouble for breaking your contract - they trust you and you're posting it? Yuck.
To be fair, though, every app we’ve written has been managed, and Microsoft hasn't t said P/Invoking is verboten, so what would be the problem?
There’s probably exceptions for games and the like, and the documents you've scanned even say a waiver is available to use the Native APIs. So I don’t know what you're complaining about…
Microsoft's dev teams have been listening to developers - why not get them to chime in and also give them a chance to hear you. Posting confidential Microsoft documents, assuming those are real, is not the way to get them to listen
Best,
-Auri
freyberry said:
The question is, can we write applications that are not automatically suspended when sent to the background? What are the policies on this?
It says multiple processes can run at the same time, but it does not say whether they get suspended automatically.
Is there any info on this? Maybe in the "Scheduling" section?
Click to expand...
Click to collapse
Personally, I like Android's approach to this, where Services can run in the background, but UI apps are allowed to be "put to sleep" while other apps run. But then again, we may see a lot of that come into play come MIX and "Answer Time"
Best,
-Auri
Well, I am now both excited and nervous -I think I will just cool my jets until MIX10 and just enjoy the eye candy for now. At worst - if the interface is nice, but the core is crap I am sure some of the boys here at xda will make us an inteface port for 6.5.x that acts and looks like the new hotness with the old compatibility. - lets see MIX
AuriRahimzadeh said:
Note that this could be old documentation, and it’s pretty annoying you're leaking confidential documentation.
Click to expand...
Click to collapse
Docs are dated 2010.
I'm not leaking the documentation. I'm sharing the information that anyway would be opened in some days, maybe weeks.
And screens are posted here just as a confirmation of my words. You may think that these pics come from my mind and are made with photoshop - it is your opinion.
I really think that WinPhone 7 would be a failure similar to desktop Vista. Of cause some people would like it, but most would stay on WM 6.x and wait for the next version.
Regarding P/Invoke. As far as I've seen, "unsafe" operations are prohibited in XNA and Silverlight. Otherwise we would be able to call coredll funcs and run native apps (and do everything else that is allowed in our chamber).
mamaich said:
Docs are dated 2010.
I'm not leaking the documentation. I'm sharing the information that anyway would be opened in some days, maybe weeks.
And screens are posted here just as a confirmation of my words. You may think that these pics come from my mind and are made with photoshop - it is your opinion.
I really think that WinPhone 7 would be a failure similar to desktop Vista. Of cause some people would like it, but most would stay on WM 6.x and wait for the next version.
Regarding P/Invoke. As far as I've seen, "unsafe" operations are prohibited in XNA and Silverlight. Otherwise we would be able to call coredll funcs and run native apps (and do everything else that is allowed in our chamber).
Click to expand...
Click to collapse
Mamaich any though of a WP7 ce6.0 bsp for all the current cortex A8 devices running on a ce5.2 bsp, will the new kernel support them natively or will extensive bsp/bootloader hacking be required?
P/invoke surely is a limitation of .NET CF, rather than Silverlight/XNA libraries?
I think it would be a bit stupid to remove P/Invoking, because it's just not realistic to rely on .NETCF alone which has soooo much stuff stripped out to minimize size.
Will we be seeing a whole new .NETCF so soon after 3.5? I highly doubt it...Unless MS have been working overtime the past year
Shame, time to stop mobile development altogether if this is true. When we developers are considered as dumb earning pipes for companies who in their arrogant big ways think they have all the wisdom, and app developers only make annoying software that makes their precious leaky OS'es crash, it's time to move on. i would have been talking about IPhone, Android etc, but sadly we must add Microsoft to the list also.
Then there's the $1195,- and airplane tickets we have to pay to get to the Mix2010 in oder to maybe maybe get to be a "partner" with access to limited native API's (probably only reserved for the big companies) and don't even bother talking about giving away 30% of our earnings to a company that last year made how many billions of profits was it ?
Time to start an XDA OS based on REAL Linux maybe ? NVidia have a nice dev-board available for $400,- with Tegra on it. That's what I call developer friendly.
Cheers !
Regardless of how this will play out, I'm pretty sure of two things:
1. Closing down the OS may be beneficial for the majority of users by bringing stability, ease of use, UI consistency, etc. Even though I don't like it.
2. Because the OS itself is multitasking, any and all restrictions may be hacked around, and a "jailbreak" will be possible.
Depending on how this whole thing will be implemented, jailbreaking and using "illegal" apps may be a major PITA (think iPhone 3GS/tethered jailbreak) or as easy as a few registry tweaks/installing additional certs/whatever. If Apple didn't chase JB with every update it would be a rather good platform for both mainstream "ordinary" users and those who want rather unusual things from their phones.
We'll have to wait and see how it evolves really to make a final judgment.
Seeing as WP7 will be almost as crippled as the iPhone, let's see ways in which it will be better, besides replaceable battery and memory card(and it's not certain every OEM will follow up on those either). So far it has two weaknesses that only the iPhone has: Lack of multitasking and apps must go through the marketplace.
In order to pick up iPhone users it will have to offer some advantage that the average iPhoner will notice.
Some advantages:
Information at a glance a la today screen with the hubs. iPhone has nothing like this.
It will (supposedly) have some degree of multitasking.
Two more hardware buttons.
Its funny since I've had my HD2 I've not really used multitasking and when I had my iPhone only not being able to use Spotify in the background bugged me so maybe certainly for me multitasking isn't a be all and end all.
Having read lots of stuff about WP7S, the conclusion I have come to is this...
There will be two types of apps
1. Apps with no need to run in the background
2. Apps that do need to run in the background
Examples of type 1 are games, spreadsheets and word processors.
Examples of type 2 are IM apps like palringo, and music streaming services such as pandora.
What will happen is that when you develop an app, by default it will not have the rights to use the background APIs. In order to gain access to them and have an app run in the background, you'll need to ask Microsoft to provide the access and make it a type 2 app. Microsoft will only allow this if you can convince them it is necessary for the functioning of your app.
Type 1 apps will simply pause when the user switches away from them. They will remain in memory but will be unable to execute any code until the user switches back to them, whence they will resume execution. This will ensure the app cannot hog any CPU and cause the UI to stutter or slow down. This is definitely a good thing.
Type 2 apps are given access to particular APIs to allow them to, for instance, download updates or postings on IM systems. This will be strictly controlled and priority will always be given to the UI, again to ensure it remains smooth and responsive.
That's my take on what's going to happen, and we'll see if I'm right at MIX 2010 next month.
So your answer is - yes it will multitask but only when it is truly needed. Which to me is the best of both worlds. It will ensure a smooth user experience whilst still allowing background operations.
Jim Coleman said:
In order to gain access to them and have an app run in the background, you'll need to ask Microsoft to provide the access and make it a type 2 app. Microsoft will only allow this if you can convince them it is necessary for the functioning of your app.
Click to expand...
Click to collapse
Lets hope theyre not too stingy with giving out access to these API's!
The hubs/services (I'm not sure what MS is calling these) system looks good; getting new relative options available on multiple hubs just from installing a single app (like they demo'd with Facebook) should make all the apps work together much better than on an iPhone. I already want to try to make one to generate a music playlist based on past plays, and another to find lyrics to the currently playing song; If I understand the system properly, these would automatically integrate into any 3rd party apps using the appropriate media API's.
Also the context-sensitive search looks to be awesome.
One disadvantage: possible lack of native code execution and probably no OpenGL support - making it harder for iPhone app developers to port their existing apps to Windows Phone.
weesals said:
One disadvantage: possible lack of native code execution and probably no OpenGL support - making it harder for iPhone app developers to port their existing apps to Windows Phone.
Click to expand...
Click to collapse
why the heck should iPhone devs have an easy migration to WP7 if WM 6 devs don't?
weesals said:
Lets hope theyre not too stingy with giving out access to these API's!
Click to expand...
Click to collapse
The impression I'm getting so far is that they will be very stingy indeed. The only people who will ever get access to non-standard API's will be phone manufacturers and networks, and even they usually won't get access to the native API's most of the time. Microsoft will not publish any documentation about native API's. To get access to them the manufacturers will have to apply to Microsoft on a case by case basis. If Microsoft judges that a native API is required (and if there actually is one that might help) then only at that point will they release any information, and a condition of this is that they will vet the resulting piece of software to verify that the native API is being used correctly, and forbid the release of the software if it isn't.
What we don't know yet is where multi-tasking sits within all this. Is it a standard managed API, an extended managed API, or a native API?
why must every phone be compared to an iphone...personally I never liked the iphone, never will...only good thing about iphone is the apps..otherwise it sucks..and high end smartphones should not be compared to it!
The only thing I like about iPhone is how I use the virtual keyboard to type text.
I have tested HD2 and iPhone in a store, and from my own perspective, iPhone is more responsive and accurate compared to HD2.
I hope WP7 can be better than those 2 platforms in this task.
giggles33 said:
why must every phone be compared to an iphone...personally I never liked the iphone, never will...only good thing about iphone is the apps..otherwise it sucks..and high end smartphones should not be compared to it!
Click to expand...
Click to collapse
gogol said:
The only thing I like about iPhone is how I use the virtual keyboard to type text.
I have tested HD2 and iPhone in a store, and from my own perspective, iPhone is more responsive and accurate compared to HD2.
I hope WP7 can be better than those 2 platforms in this task.
Click to expand...
Click to collapse
that isnt aways based on the OS or software, but the quality of the touch screen.
Jim Coleman said:
Having read lots of stuff about WP7S, the conclusion I have come to is this...
Click to expand...
Click to collapse
This definitely seems like the best thing to do for multitasking in WP7.
We are going to need a task manager though...
As for comparing to the iPhone:
-WP7 will be available in different hardware configurations, giving the consumer a choice in the style and capability of their device.
-Xbox integration, which will most likely include Arcade games (ported for playability of touchscreens)
-Better hardware standards
-Not quite as locked down (hopefully)
RAMMANN said:
why the heck should iPhone devs have an easy migration to WP7 if WM 6 devs don't?
Click to expand...
Click to collapse
Because that's where the money is.
Seems people are struggling to come up with any, maybe something magical will appear in the next few weeks, although I doubt it, the advantages of WM seem like they will be gone with WP7, people on forums like this and blogs have been asking for a windows mobile iphone [without being an iphone] and it looks like they're going to heed the demand.
The most important advantages are gone.
They've made an exact copy and think it is enough. But it's not. When you try to catch up, you have to be better.
There's almost nothing WP7 is better at. It's an exact copy of iPhone OS with a better UI on top, but lacking the thousands of applications. That's not going to be enough and I really can't think about a reason why consumers and developers would be excited about this.
(and don't get me wrong - I LOVE the UI - it's just not enough)
Free Microsoft Office (Document viewing, creation, downloading, and editing)
Abobe Flash Player 10.1 is coming
File downloads (possibly)
Apps like a Wi-Fi router and file manager will likely come and be allowed
XBOX LIVE! Enough said.
Zune integration and support (I'm a Zune user)
1GHz Snapdragon is the processor minimum (This will lead to awesome apps and games)
WVGA display minimum (You might not care too much about this one, but I've seen the difference, and it's AMAZING!)
Bing search (That's just my preference.)
Contextual search (A handy feature, I suppose.)
There is not an app collection of 100,000 with most of which being totally useless. This means that you"ll be able to find the good apps.
Even if Microsoft won't allow apps like a Wi-Fi router and file manager, all we would need to do would be to get all WinPhone7 users on XDA to install the XNA Game Studio (and possibly the Win Phone7 SDK) and we could simply upload .ccgame files to XDA instead of .cab files.
giggles33 said:
why must every phone be compared to an iphone...personally I never liked the iphone, never will...only good thing about iphone is the apps..otherwise it sucks..and high end smartphones should not be compared to it!
Click to expand...
Click to collapse
I know! Why must smartphones always be compared to a simple feature phone! I've tried the iPhone/ iPod touch (3rd generation) at Best Buy stores, and, let's just say, they froze more and gave out more errors in 5 sec. than 5 WinMo devices did combined over the course of 2 hours. The iPhone's keyboard isn't too great either. It's (the errors thing) 100% true.
Jim Coleman said:
There will be two types of apps
1. Apps with no need to run in the background
2. Apps that do need to run in the background
Examples of type 1 are games, spreadsheets and word processors.
Examples of type 2 are IM apps like palringo, and music streaming services such as pandora.
What will happen is that when you develop an app, by default it will not have the rights to use the background APIs. In order to gain access to them and have an app run in the background, you'll need to ask Microsoft to provide the access and make it a type 2 app. Microsoft will only allow this if you can convince them it is necessary for the functioning of your app.
Type 1 apps will simply pause when the user switches away from them. They will remain in memory but will be unable to execute any code until the user switches back to them, whence they will resume execution. This will ensure the app cannot hog any CPU and cause the UI to stutter or slow down. This is definitely a good thing.
Type 2 apps are given access to particular APIs to allow them to, for instance, download updates or postings on IM systems. This will be strictly controlled and priority will always be given to the UI, again to ensure it remains smooth and responsive..
Click to expand...
Click to collapse
This is the right answer. Anybody who calms down would see that this makes sense. More Apple-like approval process for Type 2, free reign for Type 1
Shasarak said:
The impression I'm getting so far is that they will be very stingy indeed. The only people who will ever get access to non-standard API's will be phone manufacturers and networks, and even they usually won't get access to the native API's most of the time.
What we don't know yet is where multi-tasking sits within all this. Is it a standard managed API, an extended managed API, or a native API?
Click to expand...
Click to collapse
Yeah, you're talking about native vs managed stuff, which is not the same as simply allowing an app to have a background process. True, AT&T and HTC will have to apply to for native API use for stuff relating to making calls, etc, but that was only about OEMS and network operators.
Regular 3rd party guys, of which there are many, will be expected to get a way to do what they need on the device. Pandora we've seen in Music, you can expect apps like Palringo showing up in People
burnblue said:
This is the right answer. Anybody who calms down would see that this makes sense. More Apple-like approval process for Type 2, free reign for Type 1
Click to expand...
Click to collapse
Just because it makes sense doesn't mean Microsoft will act like that. In fact, I'm sure they will not.
The mass market will not benefit from every joe having all the API's because it's going make programs that cause glitches/crashes/memory leaks, etc. They are doing what they think is best for mass market and that is make sure things work well on the device and everything is user friendly with the least amount of hiccups possible. So that means more restrictions on us.
^^^ +1
Jim Coleman said:
What will happen is that when you develop an app, by default it will not have the rights to use the background APIs. In order to gain access to them and have an app run in the background, you'll need to ask Microsoft to provide the access and make it a type 2 app. Microsoft will only allow this if you can convince them it is necessary for the functioning of your app.
Type 1 apps will simply pause when the user switches away from them. They will remain in memory but will be unable to execute any code until the user switches back to them, whence they will resume execution. This will ensure the app cannot hog any CPU and cause the UI to stutter or slow down. This is definitely a good thing.
Type 2 apps are given access to particular APIs to allow them to, for instance, download updates or postings on IM systems. This will be strictly controlled and priority will always be given to the UI, again to ensure it remains smooth and responsive.
That's my take on what's going to happen, and we'll see if I'm right at MIX 2010 next month.
So your answer is - yes it will multitask but only when it is truly needed. Which to me is the best of both worlds. It will ensure a smooth user experience whilst still allowing background operations.
Click to expand...
Click to collapse
This neither solves problems nor guarantees anything though. Poor code is still poor code. Too many apps running is STILL too many apps running (slows the UI). MS can police neither. So, your #2 solution really makes no sense and has no advantages. MS has no way of predicting who will run what app and when on their phones. What if a user chooses to run several "Type 2" apps? Will you get some sort of error message? Will the MS police arrest you for ruining the UI experience? What happens after several years of approved type 2 apps hitting the market? Now were back to the same problems of WM.
Dude, we're talking about 1Ghz+, 512MB+ RAM phones here! You can run lots of apps without slowing anything down. Really, the "multitasking slows down the UI" argument is utter bull****. A good OS handles multitasking in a way that doesn't slow down anything. Restrictions are only necessary if the OS itself sucks. A good OS doesn't need them.
looks like i was wrong & MS is being a A$$
there arent letting browser devs use native code at the moment...this is wack, IE better be the bomb or else this is gonna suck
From Mozilla
"While we think Windows Phone 7 looks interesting and has the potential to do well in the market, Microsoft has unfortunately decided to close off development to native applications. Because of this, we won’t be able to provide Firefox for Windows Phone 7 at this time. Given that Microsoft is staking their future in mobile on Windows Mobile 7 (not 6.5) and because we don’t know if or when Microsoft will release a native development kit, we are putting our Windows Mobile development on hold"
http://wmpoweruser.com/?p=14599
No native code = no alternative browers. At least not anytime soon.
That was clear all along.
You're not going to see any "big" applications on WP7S. Fart apps and twitter clients are easy to do, however...
A twitter client is already on board isn't it?
Probably they'll also add a fart app to the final retail version. so the only thing you could do is add customized fart sounds!
I really wish it was different but to be honest I don't see any potential for interesting apps on WP7.
seems counter-productive to not release their native client to bigger development studios as yet. They certainly want a library of applications for launch, it's a bit strange they the silverlight/xna libraries 1st, when those would typically be shorter to right than something like a Firefox, Opera, etc.
gom99 said:
seems counter-productive to not release their native client to bigger development studios as yet. They certainly want a library of applications for launch, it's a bit strange they the silverlight/xna libraries 1st, when those would typically be shorter to right than something like a Firefox, Opera, etc.
Click to expand...
Click to collapse
yeah but firefox did take awhile to produce nothing on Wm6 with access to native code so maybe MS doesnt trust them with native code cuz those fennec browser cause the phone to crash sometimes..im holding out hope that they give opera permission
gom99 said:
seems counter-productive to not release their native client to bigger development studios as yet. They certainly want a library of applications for launch, it's a bit strange they the silverlight/xna libraries 1st, when those would typically be shorter to right than something like a Firefox, Opera, etc.
Click to expand...
Click to collapse
.NET apps are much quicker to develop than native stuff. That's why they focus on .NET. They will eventually have quite a big app library by the end of the year, but most of it will be "fart apps".
Will there ever be an NDK? Who knows...
C:Sharp! said:
No native code = no alternative browers. At least not anytime soon.
That was clear all along.
You're not going to see any "big" applications on WP7S. Fart apps and twitter clients are easy to do, however...
Click to expand...
Click to collapse
LOL..I hate those fart apps...or fart jokes for that matter.
The latest IE that I have on the Prime-II ROM is very good at rendering and formatting the columns for readibility, esp when used in mobile mode. Panning large pages is also very smooth and does not show any blank/white "still loading" when moving rapidly left or right or top or down. I actually stopped using opera because it suck memory and still shows white spaces when panning pages.
I'm using the word "fart apps" as an explanation for a certain kind of apps. I don't mean that they're all useless, but they're the kind of apps that are easy to develop in .NET and will likely form the majority of apps that we'll see in the WP7S marketplace by the end of the year.
(To be honest, I'm also going to make some . Useful ones, however.)
C:Sharp! said:
.NET apps are much quicker to develop than native stuff.
Click to expand...
Click to collapse
But .NET in Windows -- at least from my understanding -- has access to native/lower-level APIs.
See: PowerShell, which is unashamedly built directly on top of .NET, and yet is a viable replacement to the command prompt due to the fact it can do pretty much anything.
Spike15 said:
But .NET in Windows -- at least from my understanding -- has access to native/lower-level APIs.
Click to expand...
Click to collapse
Yes, that's correct. You can do that via P/Invoke.
You could also do that on Windows Mobile.
But not on Windows Phone 7, this feature is officially gone.
C:Sharp! said:
But not on Windows Phone 7, this feature is officially gone.
Click to expand...
Click to collapse
I had guessed.
I was just pointing out that .NET on Windows Mobile and Windows is more powerful than it's going to be on Windows Phone.
C:Sharp! said:
I'm using the word "fart apps" as an explanation for a certain kind of apps. I don't mean that they're all useless, but they're the kind of apps that are easy to develop in .NET and will likely form the majority of apps that we'll see in the WP7S marketplace by the end of the year.
(To be honest, I'm also going to make some . Useful ones, however.)
Click to expand...
Click to collapse
make some musical ones, to live up to your name!
Hehe
But actually, the name is inspired by the programming language.
No more. Now you will be a music apps developer for WP7!
Maybe. But they have to be programmed in C# nevertheless
C# is the language that's used for .NET, thus all development for WP7 will be done in C#, in case you didn't know.
C:Sharp! said:
Maybe. But they have to be programmed in C# nevertheless
C# is the language that's used for .NET, thus all development for WP7 will be done in C#, in case you didn't know.
Click to expand...
Click to collapse
Nope. I did not know. Thanks for the info. Now I know just a bit more about the WP7 platform
havox22 said:
looks like i was wrong & MS is being a A$$
there arent letting browser devs use native code at the moment...this is wack, IE better be the bomb or else this is gonna suck
From Mozilla
"While we think Windows Phone 7 looks interesting and has the potential to do well in the market, Microsoft has unfortunately decided to close off development to native applications. Because of this, we won’t be able to provide Firefox for Windows Phone 7 at this time. Given that Microsoft is staking their future in mobile on Windows Mobile 7 (not 6.5) and because we don’t know if or when Microsoft will release a native development kit, we are putting our Windows Mobile development on hold"
http://wmpoweruser.com/?p=14599
Click to expand...
Click to collapse
I am sure .net framework in wp7s can access all hardware,so why Mozilla need native api access? just performance issues...but Mozilla do a sucked Firefox on WM6.X
Finally, I think .net framework good enough to develop great browser and developer can get benefit by GUI Acceleration
Managed is slow? May be but not critical
http://www.grimes.demon.co.uk/dotnet/man_unman.htm
It's not just about performance. A browser is a huge complex app with millions of lines of code. You can't just sit down and rewrite it in a different language when your engine is done in C++ for all platforms. That's a massive endeavor that will cost millions of dollars. In addition to that, there's no access to APIs necessary to do it. You can't open a socket and work with it directly in WP7's Silverlight.
vangrieg said:
It's not just about performance. A browser is a huge complex app with millions of lines of code. You can't just sit down and rewrite it in a different language when your engine is done in C++ for all platforms. That's a massive endeavor that will cost millions of dollars. In addition to that, there's no access to APIs necessary to do it. You can't open a socket and work with it directly in WP7's Silverlight.
Click to expand...
Click to collapse
So,this is not .net or Wp7 problem
All about the money
Everything in business is about money, so what? Restricting development to Silverlight makes developing alternative browsers for WP7 impossible because of a huge investment barrier.
http://weblogs.asp.net/scottgu/archive/2010/06/30/new-embedded-database-support-with-asp-net.aspx
Replied by Scott, M$ is looking to enable it on silverlight.
I think this is also work in wp7 in future
Yes, I'm pretty sure it's among the things they wanted to do with it. Not only does it make a dead-simple database support for ASP.NET apps, but it also will be good for Silverlight as platform.
That way we can get a nice DB with a LINQ provider, that will be able to be scaled up on the *real* SQL Server when needed. A counter-reaction to sqlite being made available for Silverlight though Mono.
It also fits the whole concept with IIS7 Express very good
"That is something we are looking to enable as well in the future. Not there just yet though "
Sounds like "not anytime soon" to me.
The problem is writing a database is fully managed code is, well, difficult. Specially if you want it to be performant.
Also I think they might rather want us to use cloud service (read: Windows Azure) instead of a RDBMS, for our Silverlight and WP7 applications, if datastorage is needed. I believe you can expose a Azure Storage easily to WP7 using WCF.
The thing is that when we can't deploy any native stuff, microsoft can. They just need to provide a wrapper so it can be used from .NET
Hello XDA,
I have developed an app called Ring My Droid (Scan the QR-Code attached with this post).
Currently this app is only available for the Android platform through the Google Play Store.
I am learning to develop apps for the Windows Phone platform too. But, then I came across this section of the XDA Forum and I am interested to know if anyone out here is aware of a tool or a website or blog providing tutorials or a methodology for porting my existing application to the Windows Phone platform?
This may be a noob question, but I am very new to programming for Windows Phone so bear with me..
Any help would be greatly appreciated!
Thanks.
prognosis: serious
I don't know of any frameworks off the top of my head, but I can infer some of the answers based on experience in other platforms. And those answers are not very promising, unfortunately.
1) If you want your app to be cross-platform, you need to design it as such from inception. Otherwise you're in for a lot of work no matter how you slice it.
2) Because WP and Android use different languages for native apps, you have a big problem in just getting your source code targeted to both platforms. If your codebase is already in Java, you'll need a Java -> C#/VB/C++ translator to make it work. I'm not sure that a product like that exists. If you had started with, say, C#, you could utilize something like Xamarin to target Android and WP at the same time, but like I said I'm not aware of anything similar for Java->C#.
3) If your app is written in HTML 5, then you could adapt it to work on WP8 with very little extra effort. But in that case I bet you would have already known that you're cross-platform-compatible and wouldn't ask this question to begin with.
4) If you're resigned to rewriting your app while maintaining its core design the same, then the basic methodology is as follows:
a) refactor your app into well-defined, loosely coupled components.
b) factor away all Android specific APIs into adapter classes and have all "core" functionality written in terms of those adapters
c) port your core classes to a different platform (WP) in a WP-supported language, such as C#. This would be a straight, mechanical but nevertheless manual rewrite.
d) reimplement your missing adapters on WP to take advantage of WP APIs, while leaving internal-facing interfaces the same, so your core classes just work.
e) all of this makes sense only if there is enough complex core functionality to warrant the rearchitecture + translation. If your app is little more than glue shuffling data between external data sources, then all of this is not worth it, and a compete rewrite is the only way to go (sorry I don't have a QR reader readily available right now so I can't check your app directly).