Android / iOS clients

[danielmewes]

This is a follow-up for https://github.com/rethinkdb/rethinkdb/issues/5239#issue-124113804 .

Besides our JavaScript Fusion "driver", we should look into opening Fusion up for mobile app developers.

I'm not sure what exactly this will take, but @Rajan mentions some possible paths in https://github.com/rethinkdb/rethinkdb/issues/5239#issuecomment-167700641 .

Also related to https://github.com/rethinkdb/fusion/issues/58

[Rajan]

@danielmewes I'm playing with deepstream framework and they're in the same state as fully working javascript API but no support of Swift/Java clients yet. Exploring to build a TCP based client library in swift 2.1 which is GCD supported for better performance. There are two good libraries for TCP that I'm exploring:

https://github.com/robbiehanson/CocoaAsyncSocket https://github.com/Zewo/TCPIP

Hope we're building TCP based Fusion Protocol as websockets are blocked and won't make for a reliable solution better than socket.io. I'm unsure about Fusion Protocol.

[danielcompton]

@Rajan what do you mean "web sockets are blocked"?

[Rajan]

WebSockets are blocked by firewalls, routers (sometimes) and anti-virus software. They've come up with Engine.io to solve this. I'm not sure about the problems solved by Engine.io. Facebook for example is using MQTT in their messenger to ensure it always works for realtime communication on Mobile.

[rosskukulinski]

I'm curious why socket.io hasn't come up as a potential solution? I've successfully deployed multiple html5 & iOS applications using socket.io to handle real-time data transports with nodejs server. (never got Android past beta due to customer demands).

Socket.io (which in version >1.0.0 utilizes engine.io - mentioned by @Rajan) first initiates a connection using XHR/ JSONP polling, while simultaneously attempting to upgrade to a websocket connection. As a consumer of the socket.io APIs, the upgrade process is seamless and transparent.

