Tag: UWP

UWP: Localized String UI XAML Properties

I was messing around in Visual Studio today and decided to spruce up my UWP apps a little bit. Originally what I was doing for all my string UI XAML properties on every project was hard coding them in the XAML code like this:

<PivotItem Header="Item 1">
    ...
</PivotItem>
<PivotItem Header="Item 2">
 ...
</PivotItem>

However there are several major flaws with this:

  1. Your strings are hard coded in the XAML code and if you were to make any modifications it would need to be done programmatically which could get messy.
  2. There is no consideration for other languages other than the one you have hard coded; a big oversight if you plan on releasing your app worldwide.
  3. It is not very flexible and easy to manage; if you need to change your strings it would have be done across a number of XAML files and it could take a long time to change everything.

Nearly every tutorial or blog post when they are writing string UI XAML properties they  always do this ‘hard coded’ method. Even Microsoft does this on their official page when outlining the different Controls and Patterns, see the Tabs and Pivot example here. Really though, I don’t blame them as it is really simple and gets the picture across nicely for beginners and the focus is really on the Controls and Patterns. However if you are going to be making a commercially viable product that will be used across different continents, supporting a number of languages is critical.

Eventually to solve this problem you have to do some Googling or Binging (not sure if that is the Bing equivalent), or if you use the new extension/tool called the ‘Windows Template Studio’ to help build your new app it sets everything up nicely for you. This is all well and good if you use the extension/tool but if you are not, then Microsoft again has a convenient page to look at, see here. I used this page to solve this very same problem and it should help you as well.

The solution to this problem can be broken down into several steps:

  1. Set a Default Language on your Package.appxmanifest (outlined in red).
    Package.appxmanifest Default Language Setting
  2. Create a ‘Strings’ folder in your root project solution.
  3. Create a subfolder that matched the Default Language you have set.
  4. Create a Resources.resw file under the subfolder.
    Default Language Strings Folder Structure
  5. Add all your string UI XAML properties in the Resources.resw file where:
    1. Name: The XAML property you are referencing including the XAML object.
    2. Value: The value for the XAML property, what you want shown.
    3. Comment: A simple comment to help identify and describe what the property and value is for.

The Microsoft page listed above outlines a very simple example and how to test your application, so I am not going to go into further detail here and I suggest you look at their example and testing method. If you are starting out doing some UWP app development then you might not be aware of what the best practices are (I still don’t), so hopefully you find this information useful and you can create commercial grade UWP apps for the Microsoft Store.

UWP: Loving the Windows Template Studio Extension

I subscribe to a number of development blogs and articles, and I have been meaning to play around with the new Visual Studio extension that got announced at Build 2017 for a while now. What better time to use it than when I am about to complete the transition from “proof of concept” to fully fledged Universal Windows Store application?

Installing the Windows Template Studio Extension

Microsoft has made it super simple for anyone with Visual Studio to install this new extension. If you have Visual Studio 2017 (I have not personally tried it on an earlier version of Visual Studio), navigate to Tools – Extensions and Updates…

Once the new Extensions and Updates window appears, on the left hand side navigation pane select Online and then Visual Studio Marketplace. On the top right hand side there is a search bar, enter “windows template studio” and press the Enter key on the keyboard. You should see Windows Template Studio now appear in the list of tools and extensions. Click Install after selecting the Windows Template Studio extension; to start and complete the installation you will need to close Visual Studio.

After the installation process completes and you restart Visual Studio, you should see the extension Windows Template Studio with a green check mark. A screenshot of a successfully installed extension/tool is shown below.

WindowsTemplateStudioInstallation

Using the Windows Template Studio Extension

With the installation complete we can start using the new extension. I was super excited to see first hand how the extension could simplify the process of creating a new UWP application. If you haven’t opened Visual Studio, open the application. Create a new Project (default shortcut key is Ctrl + Shift + N). Open the Windows Universal Visual C# Template on the left hand side pane and select Windows Template Studio. Fill in your solution/project details as you see fit and click Ok.

UsingWindowsTemplateStudio

The Windows Template Studio wizard will launch and right off the bat it offers some templates and frameworks to get you started on the right foot; a good first sign. First you get to choose a Project Type; and you get three options (I guess the options they give are ones that most developers will use when developing their apps). You also get to choose a Framework, one of which is based on a third party; it looks like Microsoft isn’t playing any favourites here and is offering what they feel is best for developers (this goes to show how much Microsoft has changed and how much they really care about developers). Click Next once you have chosen a Project Type and Framework.

WindowsTemplateStudioWizard1

If you have never developed for the Universal Windows Platform then already having a Project Type and Framework setup for you makes things much easier for you in the future. But now is where the true customization and helpfulness really begins; in this part of the wizard you get to add the Pages and Features you want to your application. To make the next couple of choices easier for you, it would be beneficial if you nailed down how you would want your application to look and how many Pages you want (but you could always manually add more at a later date).

You first get to add Pages to your application. I found this part of the wizard extremely useful as it provides some common Page Types such as Settings, Map, etc. A bonus is that you can add as many as you want 🙂

WindowsTemplateStudioWizard2

Microsoft went above and beyond for the Features part I believe, kudos Microsoft. You get a plethora of Features to choose for your project. They are some of the most common when working on your application such as a First Run Prompt, Live Tiles, and Suspend and Resume. I really appreciate how Microsoft broke them all down them into easily recognizable Features, and on top of that if you are not sure what the Features do, there is a little information button you can click to learn more. Once you have selected all the Features you want click the Create button

WindowsTemplateStudioWizard3

If you look in your Solution Explorer, you will find all the Pages and Features that you selected ready for you to work on, just like magic. It could not be any simpler. If you want to start developing for the Windows platform and you choose UWP, then it would be foolish to not use this extension. It is easy to use, offers all the basics and groundwork to get started quickly. When I start working on any new UWP project, I’ll be using this extension going forward unless I can add all the necessary features faster myself (but most likely not). Overall I am very impressed with the options that you could choose to quick start your development.

For more information about the Windows Template Studio Extension have a look here and here.

UWP: Dynamic UI 1/2

If you are new to C#/UWP programming then one of the furthest things that may have crossed your mind is a UI that is dynamic and fluid based on the screen size or the device form factor your application is running on. However this concept is very important and is super easy to implement. So I thought I might do a little write up about this and help some people out. I know I may not have all the information presented here but I would like this to be a starting point that others can build on and hopefully this post is useful to some.

When I first started working on developing UWP applications I tried to have the core functionality working for a desktop PC, i.e. anything from a 12” screen sized device and up; and I did not really consider other form factors like mobile devices or the HoloLens. But the more I work on UWP applications and how simple it is to implement this functionality I ask myself, why not consider it up front? Microsoft actually has some really useful information and even provides a worthwhile example, see here. Plus there are numerous StackOverflow questions with answers and blogs/articles that discuss this exact topic. So now when I work on any UWP application I consider what UI elements need to be placed where for the various form factors and screen sizes.

If you use the link provided above then it will already place you to the correct spot in the article that outlines how to modify the UI layout based on screen sizes/form factors. The method to have your UI change based on your form factor or screen size I will be discussing is the use of Setters, StateTriggers, and AdaptiveTriggers.

Setters, StateTriggers and AdaptiveTriggers

Some of the advantages of using the new Setters designed for Windows 10 over the Storyboards that you would have had to previously use are:

  1. No more GoToState method call in your code: there is no C# code that needs to be written when using the new Setters; your application will dynamically change layouts when the state condition is met.
  2. Cleaner XAML Code: syntactically the XAML for using the Setters is cleaner and easier to read. The Storyboard objects could sometimes get very complex and large I found.
  3. No empty DefaultState: the properties in your XAML outside the Setters appear as your default properties and the Setter values will not be triggered until the state condition is met. You do not need to define an empty DefaultState.

Using the Setters, StateTriggers, and AdaptiveTriggers are extremely easy as well. The Microsoft article provides a solid example but I am going to provide two more for reference. In the first example I will showcase the change in font size when the screen changes size, and the second example will showcase rearranging of TextBlock objects when changing screen sizes and on a small form factor device like a mobile.

Example 1: TextBlock Font Size Change

This was actually one of my very first attempts to have the UI dynamically change with a changing screen size and form factor. Below is the XAML code that I wrote to get the font size to change for a TextBlock object that is displayed to the user; some of the unnecessary XAML code has been omitted.

<Page>
  <ScrollViewer>
    <VisualStateManager.VisualStateGroup>
      <VisualStateGroup>
        <VisualState>
          <VisualState.StateTriggers>
            <AdaptiveTrigger MinWindowWidth="720"/>
          </VisualState.StateTriggers>
          <VisualState.Setters>
            <Setter Target="TitleTextBlock.FontSize" Value="24"/>
          <VisualState.Setters>        
        <VisualState>
      </VisualStateGroup>
    </VisualStateManager.VisualStateGroup>
  </ScrollViewer>
  <Grid>
    ...
    <TextBlock Name="TitleTextBlock" Text="Bill" FontSize="12"/>
    ...
  </Grid>
</Page>

As you can see the amount of XAML that needs to actually be written is fairly minimal. How does the StateTrigger actually work? The AdaptiveTrigger object defined specifies that if the screen size is more than 720 pixels (that is the state condition) then the TextBlock object will have the font size set to 24; however if the screen size is less than 720 pixels the TextBlock object will have the font size set to 12. This can be seen working below (using the exact XAML code above).

DynamicUIFontSizeChange
Example 1: Dynamic UI TextBlock Font Size Change

My next example will be in a follow up blog post, so stay tuned for another post real soon about Dynamic UI. That one I feel is more important and relevant as it moves UI objects around to ensure an optimal layout for a change in screen size and what it looks like on a mobile device.

%d bloggers like this: