When developing apps for Windows 8.1, Windows Phone 8.1 or Universal Windows apps, the recommended approach for app localization is to use .resw resource files located in Strings/[culture code]/Resources.resw path. This approach is quite similar to the previous .resx localization system used in .NET/Silverlight apps with one big difference - there is no generated code-behind file now that you can use for compiletime-safe access of localized strings. If you want to get the string named "ListHeader", you need to access it like this:

Now when you open properties of any .resw file in your app and enter ReswFileCodeGenerator in the Custom Tool field, the code behind file will be created automatically. It's also possible to define the namespace of the generated class using the Custom Tool Namespace field.

Now it's possible to access the string ListHeader like this:

var str = Vlak.Resources.AppResources.ListHeader;

var str = Vlak.Resources.AppResources.ListHeader;

Not just this is much shorter to use, it's also safer. If you now rename the property to ListTitle or delete the string from resources, the app won't compile, which is good, because you know immediately that the string is not in resources anymore. With the original approach using loader.GetString the app would launch but throw an exception when accessing the no longer present string.

ResW File Code Generator in Visual Studio 2015

Installing the addon to Visual Studio 2012 or Visual Studio 2013 is supported out of the box. The problem, is when you want to install this addon to Visual Studio 2015 - it won't work using the available installer. Update, new version of ResW File Code Generator for Visual Studio 2015 was released just day after my article, strange coincidence 🙂

This application lifecycle model is same across all platforms supported by Windows 10, only with a minor differences based on the device performance, memory, etc.

Application Lifetime - app can be in 1 of 3 states:

Application receives events when transitioning between states, Except: Suspended->NotRunning. This has not changed since Windows/Phone 8.1.

Extended Execution

Previously if user switched from app A to app B, app A was suspended with no way to continue running.
In Windows 10 it's possible to request Extended Execution from OS.
App must provide reason for extended execution: ExtendedExecutionReason.LocationTracking or SavingData or UnspecifiedThis is basically the replacement for background location tracking API in Windows Phone 8, that was missing in Windows Phone 8.1.

User can revoke the request for extended execution. Revoked events will have ~1 sec to clean up. Min time is guaranteed but opportunistic afterwards.

Opportunistic Background Tasks serve as a replacement for Windows Phone 8 that had no replacement in Windows/Phone 8.1 ResourceIntensiveTasks.

In-Proc Background Tasks

Originally background tasks were executed in separate process - with separate memory cap. In Windows 10 it's possible to define in-process background tasks - shares memory cap with the host process. This can be defined the Pacakge.appxmanifest.

Socket Trigger Tasks

Apps can have network connectivity and discoverability maintained while suspended or even terminated. Alternative to WNS triggered Tasks

How it works:

In foreground app process: Create/retrieve socket(s), Register background task to be woken up, Give socket to broker service as app is suspending, Take socket back from broker service at any time

On incoming network activity on brokered socket: Background task is triggered, Take socket back from broker service

Summary

Background processing is converged with Windows
There are lots of new things you can do
But resources are still limited

Windows 10 Universal Apps support new compiled bindings that use {x:Bind} syntax - it's possible to replace in some scenarios classic DataBindings, that are resolved in runtime using reflection, with new compiled bindings, that are created in compile time against specific DataContext type:

Declarative bindings are converted into generated code behind

Eliminates need for slow runtime “reflection” operations

Code can be inspected and debugged

x:Bind bindings are validated at build time

Performance improvements are clearly visible in lot of benchmarks shown in the session. Both faster page loading and smaller memory footprint.

How to use it - Replace {Binding ...} with {x:Bind ...}. x:Bind is strongly typed. Mode=OneTime is the default.

Usage in Data Templates:

Resource dictionaries with bindings: Need to have a class, Need to have a code behind, Need to be loaded using their type. Too complicated for tl;dw, better check the session 🙂

Usable on all events, can replace usage of ICommand & EventToCommand behavior. Note does not cover command parameter, or ICommand.CanExecute scenarios

Binding Lifecycle & Performance

Binding initialization done during Loading event

Bindings.Initialize() will initialize bindings

Can call Bindings.Update() for async data

Bindings.StopTracking() to pause tracking, Update() will resume

OneTime binding is cheaper than OneWay

Bindings.Update() can be used to update OneTime bindings

For lists – consider INCC update of item rather than INPC for property

Not all binding path nodes need to support change notifications

How do I handle:

RelativeSource = Self, ElementName = … => x:Bind uses the page/user control as the context, so can use the element name

RelativeSource = TemplatedParent => x:Bind is not supported in a control template. Most scenarios should use TemplateBinding instead which is already optimized

Source / DataContext => Binding context for {x:Bind} is fixed, and can’t be changed for sub elements unless it’s a template. Options: Use a longer path to get to the data, Add a field/property to page and bind to that

When to use classic binding

Duck Typing – same property name on different objects => Text=“{Binding Age}” works for both Person & Wine objects. x:Bind Mitigation: use a base class / interface

Dictionary graphs => {Binding} can work with JSON or other dictionary of untyped objects. {x:Bind} doesn’t work without typing information

