If you’re testing an app that uses the Nokia Imaging SDK (or any other app that access your pictures library, for that matter) and you can’t see any content in your pictures library it might be the result of a bug in the emulator.
If you need to access the in-built images, you need to open the photos app at least once before you run your app. once you’ve done that, the content will become available to your app.
(Thanks to the guys at Nokia, this information has now been added into the documentation. I’m childishly pleased to have been able to help out in my own small way. )
I’ve just been having a look at the Nokia Imaging SDK (also available via NuGet). It looks like it really bridges the gap that a lot of developers have when they want to include image technologies in their apps. (for example, you can specify an image size that you want to use in the PhotoChooserTask, but you can’t let the user decise what aspect ratio to use. It’s even less flexible in the CameraCaptureTask where the user can’t do any manipulation at all.
Adding this SDK would allow you to give a lot more control to your users as it supports cropping, resizing, rotation, scaling, filters and other image enhancements.
There’s a tutorial application project in the full downloadable version of the SDK (not available via NuGet) that will quickly get you started. Give it a try! (I would highly recommend you read the Quick Start guide as well, though. ;))
MVVM Light has a messenger implementation which can communicate with the UI layers in order to handle things like page navigation, and using this is is very easy to set up a PCL ViewModel assembly to drive both a Windows 8 and Windows Phone app. As a quick example of how you’d set this up, imagione this implementation in a view model.
So, you’re about to start an MVVM Windows Phone app, and you really want to be able to run unit tests against your view models using Visual Studio’s built-in test engine.
By default, you can’t do that for a phone app – you need to create a Phone Unit Test App that will wrap everything and spit out the test results when you run the app.
If you really want to be able to run tests within the IDE you can build your view models in a separate Portable Class Library (yes, those again). As long as you add .NET as a target framework for the VM library, you will be able to write your tests in the same way as you would for any other project type.
Of course, this approach is not appropriate for all functionality – for phone-specific functionality you will need to use the default (separate app) approach, or a mix of the two.
In the course of writing unit tests on a project, I came across in interesting wrinkle for testing MVVMLight ViewModel classes. When creating a ViewModel, the work is actually done on different thread which leads to the following unit test code throwing an exception.
publicasync Task ConstructorAddsNoItems()
Instantiating the SummaryViewModel class leads to the following exception message being displayed.
The application called an interface that was marshalled for a different thread. (Exception from HRESULT: 0x8001010E (RPC_E_WRONG_THREAD))
The solution is relatively simple, though. First I create a method to allow me to run an action and marshal its result back to the appropriate thread.
I posted briefly yesterday about an experience with the WordPress app for Windows Phone. I’ve not used it much more than an initial look around, but for the most part it seems to be a great app – apart from the experience when you are writing a post.
Once you get into the text editor for the post body, you initially see a screen like this.
OK, so the buttons look kind of randomly placed, but no biggy. The issue I had was when I entered the textbox and started adding text.
Now we have the ability to enter text, just as you’d expect. There are, however, 2 issues here.
There is no obvious way to save your work and return to the previous screen, and
there is no way to access the additional feature buttons that were on the screen
It turns out that the way to get back from the editor once you finish entering text is to simply press the back button. I’m not sure about that design choice, to be honest. It feels counter-intuitive somehow, as if you are going to abandon your changes. In fact, it felt so counter-intuitive that I avoided doing it until all hope was lost and I was resigned to losing my text. Not a great user experience.
The second issue is harder to work around. If you want to apply formatting to the post after you’ve entered your text, you have to jump through all kinds of hoops to achieve it (re-enter the text editor with the SIP, select the word, press the back button, press the required formatter).
There has to be a better way. Unfortunately, the platform doesn’t allow much flexibility in this regard. There’s no simple way to implement your own HTML editor on the platform without some sort of compromise – I’ve said it before and I’ll say it again, designing an app is hard and there’s really no substitute for experience and a good designer.
One option that we have is to use a third party control, prehaps the COmponentOne RichTextBox control.
Note the use of the app bar to add edit functions, even while the SIP is present. It doesn’t immediately get around the first issue I mentioned, but is certainly a step in the right direction.
I am going to write a further post about handling the SIP in apps, and how to modify the layout to ensure that important UI elements don’t become inaccessible when the SIP is displayed.
Note : I am not trying to criticise the authors of the WordPress app – I like the app and I’m glad the authors are focussing on their core strengths of developing a great blogging platform rather than supporting applications.
Nuget is one of my favourite tools within the Visual Studio ecosystem, but sometimes you need access to packages you have installed before while you are not connected to the internet. This simple trick shows you haw you can do just that.
NuGet caches all the packages it downloads in a subfolder of your AppData filestore. You can easily set this folder up to be a package source like so…
Open Visual Studio, and go to Tools -> Options
Find the “Package Manager” section, and expand it
Click on “Package Sources”
Click the “Add” (+) button in the top right
Set a name for your local cache (I call mine “Cache” – imaginative, huh?)
Enter the path “C:\Users\<username>\AppData\Local\NuGet\Cache” in the Source textbox
Now when you open the package manager, you will see the Cache folder listed as a package source and you can install packages from there. Be aware, though, that packages may be out of date with respect to the online version, and dependency packages may not be available.
The ICommand interface has been around for a long time now. It is typically used in a desktop application, for example, to allow the simple binding of buttons or menu items to an action in the code behind, and can be extremely useful.
A common scenario in Windows 8 where command support would be useful is on the click event of a GridView item – for example, an item on your main menu screen. Unfortunately, the platform doesn’t support commands here out of the box, so we have to do some juggling and introduce an attached property to do the work for us.
Let’s start by creating a class to hold the attachable property.
// TODO: This is where actual navigation would take place.
newMessageDialog("navigate to item id "+obj.NavigateToTarget).ShowAsync();
Now, when you run your app, you should be able to navigate to the clicked item (or if you haven’t changed the code, see a MessageDialog with the item id). Note that in the command’s CanExecute method, I only allow navigation to items whose Id is an even number.
Being a developer in both Windows 8 and Windows Phone is an interesting life. Given the relative newness of both of these platforms, and the similarities in look and feel between them, you’d probably expect that the code can be shared easily between the platforms for the same app. Sadly, that’s not the case for more than about 60% of the code base. (I’m not even going to start on the presentation layer – XAML will always need to be *at least* tweaked to account for the different screen sizes)
The differences between the desktop and phone APIs can cause sleepless nights, as well as necessitating two separate versions of a code base with all the complexities that entails (fixing the same defect multiple times, for example).
Luckily there is a solution that can help us out greatly – Portable Class Libraries. These useful little additions to the platform allow you to write one assembly that can be consumed by Windows 8, Windows Phone, Silverlight or the full .NET framework. But there is a catch – supporting all these platforms comes at a cost of compatibility. The code you write in a WinForms app is likely to use different methods, located in different parts of the BCL to the same feature on the phone.
Fortunately, Microsoft have put a lot of time into portable class libraries, and done some lever under-the-hood work to redirect calls the the PCL versions of some tasks to their platform-specific counterparts. A great example of this is the PCL HttpClient (announcement – NuGet package). This makes the task of getting content from the web a snap, and you don’t need to worry about which of the implementations of a web client to use in your assembly. Just use :
Hopefully that one example will give you some insight into the power of the portable class library, and it’s ability to simplify your coding across the platforms. I will be posting a list of useful NuGet packages that extend the base PCL functionality soon, although there’s plenty of good stuff already in there to get you going.