In the last topic of the month published on the Upperside blog we discussed WebRTC as a Web App, Native App or Anything In-Between. This post started a live discussion about the need for custom URL scheme in WebRTC native apps.
Following this discussion I had with Aswath Rao I decided to invite him to publish a guest post here where he can provide more details about the idea and explain why he believes custom URL scheme for WebRTC mobile native apps have great value.
The scenario described in this post talks about using a partnering native app that handles the RTC functionality on behalf of the other app. I invite the readers to comment on this, do the readers view this method as a potential alternative to using a PaaS with much easier integration and no real vendor lock but less control (minimal if at all) over look and feel?
Read Aswath’s guest post and provide your point of view on this in the comments section.
In the last topic of the month a few WebRTC “activists” expressed the need for native apps along with WebRTC web apps. Some of the reasons are:
- iOS lacks support for WebRTC in the native browser.
- Native apps provide a mechanism to provide notifications
- Native apps are what users mainly use on mobile
Some of the observations also lead to the requirement raised in this post:
- Some native apps would like to add RTC capability. (Dean)
- Developing native app will require familiarity with that platform. (Chad)
- It is not easy to add RTC capability in native apps as it is to add to web apps. (Schumann)
These observations hint at a specific benefit of web app that is missing from many of the native apps. The objective of this post is to bring out this gap and how the native apps can fill this gap simply. I hope all native apps that aim to provide RTC capability take this step.
Biggest benefit of WebRTC
Though it is not widely and explicitly called out, the biggest benefit of WebRTC is that any website can let its visitors invoke RTC function with a simple click on a “Call Us URL”. The app server required for this need not be part of the same website; it can be hosted by a third party.
Replicating “click to invoke” function in native apps
Given the rationale for the need for native apps in certain platforms and the benefits of using “Call Us URL”, it is imperative that we ensure that native apps have similar capability. Fortunately both the iOS and Android platforms allow something called Custom URL scheme. With such a scheme, browsers and other native apps can exchange data and invoke functions in the WebRTC native app. This way, a website or a native app that wants to provide RTC capability can partner with a native app and can dynamically generate appropriate link using HTTP or custom URL scheme.
So consider the case Dean describes in the original post: “A taxi firm wanting to add a “speak to the driver” button isn’t going to re-write its entire existing native app as a webapp, just to enable feature #37”. With custom URLs they don’t have to. The app has to place a link in the app UI that points to the Custom URL scheme of the partnering app provider with the driver’s id as a parameter. Alternatively, if the interaction happened to be on the firm’s web page, the link will use HTTP form instead of the partnering app’s Custom URL scheme. If the taxi firm does not have its own native app, but its customers use browsers both in a PC as well as mobile devices, then the website can create this link using HTTP or Custom URL scheme depending on the browser’s user agent. WebRTC native apps can make this process simple by keeping the parameter structure the same for both the schemes. This will also address Schumann’s concern as well. With a simple linking mechanism, RTC functionality can be easily outsourced. Since the link can be changed without much difficulty, RTC provider can be changed without much difficulty.
Prior use
Previously some of the RTC apps have used this approach. For example, Cisco Jabber has a scheme named ciscojabber and the invoking end-point can use the call parameter to identify the destination entity. Skype used to have a Custom URL scheme, but apparently they have removed this capability, to much consternation from the user community. A quick review of some of the WebRTC-specific apps have not defined a Custom URL scheme.
Upshot
A native RTC app should have a Custom URL scheme that closely resembles its web equivalent.
About the author Aswath Rao :
Backed by more than 30 years of telco experience, bootstrapped EnThinnai. He blogs at blog.enthinnai.com and active on
Twitter (@aswath). The first product (which is undergoing technical review) is a self-hosted, WebRTC-based messaging system. Details at http://ffonio.enthinnai.com/.
Very interesting indeed 🙂
Just keep in mind that as WebRTC evolves, new APIs come along that are much easier to use than the original PeerConnection API -even to the uninitiated. So adding RTC capability to native Apps is now becoming a snap. Check out the new release of Restcomm Client iOS SDK announced by Telestax to get an idea what is involved:
http://www.telestax.com/restcomm-client-ios-sdk-is-out/
Antonis,
What you are referring to is using a full PaaS solution that comes along with proprietary API for the client side + lock-in to the service itself.
This is not what Aswath talks about in his guest post.
Doing yourself the integration of WebRTC into a native app is not as easy as integrating a PaaS client yet it gives more control and flexibility to the developer.
See my comment about this in the prefix of the post talking about PaaS vs. what Aswath proposes.
Amir
There is the interesting and what’s practical. The Internet purists likely will get upset as this is non-standard in many regards. The notion of not having to embed, maintain, troubleshoot your own WebRTC Comms stack is however appealing. The question though is execution.
Should “Uber” have some type of voice comm as part of their app? The answer is yes, but the real question “Should Uber have some type of voice app that is 100% reliable as part of their app?”
Even with that correct question, the correct answer is still YES. Unfortunately, the current technology fails to get the 100% reliable factor.
Uber is a logistics/transport company and have enough issues with their own app. We’ve all been frustrated with it at some point. Thus they can’t add more frustration meaning create unhappy customers with unproven technology.
If you’re having to call the driver or driver you, this mean there’s a problem (you can find each other) so you can’t afford to compound the problem by layering a potential technical glitch on top.
We’re not there yet, soon, but not yet. Continue to strive towards this working all the time, with no friction and no problems.
I think I understand why you are saying this is non-standard. My initial thought was to define a webrtc scheme analogous to http. But unfortunately, iOS will associate this scheme with only one application. There could be a mismatch between what the device will select for a specific user and “Uber’s” partner. So I settled for this scheme supported by the facts that this is standard procedure within iOS environment and that “Uber” is free to select its partner, modulo that its user has installed that particular app.
I agree with you that Uber will go with regular voice call, since the scenario I describe is a problem scenario. But that is just an example used because Dean mentioned it. But the point applies to a company that has decided to evaluate WebRTC and exploring options.