If anyone has developed WP apps before you know that you can't pass certification if your app stops music that is currently playing without the users consent.
I did see this question here which might have worked for WP7 apps but it apparently doesn't work for WP8. I assume it doesn't work because the WP8 OS doesn't support XNA (It is only backward compatible, and if you developed the app using 7.1).
Has anyone come across the solution for detecting background music in WP8.
I believe checking for MediaPlayer.GameHasControl is what you're looking for. Use that property and other members of MediaPlayer to satisfy application certification guidelines 6.5.1 Here's an end-to-end example of how # http://henry-chong.com/2012/02/pro-tip-including-background-music-for-your-windows-phone-app/
BTW, 6.5.x application certification requirements don't apply if your app is a Music+Video app. That's one way to address 6.5.1 :)
I believe that Microsoft.Xna.Framework.Media.MediaPlayer.State is still supported in Windows Phone 8 (MSDN source):
You can reference and use the following XNA Framework assemblies in
apps that target Windows Phone OS 8.0:
...
Microsoft.Xna.Framework.Media.dll
...
Related
I have a Windows phone 8.1 Silverlight application.
Now I need to make it run also on windows 10 phones and tablets. I checked and the app is available on windows 10 phones, even if deployed for windows 8.1 but it seems like I can't install it on windows 10 tablets.
My question is pretty simple:
Is there a "fast way" for converting the 8.1 project to UWP?
Can I deploy my app for tablets without re-writing all the code?
Thanks all
This question is oddly similar to one that I answered just yesterday. It's not really a duplicate so I will restate the answer here along with a link to the other question (1)
Unfortunately there is no easy and fully automated way to port your Silverlight app to UWP mostly because the API footprint has changed and updated between the 2 platforms. There are a lot of similarities but also a lot of breaking changes that require some manual changes.
here is Microsoft's guidance for this particular upgrade path.
From the article above:
Note This guide is designed to help you port your Windows Phone Silverlight app to Windows 10 manually. In addition to using the information in this guide to port your app, you can try the developer preview of Mobilize.NET's Silverlight Bridge to help automate the porting process. This tool analyzes your app's source code and converts references to Windows Phone Silverlight controls and APIs to their UWP counterparts. Because this tool is still in developer preview, it does not yet handle all conversion scenarios. However, most developers should be able to save some time and effort by starting with this tool. To try the developer preview, visit Mobilize.NET's website.
[1] Can a Silverlight out-of-browser app be converted to Universal Windows Platform (UWP) app?
For some reason everything I've found online says that the Accelerometer class is only for winRT applications and I can't use it unless I code against winRT. I dont understand what winRT is. And my app can't be a metro style app because I need special access to different APIs that I've read can only be accessed in a WPF app. Also windows 8 metro style apps wont work with windows 7 which I would like my app to work for. Also I've only recently started programming so explain it to me like I'm a 4 year old.
Thanks!
The accelerometer you are referring to is a specific WinRT (Windows RunTime) class which is not available in .NET.
WinRT API was made for phones and tablets, but also integrated in Windows 8 / 8.1. It's basically the API for 'Metro' apps and therefore requires such an app. It will definitely not work for Windows 7, since WinRT is not available for this OS. I'm also somehow wondering, why you would need an accelerometer on Win7 (Notebook?), but that is a different topic.
I've once tried to get WinRT stuff working in C#.NET, and to my knowledge, this is not possible.
If you can provide us any additional information about your idea, maybe we can offer you an acceptable alternative.
I have a Windows Phone 8.1 Silverlight application which is in the store now. Since i see that Microsoft is moving all the attention towards WINRT and Universal Apps, i suspect that there will be limited or no support for Silverlight Apps in Windows 10.
There might be a tablet project that i might roll out for the same project in the future. So i am in the dilemma to convert the Silveright projects in my solution to WINRT or convert them into Universal Apps.Also, i hear that converting to Universal projects are pretty hard as well.And I understand that the bulk of the work will be in porting the UI to Hub Style UI.
Any ideas? Comments on the best approach to take here.
A WinRT app is a Windows only app (not for Phone). Other than that, WinRT and Universal apps are quite similar. They have the same namespaces, classes, controls... almost everything. You can use many WinRT libraries in Universal apps without any problem. And so, porting to them is generally the same, too.
Windows Store and Windows Phone apps generally need different UI anyway, so you would have to work on that, no matter what you do.
One difference is that a WinRT app would work on Windows 8.0 and up, and a Universal app would require Windows 8.1 (or WP 8.1 for phones). Actually, a Windows 8.1 app IS a Universal app. Just like a Windows Phone 8.1 app (not the Silverlight variation) is a Universal app.
I'd recommend porting to a Universal app as you would get used to working with these apps, and they work on both platforms (Windows and Phone). For any future project, that's the way to go.
In the company I work for, we switched to Universal apps a few months ago. Figuring out what UI we would use on both platforms and how to do it properly, as well as porting our existing libraries did take some time (not too much), but now making a new app and supporting both platforms is very easy. So, for me, that's the way to go.
It is quite unlikely that Microsoft will stop supporting Silverlight Apps in the Windows 10 version for phones. Even WP8.1 still supports XNA Games from the WP7.0 era.
Depending on the APIs you are using in your libraries the majority of changes when converting from Silverlight to WinRT will be on the UI side, e.g. if your Silverlight App already uses the LocalStorage-APIs instead of the IsolatedStorage-APIs that won't even have to be changed.
My advice would be the following:
evaluate wether all functionality you need is supported in Universal Apps (some functionality is currently only available in Silverlight Apps)
evaluate wether the actual APIs you are using are supported in Universal Apps or need to be replaced (IsolatedStorage => LocalStorage, etc.)
Armed with that knowledge I'd guess you will be able to better plan on when to port your App to the new APIs. If a tablet version is likely in the future and all required APIs are supported in the Universal App Model porting sooner will likely require less effort than porting later.
After watching a little bit of the summit keynote I kind of heard conflicting reports about it, but is it official that XNA is being dropped for WP8? I'm guessing since the future version of WP supports previous generation of apps that this is probably not true.
If it is though is using C# even an option for games or is C++ with DirectX the only way to go?
the official wp7dev twitter account had this to say too
"XNA Framework apps are fully supported in WP8. The new WP SDK will support building XNA Framework games for both WP7.x & for WP8"
https://twitter.com/wp7dev/status/215513026374270977
Personally given the lack of XNA updates or information and the lack of any Metro support on windows 8 I'm staying a little skeptical until I see an SDK and the publishing rules.
Mary Jo Foley had this to say about that:
Microsoft officials have said the XNA tools/runtime environment used primarily by game developers isn't supported on Windows 8. On Windows Phone 8, XNA is "supported," so existing Windows Phone games will run. But Microsoft's advice to phone developers going forward, just like it is for Windows 8, is to use native code, meaning C and C++, to write games.
As the public WP8 SDK is now available, I can confirm that you cannot develop XNA apps for the #WP8 platform directly. You can only target the WP7 platform with your XNA apps and they will run on WP8 devices just fine.
I'm sure it's too early to speculate on this at this point, we'll see when the SDK is released. But from what I've seen so far - I would say yes, XNA might not be officially supported WP8 and onwards (read - new features will probably only be available via the DirectX interface, but existing features will continue to be supported). However, according to this thread, games that use Monogame to run on Windows 8 metro will pass certification. So in one way or the other, the platform will not die.
Edit: I just noticed this tweet from Shawn Hargreaves: Windows Phone 8 runs all 7 apps including XNA ones. We're adding new features (native code, D3D) not taking away old ones
I've been working on and off on an XNA game that I had started with VS2010 & WP 7 SDK, and later upgraded to 7.5 (Mango). I loaded up that project in VS2012 and the WP8 SDK and it ran just fine, compiled with no errors and ran smoothly.
As previously stated, XNA projects in VS2012 and the WP8 SDK can only target the WP 7.1 platform. On the upside, all phones running WP 7.5, the upcoming 7.8 and WP8 will run your game without any issues. From that point of view, XNA is fully supported in the WP8 SDK, on WP8 devices, but these WILL NOT be WP8 projects.
By not being WP8 projects, the downside is that you CANNOT use WP8-exclusive features, such as:
In-app purchasing / micro-transactions (this one hurts XNA devs the
most)
Your games will always be 800x480 since you need WP8 projects to support higher resolutions. Your XNA games should automatically scale up when run on devices with a higher res
Exclusive WP8 networking features & APIs, including Bluetooth and NFC
Speech and voice recognition APIs
Your XNA game cannot register a protocol extension for app-to-app communications
New Live Tile templates
The dev highlights for WP8 are on the wpdev blog at http://blogs.windows.com/windows_phone/b/wpdev/archive/2012/11/05/windows-phone-8-developer-platform-highlights.aspx.
Im trying to create a media player (in C# .net 4.0) that will work on windows XP (SP3), vista and 7. Normally I would just go the easy way and use WPF's own MediaElement, but since that relies on Windows Media Player 10 or newer, that wont work as Windows XP SP3 may only have WPM9.
First I tried downloading Jerimiah Morill's WPF MediaKit sample application, but this used the EVR which wont show on my test machine (a Windows xp SP3 only with default codecs and default programs, plus the various .Net framework installations). I also downloaded the binaries and tore these apart, creating a new project only with reference to the DirectShow-dll and the bare minimums from the WPF mediakit, this time with no reference whatsoever to EVR. Still no luck. This i'm having a hard time understanding - should'nt even Windows XP be able to play movies using VMR stright out of the box?
I found some samples of media players where one of these works. This one is called DxPlay and uses directshow's graphbuilder, but is built in winforms, has some rather raw-looking code, and will not scale, seek, handle audio, and in general seems rather sketchy.
So, Is there any easy way to create a media player that will play on all the mentioned platforms without pushing WMP10+? I had high hopes for WPF MediaKit, but something is preventing it from playing on Windows XP SP3 (any solution to this would be very interesting).
Thank you very much in advance!
-ruNury
I would try to wrap VLC media player in your .Net project.
Here are some .Net projects that might help you:
http://vlcdotnet.codeplex.com/
http://sourceforge.net/projects/libvlcnet/
http://www.codeproject.com/Articles/109639/nVLC
MSDN suggest EVR (Enhanced Video Renderer) for video output in systems where it is supported: Windows Vista and later. With its introduction, its predecessors - Video Mixing Renderer filter (versions 7 and 9) were cut on smooth scaling of video. Video Mixing Renderer 7 is also less capable in terms of customization, however it consumes far less resources (does not use Direct 3D) and you can output way more videos at once.
Your standard solution here is to support both VMR and EVR output and use the latter starting Windows Vista, fall back to the former otherwise.
EVR is "unofficially" installed in Windows XP with .NET runtime and can be used with an instantiation trick: you the respective DLL is not COM registered and you cannot create an instance using CoCreateInstance API, however you succeed if you do CoLoadLibrary, DllGetClassObject and friends.
For C# development you typically consume DirectShow through DirectShow.NET Library.