What Is a Universal Windows Platform (UWP) App?

The concept of a common application architecture was first introduced in Windows 8 as the Windows Runtime. Windows Runtime (WinRT) was an evolution of the Windows app model, intended to be a common application architecture. When Windows Phone 8.1 became available, the Windows Runtime was aligned between Windows Phone 8.1 and Windows. This enabled developers to create Universal Windows 8 apps that target both Windows and Windows Phone, using a shared codebase. This article introduces you to the Universal Windows Platform.

Introduction

Windows 10 introduces the Universal Windows Platform (UWP), which further evolves the Windows Runtime model and brings it to the Windows 10 unified core. As part of the core, the Universal Windows Platform now provides a common app platform available on every device that runs Windows 10.

Apps that target the Universal Windows Platform can call not only the WinRT APIs that are common to all devices but also APIs (including Win32 and .NET APIs) that are specific to the device family the app is running on.

The Universal Windows Platform provides a guaranteed core API layer across devices. This means you can create a single app package that can be installed on a wide range of devices.

1. Device Families

Windows 8.1 and Windows Phone 8.1 apps target an operating system (OS), Windows or Windows Phone. With Windows 10, an app no longer targets an operating system. Instead, an app targets one or more device families.

A device family identifies the APIs, system characteristics, and behaviors that you can expect across devices within the device family. It also determines the set of devices on which your app can be installed from the Store.

The decision which device family (or families) your app will target determines:

  • the set of APIs that your app can assume to be present when it runs.
  • the set of API calls that are safe only inside conditional statements. To isolate sections of code that are platform-specific, use the #ifdef directive.
  • the set of devices on which your app can be installed from the Store.

Here are some considerations to help you decide which device family to target:

  • Target the universal device family to reach the maximum range of devices.
  • Choose to target your app at one of the child families if it is specialized for, for example, a desktop PC or Xbox.
  • Target two (or more) child device families instead of targeting the universal device family.
  • In some cases, you may want your app to run everywhere except on devices with a particular version of a particular device family.

By default, Microsoft Visual Studio specifies Windows.Universal as the target device family in the app package manifest. To specify the device families for your app, manually configure the TargetDeviceFamily element in the Package.appxmanifest file.

2. User Interface and Universal Input

Windows helps you target your user interface to multiple devices with the following features:

Universal Controls and Layout Panels

Windows 10 includes new controls, such as the calendar and split view. Controls have been updated to work well on larger screens, adapt themselves based on the device’s screen resolution, and work well with multiple input types, such as keyboard, mouse, touch, pen, and controllers, such as the Xbox controller.

To help you adapt the user interface of an app based on the amount of available screen space, Windows 10 introduces adaptive panels and design states.

The new RelativePanel implements a style of layout that is defined by the relationships between its child elements. It is intended for use in creating app layouts that can adapt to changes in screen resolution.

Visual State Triggers

Your app’s user interface may need to adapt to changes in window size. Adaptive visual states allow you to change the visual state in response to changes in the size of the window.

State triggers define a threshold at which a visual state is activated, which then sets layout properties appropriate for the window size that triggered the state change. Here is the XAML for the visual state triggers described above.

Windows 10 introduces an evolution of the existing scaling model. In addition to scaling vector content, there is a unified set of scale factors that provides a consistent size for user interface elements across a variety of screen sizes and display resolutions.

You can build a universal Windows app using universal controls that handle various inputs, such as a mouse, keyboard, touch, pen, and controller (such as the Xbox controller).

3. Writing Code

Your programming language options for your Windows 10 project in Visual Studio include Visual C++, C#, Visual Basic, and JavaScript. For C# and Visual Basic, you can use XAML for a full-fidelity, native user interface experience.

For Visual C++, you can choose to draw with either or use XAML. For JavaScript, your presentation layer will be HTML. Let’s look at these different cases.

