How to create apps that work together across Windows, iOS, and Android

Project Rome SDKs arrive for iOS and Android, so your apps can now take advantage of Microsoft’s cross-platform technologies

Microsoft may not have a mobile OS any more, but that doesn’t mean it’s abandoned the mobile market. Instead it’s taking a different approach: building on its platform to integrate Windows and Microsoft 365 with the devices we’re all using. That has meant a refocus on its own tools, with iOS and Android versions of the Edge browser, the Microsoft Launcher for Android, Office apps everywhere, and the new Your Phone Windows app that replicates device content onto your PC.

Doubling down on its own mobile ecosystem makes a lot of sense, because Microsoft needs to keep its users on its own applications, not let them slip to Apple’s or Google’s competitors. But mobile is only part of Microsoft’s business, and the Windows desktop is still a significant part of its revenues. That’s where Project Rome comes it, as a way to take data across different versions of the same application and control one application from another. (And, yes, the name Project Rome is a terrible pun.)

An example is the Windows Timeline in recent versions of Window 10. Timeline lets you explore your web history, along with recent Office documents. It builds on top of the Microsoft Graph, a set of APIs and cloud-hosted storage that works to exchange information among devices. InfoWorld dubbed the concept “liquid computing” when Apple debuted it in 2014 as the Handoff functionality in iOS and MacOS.

With Timeline, you’re not limited to the Office files from one PC; you can see them from all PCs that use the same Microsoft account. The same is true of your web history, with content from not only my PCs but also my iOS and Android versions of Edge. It’s like Apple’s iCloud or Google’s Google Account services, except it works natively across Windows PCs, iOS devices, and Android devices (but not Macs).

The Windows team talks about Project Rome as a way of separating application experiences from devices, taking your context from device to device in much the same way as OneDrive and other cloud services abstract your data away from your PCs.

There are three key elements in Project Rome: device relay, activities/timeline, and Microsoft Graph notifications. They cover most key ways of preserving context, giving developers the tools they need to transfer actions and status among different versions of their code across different devices. As well as using them in its own apps, Microsoft has released a series of Project Rome SDKs for developers to help add these features into their own code, linking Windows apps with iOS and Android devices.

Microsoft recently finalized the Android and iOS Project Rome SDKs, moving them from beta to production release. While there’s more work to be done to expose mobile platform functionality to Windows, there’s more than enough here to get started. You can find the SDKs on Bintray for Android and Cocoapods for iOS, with sample code on GitHub to help you get started. Windows and Xamarin developers can find SDKs on nuget or in the Windows SDK.

Working with Project Rome’s device relay

Device relay is perhaps the most interesting scenario. When using it, once device can control another. It’s how Microsoft uses its Your Phone device to send SMS messages from an Android phone, using the familiar Windows UWP application to keep your hands on your keyboard. Controlling remote devices this way helps you stay close to your main task, reducing the risk of losing flow when you pick up a new device.

The Project Rome SDK supports two device-relay scenarios. The first, remote launching, starts an app on one device from another. It’s the technology Microsoft uses to launch OneNote notebooks on the Surface Hub, or to switch between Teams meetings on smartphone, desktop PC, and Surface Hub. The second, app services, provides a way to set up a content pipeline between two devices, so you can send messages between two apps.

Building an app that can take advantage of these features is relatively straightforward, whether you’re working on iOS or on Android. However, some apps can’t be controlled via device relay, usually as a result of security choices made by their app developers.

Registering apps with Project Rome services

Apps need to authenticate with Microsoft accounts to use Project Rome features, and to access the underlying Connected Devices Platform. You need to register your app with Microsoft too, to get the client ID that’s needed for access. Apps also need to be registered for cross-device experiences in the Windows Dev Center, even if they’re Android or iOS apps. Registering them also sets up support for your other supported platforms, linking the app IDs so the Connected Devices Platform is aware of the different platforms your code will use.

Once registered, you can include the Project Rome Connected Devices SDK in your app, along with configuring the application manifest with permissions for internet access, network state, and Bluetooth. You don’t necessarily need to set Bluetooth access permissions, because it’s only needed for Bluetooth discovery and Bluetooth device-to-device connections. If you’re only using Wi-Fi, Bluetooth access permissions are not necessary.

Apps authenticate with the Connected Devices Platform using OAuth, so users need to have either an Azure Active Directory or Microsoft account to generate a token. As part of the token request, you need to request a few permissions to handle the connection, and you need access to certain Microsoft servers that are used by the service. Push notifications are handled by the appropriate service for your device, so, for example, Android apps need to register with Google’s Firebase messaging service.

Communicating over the Connected Devices Platform

Your code also needs to subscribe to a selection of notifications, to handle messages from the platform. Much of Project Rome’s functionality is handled by messaging, so you need to use asynchronous event handling to work with the service. Once connected, you need to discover remote devices, which will return a list of registered devices that belong to the logged-in user. Each device is associated with an event listener, managed by a watcher object.

Once you have a list of devices, you can pass data to them; for example, to send an application-specific URI to launch an app. If the app supports more complex URIs, you can use them to set a state or trigger a function. If you launching a presentation on a Surface Hub from your smartphone, for example, you can have it open at a specific slide.

Remote app services require more work. Your code needs to expose services to the Connected Devices Platform, so that apps can communicate via service endpoints. Once you’ve set up a connection, you can send messages to and from the service, using message payloads to handle binary-encoded content. The Project Rome message format uses key/value pairs to control apps, with simple responses to indicate that a task has been carried out by the remotely controlled service.

There’s a lot more in Project Rome’s SDKs, with tools to handle more complex scenarios by taking advantage of technologies like the Microsoft Graph. However, the most important aspect of the SDKs and the Connected Devices Platform is not that you can connect apps running on different platforms, but that it’s actually easy to do it securely. That’s a big step forward into a heterogenous future, where apps and devices are less important than what we do with them.

Copyright © 2019 IDG Communications, Inc.