March 17, 2016 10:30 am

UWP, Azure App Services, and DocumentDB Soup: A photo-sharing app

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.

1_snapgold

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.

Why DocumentDB?

Originally this code sample leveraged a SQL Server database to store the relational data for SnapGold. We moved the data layer to DocumentDB for a few reasons.

  1. DocumentDB has some awesome querying power considering all fields on your data models are indexed.
  2. So many apps use SQL and most developers are familiar with the nuances of setting it up. Here we tried something different. DocumentDB is relatively new and offers different bring-up steps.
  3. This is a code sample, and bring up for DocumentDB is much faster than bringing a new SQL Server database online. In our sample, just create a new DocumentDB in Azure, set two configs, and it creates itself when you deploy to Azure. #forthewin

We found that some queries in DocumentDB were straightforward and could be accomplished with simple Lambda queries against the collections. Here we get all the photo documents for a single user of the app for their profile page:

Conversely, some were more complicated and required some DocumentDB stored procedures. In this case, get the top 20 photos from the 20 categories most recently updated with new photos. DocumentDB uses JavaScript as their equivalent for TSQL as you will see in our code below. (More details on that are here.)

For our code sample, DocumentDB “sprocs” are stored in the Mobile App Service as Javascript files. See below:

2_getrecentphotos

The code for the highlighted DocumentDB sproc (getRecentPhotosForCategoriesStoredProcedure.js) is below so you can see the syntax we use for DocumentDB sprocs.

When you deploy the service, most of the magic to provision our DocumentDB happens in DocumentDBRepository.cs.

We deploy these .js files automatically when you deploy the Azure App Service in the SnapGold code sample.

First we create the database:

Then we deploy the sprocs:

DocumentDB is much easier to self-provision in your code than a SQL Server database. This code looks for the existence of the specified DocumentDB, and if missing, sets itself up.

How easily can I port this to my own app?

3_sportspictures

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.

  1. Get code from GitHub.
  2. 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.
  3. Create a free (for 1 month) Azure subscription to host the service, DocumentDB, and Blob Storage.
  4. Follow the Getting Started guide to get your own App Service hosted in Azure.
  5. 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.
  6. Change the default colors from Gold to whatever you want. We chose Blues for SportsPics:
  1. Add a logo. I created one in PhotoShop and simply added it to the header control in the PageHeader.xaml
  1. Update the app name in package.appxmanifest.
  2. 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.

Happy Windows Store coding!

Written by Eric Langland, Senior Software Engineering Lead for Universal Store

Updated April 7, 2016 11:02 am

