Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iOS / Android client sdks? #40

Closed
flc opened this issue Nov 6, 2015 · 19 comments
Closed

iOS / Android client sdks? #40

flc opened this issue Nov 6, 2015 · 19 comments

Comments

@flc
Copy link

flc commented Nov 6, 2015

This is more of a question.
Do you aware of any existing and preferably stable iOS / Android client sdks?
Also, do you plan to extend this doc: https://fzambia.gitbooks.io/centrifugal/content/server/client_protocol.html ?

@FZambia
Copy link
Member

FZambia commented Nov 6, 2015

Hello!

Unfortunately I have not heard about such SDKs. I personally don't know Objective-C/Swift and Java so can't implement it myself:( I got emails from people who successfully connected from IOS device using SocketRocket websocket library but code is not available. So I hope on community help - maybe one day someone will try to make a client for mobile. Javascript and Go clients can be used as reference to implement client in another programming language.

I am planning to improve that chapter in docs in near future!

@flc
Copy link
Author

flc commented Nov 6, 2015

Thanks for the info! Have you ever used the JS client from an Ionic / Cordova context? I can't see any reason why it shouldn't work, just curious.

But unfortunately I'm in a situation where a native iOS client has to connect to centrifugo. :(

Keep up the great work btw!

@FZambia
Copy link
Member

FZambia commented Nov 6, 2015

Thanks! No, never used, I am too far from mobile dev and even not familiar with Ionic / Cordova:) Hopefully js client will work - if you try please tell me about results!

@sl4mmer
Copy link

sl4mmer commented Nov 7, 2015

For Android - take a look at WebsocketClientEndpoint from java.net

@SammyVimes
Copy link

@flc
I got a repo with android client for centrifugo
https://github.com/SammyVimes/ACentrifugo

@flc
Copy link
Author

flc commented Nov 12, 2015

Thanks @SammyVimes that's great news!
A usage example would be nice.
We are considering to create an ios client, we'll see how it goes.

@SammyVimes
Copy link

@flc
Example is here: https://github.com/SammyVimes/VersionMonitorAndroid

You should take a look at PushReceiver.java, Manifest and App.java classes

@FZambia
Copy link
Member

FZambia commented Nov 12, 2015

@SammyVimes that's really great news! Thanks for sharing

Are you planning to work on other features in this client - retrieving presence and history, handling join/leave events etc?

@SammyVimes
Copy link

@FZambia of course, I want to implement full-functional client.
Btw, is there any way for client to get undelivered messages? (e.g. I sent a message for user, who just left the channel, and I want him to get this message when he comes back)

@FZambia
Copy link
Member

FZambia commented Nov 12, 2015

@SammyVimes cool, keep me posted!

Centrifugo can't do this automatically. This is one of the most tricky parts. First of all - Centrifugo does not keep message history by default - as you know it must be turned on via channel options. So by default Centrifugo drops message as soon as it was sent to all currently connected clients.

Having history for all channels isn't a good idea. We can't figure out how long client was missing and how big this cache must be. But at moment channel history is something like configurable cache for messages in channels.

So two possible workarounds here. First - remember last message uid and call history to get missing messages. But it's possible to lost messages anyway if history size less than messages missed or time of reconnect greater than history lifetime.

Another one - get missing messages from application backend in some way. I prefer this approach as Centrifugo's role is just to do fast message broadcast to currently active clients. Also your client could be disconnected for a day for example - in this case it's a bad idea to rely on Centrifugo to deal with this situation.

I thought about channel option that will automatically send messages from history to resubscribed client (if last message uid provided in subscription request) but decided that this can not redeliver all missing messages in case of long disconnect period and can be done on client side.

If Centrifugo get engine with message history on disk (there are some thoughts on early stages) then in theory such option makes sense to be built-in so Centrifugo users could decide themselves when they need it for channel.

@ghost
Copy link

ghost commented Nov 25, 2015

Another approach worth thinking about:
using gomobile, you can cross compile the centrifugo go client code to IOS and android, and use it from a Android(java) or IOS (objective-c) application.

Some examples here:
https://github.com/golang/mobile/tree/master/example

There are 3 options:

  1. Pure opengl clients GUI. Write all of the client in golang
  2. Native Android and IOS GUI, communicating directly with underlying go code
  3. Hybrid Web app, communicating directly with underlying go code. Use Cordova to help

Its really easy to integrate with android studio and XCode IDE too.

Slides / Concepts:
http://www.slideshare.net/SeongJaePark1/hello-androidgo

http://www.codingvelocity.com/2015/07/23/go-mobile-intro.html

This means that its write once, publish anywhere.

@FZambia
Copy link
Member