Whenever you want to call an API, you’ll need to know whether the API is implemented by the device family that your app is targeting. If you want to call just a small number of APIs, you could use the ApiInformation.IsTypePresent method like this.

A UWP app or Windows Runtime Component is written in C++/CX has access to the Win32 APIs that are part of the UWP. These Win32 APIs are implemented by all Windows 10 device families. Windowsapp.lib is an umbrella lib that provides the exports for the UWP APIs. Linking to Windowsapp.lib will add to your app dependencies on DLLs that are present on all Windows 10 device families.

4. User Experience

A UWP app allows you to take advantage of the unique capabilities of the device on which it is running. It provides a set of built-in features and universal building blocks that make it much easier to create a great user experience for multiple devices.

You can still have one app package that runs on all devices by checking what device family your app is running on before calling an extension API. Here are some of the features that you get when you create a UWP app:

  • When your app runs on a Windows-powered device, the system uses an algorithm to normalize the way controls, fonts, and other UI elements display on the screen. This scaling algorithm takes into account viewing distance and screen density to optimize for perceived size.
  • Although you can design for specific input devices, apps use an input system that uses “smart” interactions. That means that you can design around a click interaction without having to know whether the click comes from an actual mouse click or the tap of a finger.
  • The UWP provides a set of universal controls that are guaranteed to work well on all Windows-powered devices. These controls are input-aware and deploy with the proper set of input affordances, event states, and overall functionality for each device family.
  • Your UWP app automatically gets a default set of styles which can be customized to give your app a personal touch, or can be replaced completely to create a unique visual experience.

Conclusion

Here are some of the characteristics that make UWP apps on Windows 10 different:

  • You target device families, not an OS. A device family identifies the APIs, system characteristics, and behaviors that you can expect across devices within the device family. It also determines the set of devices on which your app can be installed from the store.
  • All UWP apps are distributed as a .appx package, providing a trustworthy installation mechanism and ensures that the apps can be deployed and updated seamlessly.
  • There’s one store for all devices. You can submit and manage all your apps for Windows devices in one place.
  • The UWP core APIs are the same for all Windows device families. App using only the core APIs will run on any Windows 10 device.
  • Extension SDKs are specialized APIs for each device family, which can be used if the app is intended for a particular device family.
  • UI elements use effective pixels, so they automatically adapt themselves based on the number of screen pixels available on the device.

Universal Windows App Project File Structure

All Universal Windows apps following MVVM pattern should have a similar directory structure. The following snapshot shows a possible project file structure of a Universal Windows app.

Let us see briefly what all things go into each folders.

  • App.xaml
  • Controls: Reusable UI controls (application independent views) without view models. Platform specific Controls are added directly to the specific project and Shared controls are added in the Shared Project.
  • Strings: Classes and resources for application localization
    • en-US: Separate directory for every supported language.
      • Resources.resw
  • Models: Model and domain classes
  • ViewModels: View models classes
    • MainWindowModel.cs
    • MyViewModel.cs
    • Dialogs
      • SelectItemDialogModel.cs
  • Converters: This folder includes the Value Converters. Follow this article to see how Converters can be used in Windows apps.
  • Themes: It contains Theme Resources that is Resource Dictionary. Platform specific resources are added directly to the specific project and Shared resources are added in the Shared Project.
  • Services: This could include classes for web service calls, navigation service etc.
  • Utils: It includes all utility functions that would be used across the app. This may include AppCache, FileUtils, Constants, NetworkAvailability, GeoLocation, DataTemplateSelector etc.
  • Views: Contains the views. Platform specific Views are added directly to the specific project and Shared Views are added in the Shared Project.
    • MainWindow.xaml
    • MyView.xaml
    • Dialogs
      • SelectItemDialog.xaml

As shown in the list, the name of a view should end with its type:

  • Window: A non-modal window
  • Dialog: A (modal) dialog window
  • Page: A page view (mostly used in Windows Phone and Windows Store apps)
  • View: A view which is used as subview in another view, page, window or dialog

