Real-Time Communication to Xamarin App via SignalR and Azure API App Services

There are times where your website or mobile app would like to show live data, such as scores in real-time. And I don’t mean hitting an api on a timer but to populate with a new set of data auto-magically. This repo consists of an API and a few demo projects that make that happen. Using .NET Web API and Signal R.

Architecture

cloudconstruct-pba-diag

We will have an “internal system” that is recording the scores it can be any system, even just a DB. In our example I have created a web form that we can enter data in to simulate this.

We will then post those scores to an endpoint that is hosted on Azure API App Services built on a ASP.NET Web API Framework. We can add authentication and even scaling if needed to our App Service when needed. For now it is open.

Next we have our clients, they will connect using the SignalR Client API to connect to a SignalR Hub out on our API App Service. SignalR will push out any messages based on data that is coming in.

Usage

LiveScoringAPI

This is the API app that will take a “post” of scores and process them out to all of the connected clients via SignalR.

Startup.cs – currently there is an option configured for CORS to be enabled. This is needed for access to the Web.

Controllers/API/PlayerScoreController.cs – Endpoint to post scores to. Currently there is no authentication. That needs to be added still. There are 2 endpoints /GET and /POST /GET is a test method to generate random scores in the Player model. This can be removed. /POST is the main method. It is expecting a Player object and instantiates the PlayerScoreTickerHub to “update scores”

PlayerScoreTickerHub.cs – this is the SignalR hub clients will connect to. It also has a few exposed methods. The main one, for Website client script is GetAllScores. This happens at init(). I did not add that to the Mobile demos yet.

PlayerScoreTicker.cs – main file for updating scores. Currently the player object is a concurrent dictionary that just keeps getting updated with a score. This most likely will need to change at some point either time based or upon another call to clear out scores. There are also some test methods in there as well. BroadcastPlayerScores calls a method for all connected clients.

Models/PlayerScore.cs – sample player score model

FYI – Swagger is enabled as well http://webapi-url/swagger

LiveScoringWeb

This project serves 2 purposes

  1. Form to post to the API – http://website-url/demo/record
  2. Demo page to show the scoring updates in realtime – http://website-url/demo/scores

/Controller/DemoController.cs – When a user records a score it will post using the APIClient for the LiveScoringAPI

*/Scripts/PlayerTicker.js *- this is the JS on the demo score page that “gets” the data on init and then has a JS function that is called by the hub to update the scores in realtime.

LiveScoringMobile

This is a Xamarin project. Contains shared code and 3 others (iOS, Droid and WinPhone). iOS is not complete.

LiveScoringMobile has some shared code – a Player Model and a Signal R Client. You may have to update the domain name and player hub accordingly.

LiveScoringMobile.WinPhone – has an example of displaying scores. App.xaml.cs has the R Client connecting OnLaunched. MainPage.xaml.cs has a method when data is received from the hub it will use a dispatcher to update the UI

LiveScoringMobile.Droid – has an example of displaying scores. Similar to WinPhone, MainActivity kicks off the R Client and has a listener for data that is recieved. It will process the data with RunOnUiThread for real time updating.

LiveScoringMobile.iOS – not implemented but will follow same pattern

Working Demo http://livescoringwebapp.azurewebsites.net/

GitHub Repo https://github.com/jdruid/LiveScoringAPI-SignalR

Bits and Bytes: Migration of Azure Mobile Services to Azure App Services

For the past year Azure Mobile Services has come a long way. From adding easy access to making custom API’s and table scripts to combining push notifications and identity management. However, this past December Mobile Services has a new name, App Services. App Services now contains, Web Apps, Mobile Apps, Logic Apps and API Apps. With App service you get the following benefits:

  • Easily connect your app to data in the cloud or on-premises, including SQL Azure, SQL on-premises, Mongo, Azure Table Storage, SaaS APIs like Dynamics and Salesforce.
  • Enable your app to work with data offline and sync with above mentioned data sources
  • Build mobile backend APIs in seconds without writing any code
  • Intuitive SDKs for iOS, Android, Windows, as well as cross-platform frameworks like Xamarin, and Cordova
  • Extend your mobile backend with custom code by leveraging App Service Mobile .NET or Node.js server side SDK, or directly via REST frameworks for other languages supported on App Service including PHP, Java, or Python
  • Cross-platform push notifications to iOS, Android, Windows, Kindle and other devices (this capability is also available as a separate service: Notification Hubs)
  • Authenticate and Authorize your users without adding any backend code using App Service Authentication/Authorization features
  • AND MORE!

You are probably saying “that is great, but what does this have to with Azure Mobile Services”. Well it is because you want to use the new App Service model for your development. If you are starting a new project, clicking through and building a service using App Service is easy and straightforward. Here is a video that shows how to get up and running in no time.

However, what if you have invested your time and effort into Azure Mobile Services? How can it benefit from all of these awesome features? Well, it starts with Migrating to Azure App Services! You might say that migrating has always be a pain or even black magic. In some instances it has. However, with the Migration Tool for Mobile Services it makes it pretty easy and straight forward.

A few things to note before you attempt to migrate.

  • If you “MIGRATE” your site, there will be no code changes needed to your scripts.
  • If you “UPGRADE” your site, you will have to make code changes to your scripts to take advantage of the new mobile SDK.

In this post we are going to talk about MIGRATION.

The next thing to note is what tier you are on with your current Mobile Services and how many do you have. If you are on Free or Basic and have multiple mobile services, all of them will be migrated. If you only want one migrated you will have to “upgrade” to the standard tier. Here are the steps to do that.

  1. Log onto the Azure Classic Portal.
  2. Select your Mobile Service.
  3. Select the SCALE UP tab.
  4. Under Mobile Service Tier, click on the STANDARD tier. Click on the SAVE icon at the bottom of the page.

Remember to set the pricing tier to an appropriate setting after migration.

Here is a Bits and Bytes video on how to migrate your Azure Mobile Services over to Mobile App Services.
bitsbytesmigrateappservice

How to Migrate Your Mobile Service

  1. Log onto the Azure Classic Portal.
  2. Select your Mobile Service.
  3. Click on the Migrate to App Service button.The Migrate Button
  4. Read the Migrate to App Service dialog.
  5. Enter the name of your Mobile Service in the box provided. For example, if your domain name is contoso.azure-mobile.net, then enter contoso in the box provided.
  6. Click on the tick button.

 

Once done, head on over to the Azure Portal and view your new Mobile App Service!