FZambia commented Nov 26, 2015

Hello, @gedw99 !

I've heard about it and already thought a bit about making shared library. 2 problems that prevented work in this direction were the fact that I still need to know Java and iOS and their environment to test resulting library somehow. And as far as I know there are limitations for types that can be exported via public API.

But I'll try to storm this idea again looking through your links first. Maybe this is really not so hard to implement as I thought initially. Moreover our go-client not so big (< 1000 lines of code) so it's comfortable to experiment with.

@ghost
Copy link

ghost commented Nov 26, 2015

@FZambia
Well i was also feeling that way.
But getting a basic android and xcode client, just for testing was remarkably easy in the end.
I am a backend guy too.
It does not have to look good, but just demonstrate the idea.

Regardign types. Yes your right that there are some restrictions.
But the go team are working through those and are aiming to have it resolved.

The other thing i am planning is to use flat buffers (or protocol buffers) between the Client GUI and the Client middle tier. This gets around some binding issues, because there are libraries for Protocol buffer for Android and IOS. Just an idea - i have not had a chance to try that out on a project yet.
The advantage is that it means that you can use the exact same code on the server as on the client. No RPC changes :)

@FZambia
Copy link
Member

FZambia commented Nov 27, 2015

@gedw99 just tried to make shared library from existing go-client. It seems that at moment gomobile supports only basic types which is not enough in our case... It can't work with []libcentrifugo.Message, map[libcentrifugo.ConnID]ClientInfo and all named types:

unsupported named type time.Duration
unsupported, direct named type time.Duration: int64
unsupported named type github.com/centrifugal/centrifuge-go.DisconnectHandler
unsupported, direct named type github.com/centrifugal/centrifuge-go.DisconnectHandler: func(*github.com/centrifugal/centrifuge-go.Centrifuge) error
unsupported named type github.com/centrifugal/centrifuge-go.PrivateSubHandler
unsupported, direct named type github.com/centrifugal/centrifuge-go.PrivateSubHandler: func(*github.com/centrifugal/centrifuge-go.Centrifuge, *github.com/centrifugal/centrifuge-go.PrivateRequest) (*github.com/centrifugal/centrifuge-go.PrivateSign, error)
unsupported named type github.com/centrifugal/centrifuge-go.RefreshHandler
unsupported, direct named type github.com/centrifugal/centrifuge-go.RefreshHandler: func(*github.com/centrifugal/centrifuge-go.Centrifuge) (*github.com/centrifugal/centrifuge-go.Credentials, error)
unsupported named type github.com/centrifugal/centrifuge-go.MessageHandler
unsupported, direct named type github.com/centrifugal/centrifuge-go.MessageHandler: func(*github.com/centrifugal/centrifuge-go.Sub, github.com/centrifugal/centrifugo/libcentrifugo.Message) error
unsupported named type github.com/centrifugal/centrifuge-go.JoinHandler
unsupported, direct named type github.com/centrifugal/centrifuge-go.JoinHandler: func(*github.com/centrifugal/centrifuge-go.Sub, github.com/centrifugal/centrifugo/libcentrifugo.ClientInfo) error
unsupported named type github.com/centrifugal/centrifuge-go.LeaveHandler
unsupported, direct named type github.com/centrifugal/centrifuge-go.LeaveHandler: func(*github.com/centrifugal/centrifuge-go.Sub, github.com/centrifugal/centrifugo/libcentrifugo.ClientInfo) error
unsupported named type github.com/centrifugal/centrifuge-go.UnsubscribeHandler
unsupported, direct named type github.com/centrifugal/centrifuge-go.UnsubscribeHandler: func(*github.com/centrifugal/centrifuge-go.Sub) error

@joeblew99
Copy link

Yeah its a pain at the moment.
Other option is to communication as if it was a client and server.
You have 3 options:
Avro
Google buffer
Flat buffers.

All of them want a IDL. Then it code generates both sides.

A pain again because you already have codevthat represents an IDL I know

@FZambia
Copy link
Member

FZambia commented Nov 29, 2015

@SammyVimes just proposed pull request (#42). This is related to what I wrote about missed messages.

@joeblew99
Copy link

@FZambia
BTW for go1.6 allot of this will be fixed.
you can make shared libs, and do dynamic or non dyanmic linking.
There is a good doc about it from the golang mobile team.
Have a google !!! Its loosk freaking awesome

@SammyVimes
Copy link

I suppose this issue is not relevant anymore:
iOS client
android client

@FZambia
Copy link
Member

FZambia commented May 13, 2016

@SammyVimes yep, you are right! @flc if you still interested in this – please look at our new clients.

@FZambia FZambia closed this as completed May 13, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants