Bitesized tidbits for building Modern (Metro) apps.
Whatever your reasons are for using WebView in a UWP app, whether it’s just to display some raw HTML or you need to actually show external web pages inline in your app, one thing is almost certain, you will not be able to await the web navigation. Yes, you can subscribe to the events for completed, failed, etc, but that then starts to all become a little messy, especially if you end up having to this in multiple places.
Ideally, it would be nice if you could just say to the WebView, “you go ahead and navigate, I’ll wait here.” So what can you do?
One of the cool things about UWP apps is the way in which they can interact with “big Windows” apps as well as other UWP apps. What do I mean by this? Well, the easy example is dragging and dropping things into your app from either another UWP, or from a regular win32 application, likes files, from Explorer.
It can be a pain to set everything up for your app to start accepting files via drag and drop, so I’ve rolled the basic behaviour into, well, a behaviour.
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.
If you’ve tried submitting a Windows 10 app to the store recently, you may have come across a problem where it’s asking you to enter store information for a language your app isn’t configured to support (in my case, I had an app that was en-GB, but it was requesting details for en-US, too). This can be frustrating because you probably don’t want to have to create the assets and store information for that extra language; so why is it appearing?
There are a number of blog posts, that show off a new feature in Windows 10 development call xaml views, that allow you to have a different xaml file for the same page depending on the device family (a great one here by Morten). There may be genuine reasons where going for an adaptive approach might not be right for your app depending on the design constraints of your app, in which case it makes perfect sense that you’d want device specific views.
Coming soon with the new Lumia devices is a nice feature called Continuum, which allows you to effectively use your phone as a PC, where you can connect it to a monitor, and use a mouse and keyboard with it, and really shows to highlight the universal aspect of Universal Apps as you effectively then have a desktop UI that you can use. So using a desktop on a mobile, what could go wrong?
Localising your apps can be hard, whether it’s finding the funds to get all your resources localised, or finding community members who will help you do it, it’s never easy. Those levels of difficulty can also be increased when you start to consider right-to-left languages, such as Arabic, or Hebrew, because it’s not just a question of adding those languages and you’re done. Far from it, in fact. Not only do you have to write extra code just to enable right-to-left, there are other practical matters that you may need to consider for your app’s design. Why? Because with right-to-left languages, the whole UI gets mirrored. Let’s look at some of those things you may need to think about.
A while back, I read a really interesting article on the best way to approach prompting your user to leave a review for your app, it’s a really good read, so I do encourage you to take a moment and give it the once over. The TL;DR version of it, though, is basically: don’t push a prompt up to yours users to leave a review, don’t do anything that shoves this kind of thing in the user’s face, be it ads, reviews or whatever. The suggested solution is to display your review prompts inline with the rest of your display data (this assumes you have that).
So how do we go about doing that on Windows Phone/Windows? Actually, it’s rather simple (sorry Silverlight, this is not for you).
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?