|
So why are there so few Windows 8 apps? I will tell you my (and only my) opinion and experience. I developed a few Windows 8 apps, some of them fairly complex. I tried to develop a few really great apps but many of those projects never got done. The reason is the API (WinRT). Let’s start with something (that should be) trivial. Imagine you want to display HTML files with images, CSS, JS in a WebView.... It can be done on Android, iOS and even on Windows Phone by copying the data to isolated storage and pointing the WebView there. This scenario is impossible in WinRT. What's your experience with developing for WinRT so far?
|
|
|
|
|
I'm writing a game, and have encountered a few nasties along the way.
I started off in WinForms and C#, but that was too slow so I replaced GDI+ DeviceContext with WPFs DrawingContext. All it does is draw lots of bitmaps and I thought (probably stupidly) that'd work fine. Then, when I got Windows 8 I discovered that DrawingContext didn't exist any longer.
So, it has to be DirectX which implies having to use C++, but in fact there's an open-source interop layer called SharpDX which takes that away, so now it's C#/DirectX through SharpDX.
That, actually wasn't too hard once I got my head around how DirectX works, sadly the thing which has caused me the most difficulty is something which should be easy.
The bitmaps and config sit in loose files next to the .exe, and I load them in when the game starts. All the normal FileStream/BinaryReader stuff I would normally use for this had either gone, or was unusable (I can't remember). Instead I have to use StorageFile, StorageFolder etc. which all use the new async/await pattern.
This is supposed to make asynchronous programming 'easy', but I found it to be anything but. Indeed your async method gets turned into some sort of hideous state machine and it's very hard to understand the execution flow. That and you can't call an async method from a synchronous method at all easily.
I have a Surface, and just on this device the sound breaks up, like the machine isn't getting there in time to fill the buffers properly. I've spent ages trying to fix this or work around it but no luck so-far. I'm hoping a firmware release might fix it one day.
Still, all that said it's going pretty smoothly and I've abstracted all the horror into a single assembly so that the actual game logic is just the usual C# stuff.
Interestingly, any concerns I had about the performance of C# have gone away. About 90% of the cycles are spent in DirectX so that's just fine. But I am alarmed by the ease of reverse engineering by unlocking the WindowsApps folder and using something like Reflector. I've heard rumours that obfuscating can get you into trouble in terms of certification, but that's unverified.
I also understand that if you offer your product as a "try it free" item a simple hack can convert it into the full featured app without paying for it which is pretty poor.
A lot of effort has gone into it, so I hope it doesn't tank when it comes out. If so, that'll be my app writing days over.
Regards,
Rob Philpott.
|
|
|
|