The name of a view model should be composed of the corresponding view’s name and the word “Model”. The view models are stored in the same location in the ViewModels directory as their corresponding views in the Views directory.

Universal Windows App Project Setup

This tutorial is a part of the series on Building a Universal Windows app using MVVM pattern. In this tutorial we will setup a new project for building a Universal Windows app.

Setting up the Project

In Visual Studio click on New Project and choose Blank App (Universal Windows 8.1) from the existing Templates. If you are unable to find this template in your Installed templates list then head over to the following link to download the latest SDK for Windows Phone.

https://dev.windows.com/en-us/develop/download-phone-sdk

Structure of Universal Windows app

When you first open up the Solution, the project structure looks something like this.

Each of the platform specific projects contain an Assets folder and a MainPage.xaml file. The shared project contains the App.xaml file which is shared by both the Windows 8.1 and Windows Phone 8.1 apps. The Windows and Windows Phone projects are platform projects and are responsible for creating the application packages (.appx), targeting the respective platforms. The shared project is a container for code that runs on both platforms. They don’t have a binary output, but their contents are imported by the platform projects and used as part of the build process to generate the app packages (.appx).

Switching between Startup projects

To set the startup project, right-click on the project node in the Solution Explorer and choose the option Set as Startup Project. You can quickly switch the startup project from the Debug target drop-down that now enumerates all the possible projects in the solution. The project that you choose is shown in bold in the Solution Explorer. The available debug targets change when switching startup projects.

  • When the Windows project is the startup project, the Debug target drop-down displays options for the Windows Simulator or Local Machine.
  • When the Windows Phone project is the startup project, the drop-down displays options for Device as well as various emulators.

Switch context in Code Editor

When writing code in a shared project, you can use the project context switcher in the navigation bar to select the platform you are actively targeting, which in turn customizes the IntelliSense experience in the code editor.

Cross-Platform Code in Shared Project

In the shared project, you typically write code that is common to both platforms. To isolate sections of code that are platform-specific, use the #ifdef directive. The constants WINDOWS_APP and WINDOWS_PHONE_APP are predefined for you.

We are done setting up our project and getting familiar with a few handy features of Visual Studio while building a Universal app. You could reference the following article to create your first universal Windows app.

Creating Your First Universal Windows App

Series Introduction: Building a Universal Windows app using MVVM pattern

I am starting a new series to help you get started with Universal Windows app development. If you take care of a few things then you could save a lot of time while building a Universal app. Almost all the code can be shared and only the UI needs to be built separately. Even the UI can be shared. In this series I will touching upon a lot of small things that can be used while building the app.

We will be following MVVM design pattern as much as possible. I will strive to have zero code behind and all the code in ViewModel itself. Getting started with MVVM has a bit of learning curve involved but I think it’s best to follow MVVM while building a universal Windows app. I will keep updating this article with link to other parts of the series as I cover them.

Universal Windows App Project Setup

Universal Windows App Project File Structure

How to Check for Network Availability in Universal Windows apps

Application Data in Universal Windows Apps

How to Display Local Toast in Universal Windows Apps

Using Shared Theme Resources in Universal Windows Apps

How to Build a Gauge Control for Universal Windows App

Build great Windows apps with your Android app code

Project Astoria lets you build great Windows apps, while reusing your Android app code and tools.

Apps built with this technology leverage key Windows interactions, and deliver the kind of experience Windows users expect. With Project Astoria you’ll be able to:

  • Build Windows apps for phones with few code changes
  • Use a Microsoft interoperability library to integrate Microsoft services into your app with very little effort
  • Test and debug your app from your preferred IDE
  • Publish your app and get paid through the Windows Store

To make changes or debug your app, you can use your current IDE. It supports IntelliJ, Android Studio, and Eclipse, and in addition to Windows development machines, you can use your Mac.

Learn more about Project Astoria here.

