Category Archives: Modern Windows Apps

Developing Windows 8 apps on Windows 8.1 Dev Machine (Updated)

TLDR; Don’t do it

I built Kalliope media player for Windows 8.1 before Windows 8 because the MediaElement and overall APIs that I wanted looked more mature in 8.1 than 8.0 and hence it was ‘faster’ to build it for 8.1.

But Windows 8 PCs still outnumber Windows 8.1 PC by almost 2:1. Lesson for Microsoft, their PC customers are not as keep ‘upgraders’ as say Phone customer (specifically Apple iPhone customers). Anyway, Windows 8 platform was hard to ignore so I decided to backport Kalliope to run on Windows 8.

My Dev Environment

Window 8.1 VM fully patched with Visual Studio 2012 Express and Visual Studio 2013 Express for Windows.

So near yet so far

I was using VS2012 on the VM for the Windows 8 port. Work was almost done, and I was ready to start WACKing the app, when I thought, might as well run it on a Windows 8 machine and test! BAM!!! The Application failed to even navigate properly. Couple of exceptions I’ve caught so far

App_UnhandledException: The property ‘HeaderTemplate’ was not found in Type ‘Windows.UI.Xaml.Controls.Combobox’

App_UnhandledException: Failed to create a ‘Windows.UI.Xaml.TextWrapping’ from the text ‘WrapWholeWords’.

After getting these two, I stopped testing and now restoring my Windows 8 Dev VM so that I can actually build the entire Code on Windows 8 and see what actually compiles and what doesn’t.

Why is this happening?

Well first of course it is because I copy pasted XAML from my Win 8.1 app to my Win 8 app. But then question is shouldn’t it be causing build errors? Well, I think so. I’ll know soon enough once I compile the code in Win 8. But the point is, this exact XAML works in Windows 8.1, in the sense when I hit F5 in VS2012, the app complies without error or warning and runs perfectly fine. Which basically means Windows 8.1 WinRT APIs are more forgiving of XAML errors. However, unfortunately for you, this means you CANNOT trust a Windows 8 build of your app created on a Windows 8.1 machine. Yes Yes Yes, I know… I feel like saying it too… but heck… what’s the point!

Essentially there are API leaks (this is my term, maybe it should be called something else, sue me), because of which Windows 8 apps when run on Windows 8.1 will work even with incorrect XAML attributes (or attributes that were not supported in 8.0 but are supported in 8.1).

Update 1 (Feb 9, 2014)

Well, looks like I am not too much of a trouble, so far the only issues reported are as follows:

image

Mind you, these are visible only if the designers are open. The build is otherwise reported as OK. So these will bite your bum at runtime.

Moral of the story?

1. You need a dedicated Windows 8 machine to develop and test a Windows 8 app, don’t depend on a Windows 8.1 machine.

2. Microsoft has more or less abandoned 8.0 from an API stand point, should you really bother about a back-port? Well you decide!

3. (Updated on Feb 9, 2014) You will not face these issues if you are upgrading your App from Windows 8 to Windows 8.1. You have to be careful only when you backport, so as to not use new stuff (which is understandable). So the only thing is play closer attention to Designer errors.

Conclusion

I may have been a little too harsh on MS, but still it’s clear that there is only one XAML engine in Windows 8.1, the one that has all the enhancements for 8.1. So if you mistakenly put some new stuff in Windows 8 App, it will work on 8.1 but fail in Windows 8.

Tagged , ,

QuickBytes: Hacking up the color of a WinRT ProgressBar

WinRT never ceases to throw a curveball at the you. I was trying to change the default ‘Violet’ color of the ProgressBar and ProgressRing to something more ‘in tune’ with my app’s style, but the only ‘violet’ color visible was the Foreground property, but changing it did nothing to change the color of the ‘running dots’.

After ‘ducking’ around I found a Brush called ProgressBarIndeterminateForegroundThemeBrush. There are two ways to override it.

1. Create a resource with the same name and assign a different color. You can do it in your App.xaml or in the XAML of the screen you need it updated in as follows:

<Application.Resources>
<SolidColorBrush
x:Key=”ProgressBarIndeterminateForegroundThemeBrush”
Color=”#FF2EADE8″/>
</Application.Resources>

2. Update the color at runtime in code. I found this article that might come in handy.

Hope this helps someone, it’s a note for me anyway!

Tagged ,

Naming Assets in your Windows 8 Store App

I just spent a few lazy minutes looking up what it takes to name assets (images) for appropriate scaling, and since I didn’t find the correct keyword to look it up in one go, writing this down to bookmark it for myself.

It’s a good idea to provide an independent images for your Windows 8 Store App, each for the appropriate scale factor. Well you don’t have to and if you only provide the Scale 100 images Windows will upscale it for you, but it won’t be pretty. With the Surface 2 going Full HD you have all the more reason to provide all the necessary scale factor images so your app looks the sharpest everywhere.

image

Now the endeavor is not for the faint hearted, you will end up requiring about 25 different images. However there is an easy way to name them such that they get picked up automatically for each scale and you don’t have to go assigning them independently.

For example if you are setting up assets for Splash screen you can name them as follows:

image

And once you assign the scale-100 image, the rest will get picked up automatically.

Mind you if you have just one image, you can name it anything and assign it to the mandatory Scale 100 resource. However if you put in a scale-xxx image, you have to rename your Scale 100 resource to say scale-100 explicitly.

Well, that was a small naming convention thingy that I knew existed but forgot what it was exactly. Now I’ve got it written down, shouldn’t forget it ever now Smile.

Tagged , , ,
%d bloggers like this: