Design and implement Azure PaaS compute and web and mobile services
- 4/7/2018
- Skill 4.1: Design Azure App Service Web Apps
- Skill 4.2: Design Azure App Service API Apps
- Skill 4.3: Develop Azure App Service Logic Apps
- Skill 4.4: Develop Azure App Service Mobile Apps
- Skill 4.5: Implement API Management
- Skill 4.6: Implement Azure Functions and WebJobs
- Skill 4.7: Design and Implement Azure Service Fabric apps
- Skill 4.8: Design and implement third-party Platform as a Service (PaaS)
- Skill 4.9: Design and implement DevOps
- Thought experiment
- Thought experiment answers
- Chapter summary
Skill 4.4: Develop Azure App Service Mobile Apps
Mobile Apps in Azure App Service provides a platform for the development of mobile applications, providing a combination of back-end Azure hosted services with device side development frameworks that streamline the integration of the back-end services.
Mobile Apps enables the development of applications across a variety of platforms, targeting native iOS, Android, and Windows apps, cross-platform Xamarin (Android, Forms and iOS) and Cordova. Mobile Apps includes a comprehensive set of open source SDKs for each of the aforementioned platforms, and together with the services provided in Azure provide functionality for:
Authentication and authorization Enables integration with identity providers including Azure Active Directory, Facebook, Google, Twitter, and Microsoft Account.
Data access Enables access to tabular data stored in an Azure SQL Database or an on-premises SQL Server (via a hybrid connection) via an automatically provisioned and mobile-friendly OData v3 data source.
Offline sync Enables reads as well as create, update, and delete activity to happen against the supporting tables even when the device is not connected to a network, and coordinates the synchronization of data between local and cloud stores as dictated by the application logic (e.g., network connectivity is detected or the user presses a “Sync” button).
Push notifications Enables the sending of push notifications to app users via Azure Notifications Hubs, which in turn supports the sending of notifications across the most popular push notifications services for Apple (APNS), Google (GCM), Windows (WNS), Windows Phone (MPNS), Amazon (ADM) and Baidu (Android China) devices.
Create a mobile app
From a high level, the process for creating a mobile app is as follows:
Identify the target device platforms you want your app to target.
Prepare your development environment.
Deploy an Azure Mobile App Service instance.
Configure the Azure Mobile App Service.
Configure your client application.
Augment your project with authentication/authorization, offline data sync, or push notification capabilities.
The sections that follow cover each of these steps in greater detail.
Identify the target device platforms
The first decision you make when creating an mobile app is choosing which device platforms to support. For device platforms, you can choose from the set that includes native Android, Cordova, native iOS (Objective-C or Swift), Windows (C#), Xamarin Android, Xamarin Forms and Xamarin iOS.
Because each device platform brings with it a set of requirements, it can make getting started an almost overwhelming setup experience. One way to approach this is to start with one device platform so that you can complete the end-to-end process, and then layer on additional platforms after you have laid the foundation for one platform. Additionally, if you choose to use Xamarin or Cordova as your starting platform you gain the advantage that these platforms can themselves target multiple device platforms, allowing you to write portable code libraries once that is shared by projects that are specific to each target device.
Prepare your development environment
The requirements for your development environment vary depending on the device platforms you wish to target. The pre-requisites here include the supported operating system (e.g., macOS, Windows), the integrated development environment (e.g., Android Studio, Visual Studio for Windows, Visual Studio for Mac or Xcode) and the devices (e.g., the emulators/simulators or physical devices used for testing your app from the development environment of your choice).
Table 4-4 summarizes key requirements by device platform.
TABLE 4-4 Requirements for each target platform
Target Platform |
Requirements |
Android |
OS: macOS or Windows IDE: Android Studio Devices: Android emulator and devices |
Cordova |
OS: macOS and Windows IDE: Visual Studio for Windows Devices: Android, iOS*, Windows emulators and devices. |
iOS |
OS: macOS IDE: Xcode Devices: iOS simulator and devices |
Windows |
OS: Windows IDE: Visual Studio for Windows Devices: Windows desktop and phone |
Xamarin.Android |
OS: macOS or Windows IDE: Visual Studio for mac or Windows Devices: Android emulators and devices. |
Xamarin.Forms |
OS: macOS and Windows IDE: Visual Studio for mac or Windows Devices: Android, iOS*, Windows emulators and devices. |
Xamarin.iOS |
OS: macOS IDE: Visual Studio for mac or Windows Devices: iOS* simulator and devices |
Deploy an Azure Mobile App Service
With the aforementioned decisions in place, you are now ready to deploy an Azure Mobile App Service instance to provide the backend services to your app. Follow these steps:
In the Azure Portal, select New, and search for Mobile App, and select the Mobile App entry.
Select Create.
Provide a unique name for your Mobile App.
Select an Azure subscription and Resource Group.
Select an existing App Service Plan or create a new one.
Select Create to deploy the mobile app.
Configure the mobile app
Once you have deployed your mobile app, you need to configure where it will store its tabular data and the language (your options are C# or Node.js) in which the backend APIs are implemented (which affects the programming language you use when customizing the backend behavior). The following steps walk you through preparing the quick start solution, which you can use as a starting point for your mobile app. Follow these steps:
In the Azure Portal, navigate to the blade for your mobile app.
From the menu, under the Deployment heading, select Quick Start.
On the General listing, select the platform you wish to target first.
On the Quick Start blade, select the button underneath the header 1 Connect a database that reads You Will Need A Database In Order To Complete This Quickstart. Click Here To Create One.”
On the Data Connections blade, select + Add.
On the Add Data Connection blade, leave the Type drop-down at SQL Database.
Select SQL Database - Configure Required Settings.
On the Database blade, select an existing Azure SQL Database, or create a new database (and optionally a new SQL Database Server).
Back on the Add Data Connection blade, select Connection String.
Provide the name to use for referring to this connection string in configuration.
Select OK.
Select OK once more to add the data connection (and create the SQL Database if so configured).
In a few minutes (when creating a new SQL Database), the new entry appears in the Data Connections blade. When it does, close the Data Connections blade.
On the Quick Start blade, underneath the header, Create A Table API, choose Node.js and select the check box I Acknowledge That This Will Overwrite All Site Contents. Then select the Create TodoItem table button that is enabled. If you choose to use C#, note that you will have to download the zip provided, extract it, open it in Visual Studio, compile and then publish the App Service to your Mobile App instance. This is performed in the same way as you deploy Web Apps as described previously.
Leave the Quick Start blade open and continue to the next section.
Configure your client application
Now that you have a basic mobile app backend deployed, you are now ready to create the application that will run on your targeted devices. You can create a new application from a generated quick start project or by connecting an existing application:
From the Quick Start blade of your mobile app, underneath the header, Configure Your Client Application, set the toggle to create A New App If You Want To Create A Solution or Connect An Existing App If You Already Have A Solution Built and just need to connect it to the mobile app.
If you select Create A New App, you will be provided with instructions specific to the device platform you selected previously as well as a download link from which you can download a generated solution that includes the code customized for access to the deployed mobile app backend. For example, if you selected Xamarin.Forms as your platform, you are provided with a zip file that contains a personalized project that you can open in Visual Studio for Windows or Visual Studio for macOS, which has been pre-configured to connect to your mobile app backend.
If you select Connect An Existing App, you are provided with instructions and code you can copy and paste into your project to connect it to the mobile app backend.
Once you have completed the steps for either option, you can open and run the project in the IDE and start working against your mobile app backend.
Add authentication to a mobile app
Once you have your project in place and connected to your mobile app backend, you can enable authentication and authorization. Recall that this enables integration with identity providers including Azure Active Directory, Facebook, Google, Twitter and Microsoft Account such that your app users need to sign in using credentials from one of these providers. To do so, follow these steps.
Identify the set of identity providers you want to support.
For each identity provider, you need to follow the provider’s specific instructions to register your app and retrieve the credentials needed to authenticate using that provider. The up-to-date instructions for each provider are available:
Configure authentication / authorization in your mobile app.
Navigate to the blade of your mobile app in the Azure Portal.
From the menu, under the Settings header, select Authentication / Authorization.
Under the Allowed External Redirect URLs header, in the text box provide a callback URL that will be used to invoke your application. It should be of the form [scheme]://easyauth.callback where the value of [scheme] is a string you specify that starts with a letter and consists of only letters and numbers. For example, myapp://easyauth.callback.
Select Save from the command bar.
Restrict permissions to authenticated users on the service side. The approach you take varies depending on how you configured your backend language and if you have deployed custom backend code.
If you are using the Node.js backend created through the quick start in the Azure Portal, you can control access to data on a table-by-table basis. From your Mobile App blade, in the menu select Easy Tables, and then select the table you want to secure. For all of the permission options, set the value to Authenticated Access Only and select Save.
If you deployed a C# backend, in the controller for your project that inherits from TableController, decorate the class with the Authorize attribute. For example:
[Authorize] public class TodoItemController : TableController<TodoItem>
If you have deployed a customized Node.js backend, you need to modify the code accessing the table and set the access property to authenticated. For example:
table.access = 'authenticated';
Add the authentication logic to your app project. The specific steps to take vary based upon the target platform for your app, but in general they amount adding user interface elements to initiate sign-in and handling the authentication events. An important step in the configuration of the authentication is providing the value of your scheme you defined for the Allowed External Redirects URL (e.g., myapp).
Run your application in your local simulator or device to verify the authentication flow.
Add offline sync to a mobile app
The offline data sync capability comes from a mix of client-side SDK and service-side features. This capability enables reads as well as create, update and delete activity to happen against the supporting tables even when the device is not connected to a network, and coordinates the synchronization of data between local and cloud stores as dictated by the application logic (e.g., network connectivity is detected or the user presses a “Sync” button). The feature includes support for conflict detection when the same record is changed on both the client and the backend, and it allows for the conflicts to be resolved on either the client side or service side.
On the Mobile App service side, you need a table that leverages Mobile App easy tables. This is typically a table in SQL Database that is exposed by Mobile Apps using the OData endpoint. Easy tables can be managed in the Mobile App blade in the portal, including adjusting their schema, setting permissions, and modifying the service side script (for Node.js backends) that processes the create, read, update, delete (CRUD) operations.
On the client side, the Azure Mobile App SDKs provide an interface referred to as a SyncTable that wraps access to the remote easy table. When using a SyncTable all the CRUD operations work from a local store, whose implementation is device platform specific. The local store provides the data persistence capability on the client device. In iOS the local store is based on Core Data, and for Windows, Xamarin, and Android the local store is based on SQL lite.
Changes to the data are made through a sync context object that tracks the changes that are made across all of the tables. This sync context maintains an operation queue that is an ordered list of create, update and delete operations that have been performed against the data locally.
To modify the backend table data with the changes performed against the local store, you have to perform a push. To populate the local store with data from the backend, you have to perform a pull. A push operation executes a series of REST calls to your mobile app backend that applies all the CUD changes since the last push. It’s important to note that when you push changes, you are always pushing a set containing at least one operation; you are not pushing a specific table. This restriction ensures that multiple operations against the context that may span across multiple tables are replayed against the backend table in the correct order.
There is a notion of an implicit push; this occurs when you execute a pull operation but have pending operations to push. In this case, the pull will first execute a push against the sync context.
Offline sync supports incremental sync, whereby each time you pull records from the source only the source records that are new or have changed are retrieved (as opposed to downloading the entire table worth of data every time). You can clear the contents of the local store by performing a purge.
You can enable Offline Sync by following these high-level steps:
Modify the client code that accesses your easy tables to use objects of the SyncTable variety.
Implement a method that is run when your application first launches that defines the table schema and initializes the local store with data from the remote table.
Implement a method that launches initiate sync operation. This could be triggered from a button or refresh gesture.
You can test the offline behavior of your app by:
Running the application once as normal and adding data to your table.
Modifying the application’s configuration so that it no longer points to the correct URI of your mobile app backend.
Run the application again. This time the offline behavior should take affect. Make some modifications to the data.
Restore the application’s configuration.
Run the application again and verify that the changes you made while offline appear in your easy table. To do this, navigate to the blade of your mobile app, select Easy Tables from the menu, and then select your table to view its contents.
Add push notifications to a mobile app
Push notifications enable you to send app-specific messages to your app running across a variety of platforms. In Azure Mobile Apps, push notification capabilities are provided by Azure Notification Hubs, which is accessed using the Mobile Apps SDKs for the platform of choice. Notification Hubs, in turn, abstract your application from the complexities of dealing with the various push notification systems (PNS) that are specific to each platform, which includes challenges like device registration with the PNS, backend services to send messages to the PNS, and provides for routing of messages to targeted users or groups of users (which requires maintaining a mapping of users to devices), and scaling to support such functions across a huge base of devices. Notifications Hubs supports the sending of notifications across the most popular push notifications services for Apple (APNS), Google (GCM), Windows (WNS), Windows Phone (MPNS), Amazon (ADM), and Baidu (Android China) devices.
To add push notifications, follow these steps:
Deploy a Notification Hub with your mobile app.
Navigate to the blade of your mobile app, and on the menu under the Settings heading, select Push.
From the Command bar, select Connect.
On the Notification Hub blade, choose an existing Notification Hub or provision a new one. If you choose to provision a new Notification Hub, provide a name for the hub, a name for the new namespace, and select the desired pricing tier, and then select OK.
Select the link Configure Push Notification Services.
On the Push Notification Services blade, select the PNS to which you want to connect the Notification Hub.
On the blade for the PNS, enter the PNS specific configuration, and select Save.
Configure your backend server project to send push notifications.
Modify the app project to respond to push notifications.