https://dev.windows.com/en-US/uwp-bridges/project-astoria

Chapter 1: Developing Windows Apps using Visual Basic

Please have a German – English dictionary by your side or use one of the many translators available online. I am using Microsoft Visual Studio Express 2013 for Windows. Visual Basic is being used.

Select and click: New Project

New Project

Visual Basic

Store Apps

Windows Phone – Apps

Windows – Apps

Select Windows – Apps

Name: MyApp1 (when the name is typed in, the other two lines are filled by itself.)

Path: c:\users\emmanuel\Visual Studio 2013\Projects (Durchsuchen means search)

Project Folder: MyApp1

Create Directory

Ok (click ok button). Abbrechen means cancel.

 

Now you are taken to the project window.

Here you see the MainPage.xaml.vb, MainPage.xaml, App.xaml.vb as Title of the pages to be displayed when you click one these.

MainPage.xaml is being displayed now. On the right you have the Project Explorer and Properties windows. Right below the main display you see the XAML code displayed which you can edit but DO NOT touch now. We will come to that later as time goes by.

Now let us go to the Project Explorer on the right-hand side.

Here let us click the Assets folder (Directory)

 

 

Here in the Assets directory, the images are saved. These four images have to be replaced by your own but without changing the name.

  • Logo should be 150 by 150 pixels.
  • SmallLogo should be 30 by 30 pixels.
  • SplashScreen should be 310 by 150 pixels.
  • StoreLogo should be 50 by 50 pixels.

SplashScreen pops up for a few seconds when the app is called in. The other three are for the Windows store market meant to catch the attention of potential users.

SplashScreen

Logo SmallLogo StoreLogo

 

Now let us start some work in the MainPage.xaml. Once you are in the main page form, you can activate the Tools listing. (From View listing and the Tools). Then from the tools list select the ListBox by double click. You will see the listbox on the top left of the mainpage display. Drag this down to the mainpage body. Using the properties list, you can change background colour, change text font size etc. The ListBox should be highlighted for you to see and change the properties. Assign a name to the ListBox. ListBox1 for example.

In the mainpage you can change the size of the listbox by dragging the highlighted frame.

Now from the Tools listing, select Button and double click. Drag the Button appearing now in the top left corner of main page to the main body. Just like what we did for the listbox, give a name, change fore and background colours, text font size and type in the content, a title for the button.

 

Click the top right box in the properties of the button and

Fill in for Click…..Button1_Click. (Button1 is the name of the Button.)

Now the MainPage.xaml.vb gets activated and a module is created

Button1_Click(……) for you to write the code.

Herein you type in the code.

ListBox1.Items.Add(” What a Wonderful World “) the beautiful song of Louis Armstrong. Now run your app by pressing F5 or clicking Debugging.

Click the Button1 and your text appears in the ListBox. Return for more codes by pressing alt+tabs or anyother means.

Now let us create a TextBlock by double clicking TextBlock in the Tools list and then dragging the TextBlock from the top left corner of the Form to the main body. Highlight TextBlock and do the necessary changes in the properties.

Now you can directly type in the messages in the TextBlock. Similarly, you may select anyone of the tools from the Tools List and continue.

Now let us select the Image tool by double clicking, dragging and so on. Drag an image from a directory and place it in the Assets directory. Highlight the Image block in the Form and select Sources in Properties. All the images in the Assets directory will be now listed in the Sources to enable you to select the required image.

Here there are six TextBoxes, three Buttons and the rest as labels in TextBlocks. While executing the program, you enter a point number and then two plane coordinates X1 and Y1. When you click the accept button. These values are stored in respective variables, declared by us in the code in MainPage.xaml.vb. Plane coordinates mean Cartesian coordinates in a plane. That is a two dimensional plane. In the Cartesian system, the axes intersect at right angles.

Now let us go to the MainPage.xaml.vb.

At the top of the MainPage.xaml.vb form, we declare the variables. Dim i as Integer. i is going to be used as a counter.

