Create the Ultimate Fan Universal App using Windows AppStudio – Part 2 1/2

Originally posted on:

When I first started this series, I intended on it being delivered in 3 parts. But in wrapping up the series, I felt that an important piece was missing – understanding the structure of the Visual Studio solution generated by AppStudio. So this post is technically not part 3, but simply a brief tangent to discuss the anatomy of an AppStudio solution.

In Part 2 of this series, I demonstrated how to get 90% of the Ultimate Fan Universal App completed simply by using Windows AppStudio. Since we require some code modifications to get the band’s concert listings displayed within the app, we downloaded the archive containing the source code generated by AppStudio.

At this point, you will need some basic knowledge to be able to navigate through the code, and make changes. If you’re new to Universal App development, C#, and/or XAML, I recommend watching the following Microsoft Virtual Academy courses which will help you to get up to speed fairly quickly:

1) Programming in C# Jump Start

2) Developing Universal Apps With C# and XAML

3) Designing Your XAML UI with Blend Jump Start

Anatomy of an AppStudio Solution

Now we need to unzip the contents of the archive to a folder on the local machine, then launch the provided solution in Visual Studio. Let’s take a look at what that includes based on how we configured the app in AppStudio.


Notice that the solution contains 4 projects: 2 platform-specific projects, 1 Shared Project, and 1 Portable Class Library.

Platform-Specific Projects


A Universal App currently supports both Windows 8.1 and Windows Phone 8.1, which requires two separate files to be compiled and submitted to the Window Store. You can see this reflected below in the solution, where each supported platform is contained within separate projects. They can both share code in different ways which we will get to shortly.

The platform-specific projects contain components that are exactly that: platform-specific. This includes user interface elements and code that target the current platform, such as custom controls, styles, views, as well as images that are used for the application’s tiles, background image, splash screen, and logo.

Windows 8.1 and Windows Phone 8.1 both render and display data in a different way. Apps designed for Windows 8.1, known as Windows Store apps, will run on laptops, desktop PCs or tablets with more screen real estate than Windows Phone 8.1 devices. Also the default orientation of a Windows Store app is in landscape mode, whereas the default orientation on a Windows Phone 8.1 device is portrait mode. When designing a user interface for each platform, it is best to customize the layout and user experience to each supported platform.



Shared Project


The Shared Project is made up of files, images, and classes that are independent of any target platform. For example:

– Resource Dictionary files which contain localized strings that are used within the app.

    • – Converters which render how elements are displayed or format data in a specific way based on an object’s property value.


  • – ViewModel classes which contain data which need to be displayed within the views.


    – Services to incorporate features such as Speech Recognition, Maps, and Navigation.


Shared project files are copied into each target platform whenever the solution is compiled.

Portable Class Library

clip_image007The Portable Class Library contains code which is also platform independent, but is compiled separately outside of the solution. Each project contains a reference to the compiled library. Portable Class Libraries are great for code reuse among multiple projects.

As we can see, AppStudio generated a number of classes:

1) Data Providers – base classes containing logic which loads data from a source (ex: web service, static data, local database, etc).

a. The RssReaders folder contains classes to parse data from Atom and RSS feeds

b. The Twitter folder contains classes to handle Twitter authentication using OAuth so that the app has authorized access to the Twitter API.

2) Data Schemas – represent the models for data that is retrieved within its associated data provider

3) Data Sources – extensions of the data providers to load data from a specified source

4) OAuth – supporting classes for Twitter authentication.

Important Note: Your Twitter ConsumerKey, ConsumerSecret, AccessToken, and AccessTokenSecret are in the OAuthTokensRepository class. If you share your project code with others (for example, by posting it on Github or making the code available for download via OneDrive), be sure to scrub these values from this class and just use placeholders. Never let anyone have access to these values!

5) Tiles – logic for updating the application’s tile (ie. title, content, and image)

So now that you have a basic understanding of your AppStudio solution structure, it will be easier to figure out where changes need to be made to achieve the end goal, which I will cover in the next and final post in this series.

Source: GeekswithBlogs – Lori Lalonde