Sometimes when getting started with a new tech or service, it helps if you can get a complete end-to-end working example, of course with source.
Today's project is one such project, which you can (and I did) get a local version running in 5 minutes...
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.
What is SnapGold?
All the code can be found on our GitHub page here.
The app highlights best practices in the following areas, which you can use to model your own app:
- UWP optimized for desktop & mobile
- MVVM with responsive layout
- Azure App Service
- Azure DocumentDB & Blob storage back end
- Azure App Service Authentication (w/Facebook/Twitter/Google/Microsoft account)
- Authenticated push notifications
- Instrumented with Visual Studio Application Insights (client and server)In-App-Purchase Enabled
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.
Here’s what you’ll need to get your own app started.
- Get code from GitHub.
- 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.
- Create a free (for 1 month) Azure subscription to host the service, DocumentDB, and Blob Storage.
- 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.
PhotoSharingApp is a Universal Windows Platform (UWP) app sample that demonstrates real-world social media experiences around photo sharing.
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.
The app allows users to:
- Browse photo categories and navigate into photo collections and photo details.
- Take and upload photos directly in the app or upload an existing photo.
- Give gold and add comments to photos uploaded by other users.
- Receive push notifications when users are given gold for uploaded photos.
- Explore a leaderboard of users with the most gold, users that have given the most gold to other photos, and the photos that have received the most gold.
- Sign in with a Microsoft, Facebook, Google, or Twitter account.
- Report content as abusive, inappropriate, or spam.
- Buy virtual gold using in-app purchase.
PhotoSharingApp demonstrates the following features:
In-app purchase (see the Windows.ApplicationModel.Store namespace):
Separation between user interface, business logic and data models (MVVM):
Extensibility and flexibility using the Unity dependency container:
How to connect your app to an Azure App Service
Real-world service implementation for storing uploaded photos using Azure DocumentDB
Sign-in with Azure Mobile Apps:
Usage analysis with Visual Studio Application Insights
Running the sample
For instructions on setting up the sample, see Getting Started.
For an overview of the projects structure and namespaces, see Project overview.
Technical deep dive
For an explanation of how the sample integrates multiple technologies, see 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:
There are two ways to explore the PhotoSharingApp sample:
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.
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
- MVVM design pattern
- Design ViewModels
- Dependency Injection & Registries
- Navigation bar
- Service communication
- In-app purchase
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();.
More details about the above design principles can be found here.
That should be more than enough to keep you busy for a couple days... :)
Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.