We are declaring an array of ten for each of the variables except the counter.

  • TextBoxes accommodate only String variables.
  • Long.Parse converts String to Long.
  • Double.Parse converts String to Double values.
  • ListBox takes in only String data, therefore we have to convert the non-string values to string by using X1(i).ToString.

 

I typed in this line of text in a new textblock but on execution the word “necessary” appears broken with spaces within the word “nece s sary”. This could be edited in XAML as shown below.

 

 

One has to be careful meddling with XAML. An inadvertent entry or space will prevent the Page.xaml from loading. Let us go back to the Button2_Click() module.

 

The single apostrophe is used for comments. (Instead of REM etc.)

Try

 

Catch

 

End Try these three are used to catch errors and prevent the system hanging.

PtNo(i) = Long.Parse(TextBox5.Text) convert the string contents of TextBox5.Text to variable type Long and place it in

the array element of PtNo(i). PtNo(0) is the first element.

If (PtNo(i) = -99) then GoTo 100 if the value entered is –99

Then goto to line address 100:.

 

100 numpts = i – 1 (the number of points in the list)

GoTo 120

 

 

  1. Lists the data in the ListBox1.

The numpts has to declared as integer. See the top of the form.

 

Let us see another sub-routine.

 

editptno is declared at the top as variable Long and this takes in the contents of TextBox5. editptno is compared with all the point numbers in the list and when an identical point number is found, then the X1() and Y1() values are placed in the respective TextBoxes so that you may edit and Accept.

Editflag = 1 a flag is set to show you were here and this is shown and used in the Button2 routine.

In Button 2, editflag is used to prevent incrementing the point number and give a wrong number to the number of points in the list.

Enter the number that you want to edit, press Edit button, make the correction and then press the accept button.

 

Now let us analyse the sub-routine Button2_Click() which we are using to type in a set of coordinates. TextBox6 is assigned to take in the Point Number of a point. Point number has been declared by us as a variable Long. If this text box is blank then an error message is listed in the list box. If this text box contains anything else other than numbers then the Try Catch End Try argument catches the error and the message appears in the list box. If TextBox5.Text contains –99 then a list of the points is listed.

 

If any points have been edited then you are taken to the address 110:

If the TextBox1.Text and TextBox2.Text are empty then an error message in the listbox otherwise two variables take in the coordinates provided the text boxes contain only numbers.

The point number, X1 and Y1 are listed.

The point number is incremented and shown in TextBox5.Text so that you may enter the coordinates of the next point.

editflag is set to zero.

If TextBox5.Text contains –99 then a list of the points is listed as in address 120:

When you see in the listbox that you have given a wrong coordinate then you enter the point number to be edited in TextBox5.Text and press the Edit button. You are taken to the edit routine.

 

 

If the number of points is less than 1 then the chances are that you have not entered –99 before coming to the edit routine. In the routine Button2_Click(), the variable numpts takes in thevalue of number of points entered, only when you enter –99 in the TextBox5.Text and press the accept button.

These steps should eventually be written in the guidelines and instructions to the users and may even be included in the listboxes. We will come to that later.

The variable editptno2 takes in the number of the point to be edited and goes through the list of the given data, comparing point by point the point number and takes and displays in the text boxes the values to be edited as shown in line address 100:.

 

The number in the list i1 is saved in the variable editcounter1 and used in Button2_Click() routine inorder to save the editted data at the original listing position.

 

 

Similarly for the second set of coordinates in Button3_Click and Edittwo_Click().

The number in the list i2 is saved in the variable editcounter2 and used in Button2_Click() routine inorder to save the editted data at the original listing position.

 

Next chapter we will learn about

  1. Writing data to and reading from text files.
  2. Doing calculations with the coordinates to find distances between points and area contained in polygons constructed with the list of coordinates.
  3. Drawing the lines and polygons. Etc.
  4. UI (User Interfaces).