An open API service indexing awesome lists of open source software.

https://github.com/tomashubelbauer/ios-app-web-control

A demonstration of using WebRTC to achieve communication between an iOS application and a web page
https://github.com/tomashubelbauer/ios-app-web-control

ios ios-app swift webrtc webview

Last synced: about 2 months ago
JSON representation

A demonstration of using WebRTC to achieve communication between an iOS application and a web page

Awesome Lists containing this project

README

          

# iOS App Web Control

A demonstration of using WebRTC to achieve communication between an iOS application and a web page.

## Configuring

- Install [Carthage](https://github.com/Carthage/Carthage) for managing Swift dependencies
- Install [TypeScript](https://www.typescriptlang.org/) for converting TypeScript to JavaScript

### Dependencies

- An [unofficial build of WebRTC by Anakros](https://github.com/Anakros/WebRTC)
- TypeScript for converting TypeScript to JavaScript in the web application

## Running

- Mobile application: XCode
- Web application:
- `cd src/web-control`
- `tsc -p . -w`

## Debugging

- Mobile application: XCode
- Web application: Safari > Develop > My iPhone > … (TypeScript source maps are provided)

### Flow

1. The user decides to use web control, clicks Web Control in the mobile app and the mobile app shows the web app URL to visit
- Currently for simplification, a web view is shown in the mobile app and direct communication is used between the apps
- In the future, the actual web app will be run in a browser on a laptop and the communication will go over the QR channel
- The mobile app, upon clicking Web Control, creates a peer connection and a data channel (without offer or answer)
- The mobile app starts listening for messages from the web app (for now direct communication, in the future a QR channel)
2. The web application is opened and it initiates a peer connection and a data channel and waits for negotiation request
3. The web app requires negotiation and creates an offer, then sets it as its local description and sends its SDP to the mobile app
- The web app also starts listening for messages from the mobile app immediately after startup (now direct, future QR channel)
- The web app will start generating candidates at this point and sending them to the mobile app as messages too
4. The mobile app receives the offer SDP message and sets it as its remote description or candidate and adds it to its connection
- The mobile app creates an answer to the offer message and sets it as its local description, then sends its SDP to the web app
- The mobile app will start gathering ICE candidates at this point and sending them to the web app as messages
5. The web app receives the answer SDP message and sets it as its remote description or candidate and adds it to its connection
6. At some point the data channels open at both ends

In direct communication, trickle ICE is near instant, in QR communication, it will be down to the rotation of SDP and ICE codes.

In the future the web application may be changed to be able to act as a peer (offerer or answered)
so that web applications can interconnect with any other and all have the ability to offer first.

The mobile application will always be an answered only, because the web application doesn't benefit
from the mobile one being used as a remote control. (Or does it?)

## To-Do

### Implement the QR channel

First, keep the web view but hide audit logs (so they are reachable using a button) and split the screen into two equal parts, one for mobile code and one for web code.

Second, actually pull the web site out and verify the QR channel still works.

### Introduce and audio log view

In both the mobile app (replacing the alerts) and the web app