Re: @Rajan's comment about websockets being blocked by firewalls/AV: I haven't heard of any problems with this since around 2010-2011 (during which the websocket spec wasn't finalized). Now that websockets are a valid RFC and supported by all browser vendors this usually isn't a problem. @Rajan have you seen a problem with this recently?

Another alternative that I haven't fully thought through is utilizing webrtc datachannels for low-latency socket transport. The only bummer with webrtc is that there's zero Safari or MS Edge support. However, it could be used as a solution for mobile clients. Something for us to think about.

[rosskukulinski]

What is the Rethinkdb webui using for pushing data to the browser?

[deontologician]

The webui doesn't push data, it uses polling. It was built before changefeeds existed and hasn't had an overhaul, though that's on our list eventually

On Sun, Jan 24, 2016, 17:17 Ross Kukulinski notifications@github.com wrote:

What is the Rethinkdb webui using for pushing data to the browser?

— Reply to this email directly or view it on GitHub https://github.com/rethinkdb/fusion/issues/59#issuecomment-174365329.

[deontologician]

The reason we didn't go with socket.io is that all of the fallback stuff means it needs to be fairly in control of a lot of things and we didn't want to link our protocol to the decisions of a library. For building an app, socket.io removes a ton of pain and boilerplate. For a data-layer/framework like fusion, it removes control of the protocol and endpoints

If it turns out we are reimplementing much of socket.io for backwards compatibility, we may head in that direction, but for now bare websockets have been fine

On Sun, Jan 24, 2016, 17:22 Josh Kuhn josh@rethinkdb.com wrote:

The webui doesn't push data, it uses polling. It was built before changefeeds existed and hasn't had an overhaul, though that's on our list eventually

On Sun, Jan 24, 2016, 17:17 Ross Kukulinski notifications@github.com wrote:

What is the Rethinkdb webui using for pushing data to the browser?

— Reply to this email directly or view it on GitHub https://github.com/rethinkdb/fusion/issues/59#issuecomment-174365329.

[Rajan]

There will remain problems with WebSockets as long as people will keep using old firewalls, old OS and old antivirus/other software.

https://wiki.f-list.net/Websockets

An example of Avast blocking websockets.

https://forum.avast.com/index.php?topic=174276.15

You may google "WebSockets blocked" and find many posts even after 2011, that proves that it is not a reliable mode of communication. If you want to be sure consider MQTT (or similar) which is also used by Facebook Messenger and is a "light weight" protocol built atop TCP/IP.

https://en.wikipedia.org/wiki/MQTT

[deontologician]

@Rajan Added issue #104 to track implementing a fallback for websockets

[arden]

i think this features is very important，because now ios/android is so popular.

[jeveloper]

Could i suggest looking into implementation of LiveQuery for Parse, its OSS now. Its nothing fancy but their ios/android sdk uses sockets to communicate. Personally i don't think its "very" high on priority for systems like rethinkdb and horizon, better to get scalable system in place that can sustain 1000s of connections that eventually may require transactional updates and syncing across connected devices.

[adrianbrink]

Are there plans to develop a iOS SDK for horizon?

[deontologician]

No immediate plans, but once we switch back to websockets it should be significantly easier to write an ios client.

On Thu, Jun 23, 2016, 06:43 Adrian Brink notifications@github.com wrote:

Are there plans to develop a iOS SDK for horizon?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/rethinkdb/horizon/issues/59#issuecomment-228053880, or mute the thread https://github.com/notifications/unsubscribe/AAAFVrUvECzZliVSdlqtaztRUNe-GNCzks5qOo1vgaJpZM4HAoeV .

[Rajan]

If I were leading this, I'd use MQTT. https://www.quora.com/What-are-the-pros-and-cons-of-WebSockets-versus-MQTT-as-real-time-web-infrastructure-for-the-Internet-of-Things

[adrianbrink]

I am only bringing this up, because parse might not support Swift 3 and hence an iOS SDK would be splendid.

Also, I think a lot of iOS devs would be willing to contribute to an iOS SDK (me included).

[segphault]

I think that an experienced Swift developer could easily build a native client library for Horizon. I put together a working proof of concept implementation very early in the project. The protocol has changed quite a bit since then, but I don't think it'd be hard for somebody to take this and update it to make it work: https://gist.github.com/segphault/abaad8189ab36ce84b1b4837f96af53b

It'd be neat to see something like that done with RxSwift so that it has some of the same Observables magic that you get in the JavaScript client.

[littleStudent]

Is there currently any way to connect to horizon from ios / android? other than going through all the handshaking stuff myself. ?

[mbalex99]

This would certainly make offline first a priority on mobile.

[arden]

why? there still have no ios/android client sdk?

[adrianbrink]

Is there any movement on this? Also, what is the current process to get it to work with an iOS client? Do I have to expose all then desired endpoints manually using express.js?

[deontologician]

If you want to write an ios client, it's fairly simple. You need a WebSocket library for swift or whatever, and you need to implement the protocol document located here: https://github.com/rethinkdb/horizon/blob/next/protocol.md

In the js client we use observables, but you'd be free to implement whatever interface seems most natural for ios

On Sun, Sep 25, 2016, 14:13 Adrian Brink notifications@github.com wrote:

Is there any movement on this? Also, what is the current process to get it to work with an iOS client? Do I have to expose all then desired endpoints manually using express.js?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rethinkdb/horizon/issues/59#issuecomment-249447092, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAFVtNhWU_ewaB95lWp-g0lsI2Xsv9iks5qtuQLgaJpZM4HAoeV .

[mbalex99]

I think it will be critical to offline data with something like RealmDB On Sun, Sep 25, 2016 at 2:22 PM Josh Kuhn notifications@github.com wrote:

If you want to write an ios client, it's fairly simple. You need a WebSocket library for swift or whatever, and you need to implement the protocol document located here: https://github.com/rethinkdb/horizon/blob/next/protocol.md

In the js client we use observables, but you'd be free to implement whatever interface seems most natural for ios

On Sun, Sep 25, 2016, 14:13 Adrian Brink notifications@github.com wrote:

Is there any movement on this? Also, what is the current process to get it to work with an iOS client? Do I have to expose all then desired endpoints manually using express.js?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rethinkdb/horizon/issues/59#issuecomment-249447092, or mute the thread < https://github.com/notifications/unsubscribe-auth/AAAFVtNhWU_ewaB95lWp-g0lsI2Xsv9iks5qtuQLgaJpZM4HAoeV

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rethinkdb/horizon/issues/59#issuecomment-249447501, or mute the thread https://github.com/notifications/unsubscribe-auth/ACFSMXK1hBMywtISL48Ca5iG3gVliH_Wks5qtuYKgaJpZM4HAoeV .

Maximilian Alexander mbalex99@gmail.com www.maxofeden.com

[richardbarabe]

I'm thinking about using Horizon for a project so I stumbled on this thread. I see it's been around a year now so I wondered if something had moved or if someone out there have made something since. Is there news ?