Target Version - highest API version used in the app. Example, if the app uses API from OS version 10.0.10100 and it's known that there is breaking change in this API in Windows 10.0.10250, then this package won't be available on Windows 10.0.10250 and higher until the developer publishes new package for the new API version.

Min Version - min API version required. The package won't be available on Windows with lower OS version than the MinVersion.

Windows Device Family Extension SDKs - used for accessing platform specific features like phone SIM card features, the vibrator, etc.

Since there is usually only single project and single assembly, it's not possible to use conditional compilation using #if. Solution: Windows.Foundation.Metadata.ApiInformation, reflection-like API for checking if specific type/method/property is available on current device

How to migrate from Windows/Phone 8.1 to Universal Apps? Typically by creating single new UWP project, using adaptive code for platform specific stuff and platform specific views for different form factors. It's still possible to have one project for tablet and one for phone (or for Xbox, IoT...) and share code using linked files, or using Portable Class Libraries, or using Shared Code project, it's up to developer and the target app.

XAML UI is the primary native UI Framework for Windows 10 Apps and Services. Lot of new features were added to it with the same goal - increase the reach and dev opportunity, reduce the cost to deliver apps and decrease loading time and memory footprint.

When creating new Windows 10 project there is now only one universal Windows project template for all platform or devices.

New Native CalendarView control is now available for developers. Touch Friendly, used in Outlook, Calendar popup when tapping the current date in bottom right corner.

Basic controls were updated to match across all platforms. Context menu is now cascading. On Desktop it can go outside the window, which is nice. When invoked by touch, it's bigger, tailored for the target platform and input type.

When running app on Xbox One overlay rectangles are shown over the active control. It works the way you expect it to work. It runs on Raspberry Pi 2 too, just deployed and it works.

In some controls there were differences between WP and Windows behavior, like in PasswordBox the Show Password icon. In some scenarios both original behaviors were kept with the option to select the right one for your app.

There is both SearchBox and AutoSuggestBox in Windows 10. SearchBox will be likely deprecated in the future.

There is updated Pivot control in Windows 10 that works great on large screens too. Optionally it can work as Tabs too.

New ContentDialog control, like MessageDialog, but you can customize it with your own XAML content.

Simplifying Responsive View Development

New SplitView control - basically a navigation affordance, typically used with the Hamburger button in top left corner.

New AdaptiveTrigger and simplified Setters, no need to use Storyboard + ObjectAnimationUsingKeyFrames + DiscreteObjectKeyFrame just to change single discrete value from A to B.

RelativePanel - the replacement for common pattern - nested panels. Gives better performance in typical scenarios where nested panels are used in ItemTemplates.

Before, nested Grid and StackPanel.

After, with RelativePanel

XAML Performance improvements in Windows 10

If you just take your Windows 8.1 app and run it on Windows 10, it runs faster. If you recompile your Windows 8.1 app to Windows 10, it runs even faster!

The goal when controls for Windows 10 apps were designed - single API across all types of devices, screen sizes, input options. But each platform should also get tailored UI experience.

Example - specific Context Menu based on input method mouse vs touch:

Effective pixels - screen sizes are measured in effective pixels that are based on physical screen size, screen resolution and expected distance from the user, keeping the same visual size of elements on all platforms.

Breakpoints - when designing your app there are typically three breakpoints when app layout should change from one to another:320 epx, the minimum default view -> 720 epx, first breakpoint-> 1024 epx, another breakpoint. This is only example, it's up to you how you design your app.

Most common navigation patterns, how content/navigation/commands are placed on a screen, observed in real world apps, not just in Windows Store:

Pivot - typically Contacts app. Useful when navigation between set of pages is common task. Avoid controls with horizontal interaction - Map, ToggleButton. No more than 6 pivot items should be used. In Windows 10 it's possible to layout all Pivot items next to each other, useful on large screens.

Tabs - typically Twitter app. Variant of pivots with fixed order tabs on top of the screen. Muscle memory for easy content switching. No more than 5 tabs should be used.

Hub - typically Xbox hub. useful for displaying complex pages, lot of content at the same time. Good for content consumption, not for creation. Works good with touch and gamepad.

Hamburger - typically Office or Mail apps. used for infrequent navigated items, allows more content to be displayed. On large screen could be expanded by default. Hamburger symbol very common and well known among users. Works best when placed top left according to usability testing.

6 R's of responsive content when switching between small and large screen sizes

What is the Windows App Model? It's a specification of all processes in the app, how it's downloaded from Store, deployed, started, communication with the OS, how the app lifetime works, how the app capabilities and access rights are managed, how the app contracts, data roaming, device usage work, and also how the uninstallation process is handled.

Windows 10 app model is same across all supported platforms: IOT->Mobile->PC->Xbox->Hololens.

Adaptive Tile Templates - same Tile size but different content based on actual tile size.

Action Center - same look and feel shared across all platforms. Alarms and Reminders working again, can be viewed in Action Center. Action Center Change Trigger for updating Live Tiles when notification is removed.