Page 10 - MSDN Magazine, March 2018

Data Points JULIE LERMAN
Calling Azure Functions from the Universal Windows Platform
This is the final installment of my series on building a Universal Windows Platform (UWP) app that stores data locally and in the cloud. In the first installment, I built the UWP CookieBinge game, which uses Entity Framework Core 2 (EF Core 2) to store game scores onto the device on which the game is being played. In the next two installments, I showed you how to build Azure Functions in the cloud to store the game scores to and retrieve them from a Microsoft Azure Cosmos DB database. Finally, in this column, you’ll see how to make requests from the UWP app to those Azure Functions to send scores, as well as receive and display top scores for the player across all of her devices in addition to top scores for all players around the globe.
This solution also enables users to
register in the cloud and tie any of their
devices to that registration. While I’ll
leverage that registration information
to send and retrieve scores from the
Azure Functions, I won’t be describing
that part of the application. However,
you can see that code in the download,
including code for the new Azure Functions I created for registration.
Where We Left Off
A little refresher will help reacquaint you with the UWP app and the Azure Functions I’ll be connecting.
In the CookieBinge game, when a user completes a binge, they have two buttons to choose from to tell the app that they’re done. One is the “Worth it” button to indicate that they’re finished and are happy about all the cookies they scarfed down. The other is the “Not worth it” button. In response to these click events, the logic leads to the BingeServices.RecordBinge method, which uses EF Core 2 to store the data to the local database.
The app also has a feature that dis­ plays the top five scores from the local database.
There are three Azure Functions that I built in my last few columns. The first receives the game score, along with the player’s UserId (assigned by the regis­ tration feature) and the name of the device on which the game was played. The function then stores this data into the Cosmos DB database. The other two functions respond to requests for data from the Cosmos DB database. One receives the player’s UserId and returns their top five scores sent from all of the devices on which they play. The other simply returns the top five scores stored in the database regard­ less of the player.
So now the task is to integrate the Azure Functions into the game. First, at the time the game score is stored into the local database, the app should also send the score and other relevant data to the StoreScore function. Second, at the time the app reads the score histo­ ry from the local database, it should also send requests to the functions
that return the scores and display the results of those requests, as shown in Figure 1.
Communicating with the Web from the UWP
The UWP framework uses a special set of APIs for making Web requests and receiving responses. In fact, there are two namespaces to choose from and I recommend reading the MSDN blog post: “Demystifying HttpClient APIs in the Universal Windows Platform” at bit.ly/2rxZu3f. I’ll be working with the APIs from the Windows.Web.Http namespace. These APIs have a very specific requirement for how data is sent along with any requests, and that means a little extra effort. For cases where I need to send some JSON along with my request, I’ve leveraged a helper class, HttpJsonContent, that will combine the JSON content together with the header content and perform some additional logic.
Figure 1 Scores from the Azure Cosmos DB Database Retrieved from Azure Functions
Code download available at msdn.com/magazine/0318magcode.
6 msdn magazine