Bitesized tidbits for building Modern (Metro) apps.
For a while now, there have been a few ways for developers to allow a user to sign into Facebook:
With Windows 10, there’s a new way for developers to be able to authenticate their users, and that’s the WebAccountProvider. This allows account providers (like Facebook) to provide authentication using their Windows 10 app. Using this approach would mean your users would never have to leave the comfort of your app to get authenticated.
So what does all this mean? What is WebAccountProvider? It’s possible, in Windows 10, for apps to allow developers to explicitly use them as an authentication provider, without having to use URI schemes and callbacks to be set up by the calling app. The difference between this approach and the URI/Callback approach is this can be done silently so the user can potentially never leave your app but still get successfully authenticated.
All of this blog post is based on the current Windows 10 Facebook beta that came out recently. If you submit a Windows 10 app to the store before this version leaves beta, this code will not work as the user will likely be using the non-beta Facebook app. If you only depend on this approach, then your users will not be able to authenticate with Facebook, so it’s important to have some fallback methods.
This is now available in the non-beta version of Facebook for Windows 10 too, so will work for anyone who has updated their app.
In Windows 10, we’ve seen apps that look to have different tile faces and they cycle between those tiles. It’s a really nice effect and can be a very powerful thing for your app to use, it allows you to present more data to the user without having to have your tile all cramped. A good example of this would be a weather app where you might want to allow the user to show the weather for different places. So, how do you go about creating a tile like this?
In your Universal app, you may want to have AppBars that have different colours from the default theme colours, which is understandable if you want to add your own branding to it. But when you set the Foreground/Background colours, you may end up with behaviour you weren’t fully expecting.
With Windows 10, two key areas of personalisation for a user are the lock screen and the wallpaper images, and this is both on phone and desktop. And on both you’ve always been able to set the lock screen image (for now we’ll just forget that WPA8.1 apps couldn’t!), but setting the wallpaper was something you couldn’t do in either desktop or phone. Now that’s changing with Windows 10. Whilst the APIs for settings these aren’t the most complicated ones in the world (Wallpaper/Lock screen), no-one would ever say they wouldn’t like things even simpler, right? Also, how about being able to set these things from a viewmodel in a PCL?
One of the new ways users can interact with your app is through notifications. Now, notifications are nothing new, for either Phone or Desktop, however, what’s been added to 10 is new. With Universal Windows Apps, you can now have interactive toast notifications. So what are these? They are like regular toast notifications only they can have elements that the user can interact with, maybe make a selection, or type in a response to something.
There’s an excellent blog post on MSDN that covers all the different types of interactions you can have within your app’s toasts, along with all the xml elements that are required in order to build your toast notification, but that does mean dealing with xml, and who likes that?!
One of the things you can add to a Desktop variant of a Universal Windows App is a back button that a developer can add to their app; this back button appears in the top left corner of the app. In order to use the back button, the developer needs to tell it to appear, as well as potentially wire up to the back button’s pressed event, but that’s not the Cimbalino way.
I realise the first question you have: “Unplated?” Well, give me a chance. In your app’s package manifest, you have a section for Square44x44Logo, this logo is used in the task bar and in the application list in the start menu. What you will notice is that, by default, your image will have a border around it, like so:
Notice the grey all around the icon (note: that grey is defined in the package manifest too, so doesn’t have to be that colour)? Now, for your app’s branding, maybe you don’t want that border as that goes against how your actual tile looks, and consistency is key, right!
When creating your awesome layout to your awesome new app, you’ll often use Grids as a way of ensuring things are placed where you want them to be and you’d most likely use the ColumnDefinitions and RowDefinitions. Using these has a number of benefits, not least letting you specify exact heights/widths for your columns/rows, but you can also use Auto and the * values to set screen percentages. What this means is you can have a very exact UI or one that adapts as the size of the window changes.
Adapting to the size of the window is something that’s more relevant to UWPs than ever before with you bringing one UI to all possible screens the user can use your app on. But what if you still want to keep some rows at a certain screen percentage until the user hits a trigger point? Well, a small, but subtle change to xaml now allows you to do more with your Column/RowDefinitions.
One of the things shown off at Build recently was this new thing for updating tiles, called Adaptive Tiles. The notion is, that like your Universal Windows Apps can adapt to different sizes on different platforms, so, too, should your tiles. So Adaptive tiles allows you, with one bit of XML tell your tile how to behave at different sizes. For more information, you should definitely watch the Build session on all this
The problem is, it means crafting the XML. And who likes XML?