ios-client-sample/ios-client-sample.xcworkspaceを実行- golangの実行環境を準備
local-server-sample/starscream-server/starscream-server.goを実行（socket.ioを試したい場合はsocket.io側）- xcodeの実行プログラム側で
connect starscreamをタップ ---starscream is connected---が表示されたら接続成功sendボタンをタップするとResponseが返却され表示される
備考：socket.io側はProtobufを使ってないです。
Protobufのファイルの生成方法は下部参照
クライアント側のライブラリはStarscream
- objective-cで作成されていてあまりメンテナンスされていないSocketRocketは除外
- socket.ioはサーバ側の言語がGolang非対応なのでsocket.io-client-swiftもなし
- StarscreamとSwiftWebsocketはあまり変わらないが、人気度と知見の量的にStarscream（参考：https://ios.libhunt.com/compare-starscream-vs-swiftwebsocket?rel=cmp-cmp）
サーバ側はgorilla/websocket
- 標準パッケージである https://godoc.org/golang.org/x/net/websocket に下記のように書いてある
This package currently lacks some features found in an alternative and more actively maintained WebSocket package: https://godoc.org/github.com/gorilla/websocket
下記を見ればわかるように標準の方が機能が多く不足しているため
| github.com/gorilla | golang.org/x/net | |
|---|---|---|
| RFC 6455 Features | ||
| Passes Autobahn Test Suite | Yes | No |
| Receive fragmented message | Yes | No, see note 1 |
| Send close message | Yes | No |
| Send pings and receive pongs | Yes | No |
| Get the type of a received data message | Yes | Yes, see note 2 |
| Other Features | ||
| Compression Extensions | Experimental | No |
| Read message using io.Reader | Yes | No, see note 3 |
| Write message using io.WriteCloser | Yes | No, see note 3 |
- https://github.com/daltoniam/Starscream
- ★5,106
- 最終更新日: 3ヶ月前
- Swift
- Objective-CはJetfire
- framework size: 942KB
- first commit: Commits on Jul 17, 2014
- サーバ側が通常のwebsocketが使える
- 軽量
- websocketが繋がらない場合にpollingなどをする場合自前で書かなければならない
- https://github.com/socketio/socket.io-client-swift
- ★3,797
- 最終更新日: 2ヶ月前
- Swift
- Objective-cからでも使える
- framework size: 1.4MB
- 内部的にStarscreamを使っている。
- websocketのライブラリではなくsocket.ioのライブラリ（https://github.com/socketio/socket.io-client--swift/blob/6cfea5aca32bd1ebafccc4c4f1fb7f71e1b2e9ce/Usage%20Docs/FAQ.md)
- Clientでこれを使う場合、Serverもsocket.ioは必須っぽい（内部的にsocketURLなどに/socket.io/のpathなどが付与されている）
- socket.ioが使える
WebSocketが繋がらなかった時に代替手段としてLong Pollingやpollingを行ってくれる
- objective-cでも使える
- サーバ側もsocket.ioを使わなければならない
- socket.ioはもともと
node.js用サーバー側ライブラリとブラウザ用JavaScriptライブラリのセットなのでgolangでのsupportがない。一応go-socket.ioというライブラリがあるが、現状でsocket.ioのversion1.4までしかsupportしていない
- socket.ioはもともと
- https://github.com/tidwall/SwiftWebSocket
- ★1,262
- 最終更新日: 3ヶ月前
- Swift
- Objective-cでも使える
- first commit: May 27, 2015
- Starscream同様
- Objective-cでも使える
- 知見が少ない
- https://github.com/facebook/SocketRocket
- ★8,660
- 最終更新日: 1年前
- Objective-C
- 知見が多い
- コードがほぼobjective-cであるため内部実装が読みにくい
こちらを読んでもらえば大体こんな感じかっていうのは理解できる。 要約すると下記のような感じで書いている
Protocolbufferはスキーマ言語でGoogleが内部で利用しているシリアライゼーション形式である。
スキーマ言語がなぜ今人気になった理由は、単一のDBなどにデータを保存していたような昔と違い、
データはあちこちのいろんなストレージ技術で保存されたり、バックエンドも単一サービスではなくて分割されていたりする。
また、クライアントもweb版, iOS版, Android版それぞれ別の言語で実装されていたりするからだ。
JSON schemeは可読性に難がある。
Protobufがいい理由は簡素で可読で、割と何にでも使えて、しかしすべてをカバーしようとして膨れあがっておらず、ツールを拡張可能。
とりわけ何かがすごく良いという訳でもないけれども、すこし使い込めばこの素朴さが手に馴染みやすい。
- サーバ側クライアント側で余計なすり合わせが発生しにくい
- バイナリデータでやりとりするので軽量
- デバッグは少しやりにくい
- 導入が少し手間がかかる
message [モデル名] { TYPE NAME = UNIQUE NUMBER }
といった書き方をする。
下記のように定義する。
syntax = "proto3";
message User {
int32 id = 1;
string name = 2;
}
- protocolbufferをinstallする
$ brew install protobuf
- swift-protobufをinstall
$ brew install swift-protobuf
- ファイルの書き出し
$ protoc --swift_out={outputのpath} exsample.proto
- 書き出したファイルをxcode.projectに追加
- swift-protobufをpod install
pod 'SwiftProtobuf', '~> 1.0'
- structとして使える
guard let user = try? User(serializedData: data) else { return }- protoc-gen-goをinstall
$ go get -u github.com/golang/protobuf/{proto,protoc-gen-go}
- ファイルの書き出し
$ protoc --go_out={outputのpath} exsample.proto
- goファイルが書き出されるのでgo側からimportすれば、定義モデルが使える