-
-
Notifications
You must be signed in to change notification settings - Fork 576
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
Comments
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! |
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! |
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! |
For Android - take a look at WebsocketClientEndpoint from java.net |
@flc |
Thanks @SammyVimes that's great news! |
@flc You should take a look at PushReceiver.java, Manifest and App.java classes |
@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? |
@FZambia of course, I want to implement full-functional client. |
@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. |
Another approach worth thinking about: Some examples here: There are 3 options:
Its really easy to integrate with android studio and XCode IDE too. Slides / Concepts: http://www.codingvelocity.com/2015/07/23/go-mobile-intro.html This means that its write once, publish anywhere. |
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. |
@FZambia Regardign types. Yes your right that there are some restrictions. 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. |
@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
|
Yeah its a pain at the moment. 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 |
@SammyVimes just proposed pull request (#42). This is related to what I wrote about missed messages. |
@FZambia |
I suppose this issue is not relevant anymore: |
@SammyVimes yep, you are right! @flc if you still interested in this – please look at our new clients. |
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 ?
The text was updated successfully, but these errors were encountered: