SnapGold is a photo-sharing UWP code sample that runs on Azure App Services and uses Azure DocumentDB and Azure Blob Storage for its data storage. You should be able to get this sample running locally using its mock (i.e. dummy) service in 5 minutes and then fully link to your own Azure App service in less than 30 minutes.

There’s lots of great stuff in this code, even if a photo-sharing app isn’t your goal. The navigation framework, MVVM patterns, Azure integration, push notifications, and authentication are all juicy bits that you can port directly to your own apps.

...

How easily can I port this to my own app?

Perhaps the best way to show off this code sample is to fork this sample into another photo-sharing app. In a few steps below, we’ll create SportsPics, an app for sharing sports pictures. Click here to download the free SportsPics app from the Store to get an idea of the look/feel of our code sample.

Open PhotoSharingApp.sln and hit Ctrl+F5 to run the UWP app. It should deploy the UWP locally and launch SnapGold using the mock service mentioned above. You’ll see a red “dummy” box at the top indicating it’s not hitting a real service. This should give you a feel for how the app functions. The next step is getting the app pointed to your own, real service.

Follow the Getting Started guide to get your own App Service hosted in Azure.

At this point, you should have the SnapGold code sample running on your own Azure hosted App service. Now let’s tweak the app a bit.

Change the default colors from Gold to whatever you want. We chose Blues for SportsPics:

Add a logo. I created one in PhotoShop and simply added it to the header control in the PageHeader.xaml

Update the app name in package.appxmanifest.

Ship it! You just created your own photo-sharing app.

Now go forth and clone

By now, you hopefully have a locally hosted UWP running against your own Azure App Service and are ready to start turning this thing into the next Instagram. You also (hopefully) now better understand how easy it is to wire up a rich UWP to an Azure App Service. If you have questions about the code sample (https://github.com/Microsoft/Appsample-Photosharing), submit comments below. The team is here to help.

With this app, users can earn virtual gold by uploading and sharing photos with people from all around the world. They can upload photos of their cats, shoes, houses, or last vacations, and see how they compete against other users. Are their photos a great gold source? Are they among the most generous contributors? They can find out on the app's leaderboard.

The goal of this app is to provide a complete, end-to-end example of a real-world app that uses a variety of UWP features, and exhibits design and development best practices. This makes it a great source of code you can copy into your own apps. It also provides an example of what a real-world app architecture might look like. The decoupled architecture makes it easy to reuse code or to make changes and build your own photo sharing app, which you can then publish in the Windows Store.

Technical deep dive

The PhotoSharingApp solution consists of two projects for the client app (PhotoSharingApp.Universal and PhotoSharingApp.Universal.Tests) and three projects for the service (PhotoSharingApp.MobileService, PhotoSharingApp.MobileService.Shared, and PhotoSharingApp.MobileService.Tests). Both client and service implementations make use of a portable library which contains interfaces and shared data models for communication.

The app and service are separated in the project structure as shown in this diagram:

You can run the UWP app with a dummy service. This allows you to explore some basic features of the app without the need to set up the Azure service.

You can set up your own Azure App Service, which will be your app backend for storing and retrieving real data.

Pre-requisites

Visual Studio 2015 with Universal Windows App Development Tools and Web Developer Tools installed. Also ensure that you have the latest updates.

...

Launching the app with the dummy service

The dummy service is a service implementation that loads static data into the app for exploring and testing purposes.

In Visual Studio, make sure to have Debug mode enabled. By default, PhotoSharingApp.Universal is the StartUp project, so you can Start Debugging (F5) or Start Without Debugging (Ctrl+F5) to explore the app connected to the dummy service.

Note : When you first load the solution, you may run into numerous warnings and errors in the Error List. This is because the NuGet packages are not downloaded and dependencies are not yet built. First Clean the solution and then Build it to get rid of all those errors.

Setting up the Azure backend service

Design Goals

PhotoSharingApp has an architecture that reflects best practices for larger app projects. The following are high-level architectural goals:

Flexibility: Easy-to-maintain code, allowing components to be easily updated as new capabilities are developed and integrated

Extensibility: Allowing parts of the app to be easily added or replaced with alternative implementations

Quality: Allowing services and components to be tested

In order to achieve the above goals, these are the more detailed key design principles:

The Open/Closed Principle (OCP) - The OCP states that "software entities (classes, modules, functions, and so on) should be open for extension, but closed for modification" (Meyer, Bertrand (1988))

Separation of concerns (SoC) - The code is divided into distinct features with as little overlap in functionality as possible

Single Responsibility Principle (SRP) - Each code component should be responsible only for a specific feature or functionality.

Dependency Inversion Principle (DIP) - This principle states that software modules should not depend on concretions, but on abstractions. In this sample code, interfaces (such as ICameraEngine, IPhotoService) are being used to hide a specific implementation in order to reduce coupling.

Don't Repeat Yourself (DRY) - Specific functionality should be implemented in only one place, not duplicated across multiple components. A good example in PhotoSharingApp would be the process of making sure that the user is signed in for actions such as uploading photos or posting comments. Doing this check and offering a way to sign in should not be duplicated across the app although it is being used in different places. Therefore, the class PhotoSharingApp.Universal.Services.AuthEnforcementHandler which implements IAuthEnforcementHandler.cs takes care of that by offering the method Task CheckUserAuthentication();.