Join the conversation

  1. Sorry but I’d simply refuse to use any database which doesn’t support paging and aggregation, for anything serious .

    • Hey Onur – I work on the Azure DocumentDB team. While we offer some paging functionality – we recognize that paging and aggregation are valid pain points which we seek to address.

      That said, I’ll point out that there are many notable advantages in using DocumentDB including automatic indexing over flexible schemas and the ability to support an extremely high-rate of ingestion at extremely low latencies.

      We’re living in a database renaissance, with some pretty cool technology arriving in all sorts of new database paradigms. I encourage you to always consider the trade-offs you make and pick the right tools for the right job (this is what engineering is all about 🙂 ).

  2. I’m catching a UriFormatException in DocumentDbRepository.cs, line 84. I’m trying to run it “out of the box” using the dummy service. Suggestions?

    • Stephen,
      I’m guessing your running it in release mode. It’s looking for an Azure service url. Try debug mode which defaults to the dummy service.

      Let me know if that works for you.

      /Eric

      • No, I have the active solution configuration set to Debug. I have not made any changes to the code as it came from GitHub.

        • Sounds to me like you might need to set the PhotoSharingApp.Universal as your startup project. Does that change anything?

          • That fixed it. The solution’s property page showed that the startup project was set to PhotoSharingApp.AppService. When I changed the startup project, VS tried to deploy to Local Machine which failed for some reason that I haven’t investigated. But when I changed the deployment target to one of the mobile emulators, the deployment completed and the app launched. Thanks.

  3. Thanks for this sample app, guys! However, I must say that even with all cool functionality of DocumentDB it will be difficult to use it in real complex back-ends without ORM (ODM) support. Its nice you’ve used some DDD patterns in the app like Repository, but it looks like one from the data-driven design era, where abstraction from DAL was weak. There is no Unit Of Work, no change tracking. The business code must be aware of the need to push the model back to storage (update) after modifying it. Even more, when you work with an object model, you don’t know if the state has changed after calling some methods, and you don’t have to. Its the repository’s work to track changes in the model and persist them. Not to say that replacing the whole document to update one field is quite inefficient.
    So it would be very, very cool if you implemented a provider for, say, EF7. You would also have another win – it would be much easier to migrate EF+SQL-based repositories to DocumentDB. Currently, the only option is to write a new repository implementation from scratch (with changing its interface and dependent architecture to support explicit updates).

    • Thanks for the feedback! Some of the original intentions behind the document-oriented database paradigm include removing the *need* for ORMs and other duct tapes, in which you can serialize + de-serialize an evolving data model directly as JSON records.

      That said, I can see how integrating with existing ORM and ODM solutions would yield benefits…. and at the end of the day – we’d love to make DocumentDB available in the ecosystem of tools you love to use.

      Can you help vote on this feature our feedback forums? This helps us prioritize our backlog:
      https://feedback.azure.com/forums/263030-documentdb/suggestions/12505899-add-provider-for-entity-framework-7

      • Hi,
        that’s actually me who posted that user voice 🙂

        Let me add. The idea of direct serializing a data model to a document works nice, but in the same way as with relational DBs common approach it implies less abstract architectures, primarily oriented on performance (when transferring whole documents is ok since there are fewer transformations). For example, its common to implement a web server directly inside MongoDB, and to have the documents in the DB to be the model. With RDMS I saw many times business code spread among stored procedures, and having controllers just calling these SPs and transforming the results to some view. Such performance-centric approaches are completely acceptable in some areas, but I doubt its the what will lead DocumentDB to success being chosen as primary usage scenario. It’d be nice to see some statistics of DocumentDB usage depending on architectural style and design.

        On the other side, I worked on an IoT Mongo-based project (founded by an ex-Microsoftie) with high load, and most updates to Mongo were done only to particular fields, not whole documents – meaning that was important for performance.

        Lets be honest: the world has MongoDB, there is lots of information on it, and while it lacks many cool features DocumentDB has (managed service – for me), it remains almost default choice for most developers. Without some killing feature like EF support DocumentDB adoption will be relatively slow IMHO.

  4. Hi,
    This is a great app but it’s an awful lot to take in. Do you have any documentation to go with the app? Anything to help you understand where to start. While I’ve gone through all the projects and most of the files, I still feel it’s like looking for a needle in a haystack, especially if you’re not familiar with the likes of Azure and DocumentDB. Thanks.

  5. I am looking for a Azure SQL solution. You mentioned: “So many apps use SQL and most developers are framiliar with the nuances of setting it up. Here we tried something different.”

    Could you please redirect me to the example apps that use Azure SQL.
    Thanks, Steven K James

    • Hi Steven,
      When we started building this code sample, we actually created a SQL project as the back end. It conforms to the same data layer / interfaces as the DocumentDB version so getting it incorporated should be pretty easy. If you really want this I could post this code in a zip folder somewhere. Let me know if you really want it.
      Cheers
      /Eric

      • Hi Eric,

        I’m also interested in the SQL version. If you could upload a ZIP that would be great.

        Many thanks.

      • I also would like a copy of the SQL Server version. Can you give me a link or zip copy? Thanks. – BG

  6. Wow this is super-super cool! Now you can make your Photos apps more practical by adding an Import function so users can pull pictures from their devices in one click: check out Windows.Media.Import in the Windows 10 SDK, and the missing user guide is on CodeProject: http://j.mp/Windows-Media-Import

  7. Hi all,

    This app looks great, but I agree with the feedback of user Thierry Fierens: it’s a lot to take in. I no longer buy C# books. What you find in there is just all basic stuff. Barely in depth knowledge to use in real business apps. Also most of the examples in those books are also too basic and not usable for real work. That being said, this app is very much usable, but the problem is, it’s very hard to understand. Esp. code flow and lot’s of code and statements I didn’t even know it existed. Is this the place to ask questions about it or should I ask on the MSDN forum (where I already posted a question prior to finding this blog).

    The problem I have now, I cannot find where the Snapgold main page is loaded. According to the ProjectOverview.md file on GitHub, the app entry point is located in the App.xaml.cs which I expected to be like that. However, when I put breakpoints in that file, the SnapGold mainpage is always loaded first, even before entering the main method. So I was wondering when that SnapGold page is loaded first? Even between the xaml files, I can’t locate that Gold file. Really puzzled…

    Many thanks in advance, Steve Declerck

    • Hi Steve, Thanks for your feedback. The entry point for the regular app launch is in App.xaml.cs as you described. If you put a break point in the OnLaunched method, you will notice that based on if this is the first launch, facade.NavigateToWelcomeView() will be called or for any subsequent launch facade.NavigateToCategoriesView() is being used to navigate to the categories page. NavigationFacade.cs will then do the actual navigation on the current frame via _frame.Navigate(…). This code example encapsulates navigation code into the NavigationFacade.cs since there are a couple of pages that can accept different sets of parameters, so that by defining strongly typed navigation methods, input arguments for pages get more obvious and robust against changes. Let me know if that helps. Cheers, Andy

      • Hi Andy,

        I’m sorry, just saw your answer now. I didn’t expect answer, because I know everybody is busy most of the time. So thanks a lot for the reply and your explanation. I was busy a few hours again this evening. Little by little I’m getting a bit further. Are you the author of the app? Great work! I still have a few questions but I don’t know if it’s fine to ask here or is there a better place?

        I can see where the sidebar menu captions are set, but I can’t find anything about the images on the left. Where they are loaded ? Is the project working on a tablet and a windows phone ?

        Many thanks in advance !
        Best regards, Steve

  8. I have followed the configuration procedure for enabling notifications, but I’m not sure it’s exactly right – sometimes it works when I give gold, sometimes not. It’s probably a confusion on my part about how it is supposed to work. What does the user need to do to generate the toast notification reliably?

    • Answering my question:
      1. I had to install the sample app from the Windows Store (my private store copy) to get the notifications to work properly. They work reliably after installing from the store.
      2. To test, set up authentication with two different providers and set up the app on two different computers. Log in to a different provider on each computer. Send gold from one user to the other.

  9. This sample provides a nice UWP Windows mobile app. Say someone wanted to add support for a browser-based web app. What technology stack would MSFT recommend implementing that app on?

    • To clarify my question: say I wanted to develop a web app that would serve as a simplified peer of this sample’s UWP app, PhotoSharingApp.Universal, communicating with the PhotoSharing App Service side. What web app technology stacks would work well with and complement the PhotoSharing app technologies?