PhoenixFramework の WebSocket に iOS からつなぐ

PhoenixFramework の WebSocket に iOS から繋ぐのはとても簡単だった。

Awesome iOS with 🌟 で、 Swift で書かれている中から Starscream を選んで使ってみた。README にでかでかと表示されたロボットがカッコよかったので。

PhoenixFramework は ES6 で書かれた WebSocket 通信のためのクラスが最初から用意されてて、その仕組みに乗るとすごく楽なので、Swift 側で同じ仕組みに乗るような通信をすればよい。PhoenixFramework で実装された WebSocket の Chat を使ってみる。

PhenixFramework では、特定の topic に join するというのがあるが、これは JSON に event: "phx_join" というのを付けて送ってる模様。また、まだ良く理解できていないが毎通信ごとに ref というカウンターをインクリメントしてるので倣ってみる。 topic には、Phoenix 側で使ってる topic をそのまま入れれば、あとは好きなように payload にデータを入れてやり取りすればOKなようだった。とても簡単。

下記のようなコードで、Phoenix 側と通信して、 JavaScript で繋がってるブラウザとやり取りが出来た。

PhoenixFramework の WebSocket に iOS からつなぐ

WKWebView で NetworkActivityIndicator を良い感じに表示(Swift3)

以前 iOS9 が出たときに書いたものが古くて使えなくなってたので、書き直した。

iOS9とSwift2の頃のやり方

iOS9 から追加された WKWebView で、networkActivityIndicator (iPhoneの上部のステータスバーで読込中にぐるぐるさせるやつ) を表示する方法。 UIWebView と WebView はもう使うなって API Reference に書いてある。

Swift3 になって書き方も変わっているのと、iOS9 から constrains の設定もしやすくなった。WebView の一種でコンテンツを読み込むとき、isNetworkActivityIndicatorVisible を処理しないことが無かったので、 pod でインストール出来るようにした。

EcpWebView (on GitHub)

続きを読む “WKWebView で NetworkActivityIndicator を良い感じに表示(Swift3)”

WKWebView で NetworkActivityIndicator を良い感じに表示(Swift3)

xcodeproj を CONFLICT しづらくする mergepbx

Xcode を使って開発していると、.xcodeproj が、論理的には CONFLICT していないのに Xcodeのバージョンアップ等で激しく CONFLICT することがある。 mergepbx を使うと、理不尽に CONFLICT されるケースをある程度解消してくれる。複数人で開発している時は入れておいて助かることが多い。

1年くらい使ってるけど、特に問題が起きたことはないです 🙂

Install

brew install mergepbx

Usage

以下の2ファイルに設定を追記(プロジェクト単位でもglobalでもOK)すれば、あとは git merge や git rebase とか通常の操作で mergepbx を使ってくれるようになります。

.gitconfig

下記を追加。

[merge "mergepbx"]
  name = Xcode project files merger
  driver = mergepbx %O %A %B

.gitattributes

下記を追加。

*.pbxproj merge=mergepbx
xcodeproj を CONFLICT しづらくする mergepbx

Awesome 某のスター付き一覧

Awesome Hoge のページをよく見ることがあり、特に iOS をよく見ていたのだが、スターの数をまとめて見たいと思い、主に自分用にスター付きの一覧を生成してみました。Awesome repositories の contributors と全てのレポジトリの developers の方々に感謝です。

URLはこれです。
Awesome repos with 🌟

GitHub API で取得した stargazers_count を使っています。 GitHub API、レポジトリの取得なら1時間に5,000回のLimitなので結構叩ける印象。

サーバは要らなそうだったので、AWSのサービスを組み合わせてサーバレスでページを生成しています。

  • Lambda でレポジトリ一覧を取得
  • まとめて GitHub API を叩くと Lambda がタイムアウトするので、一旦 SQS に JSON にしていれる。
  • CloudWatch Events で Lambda を定期的に起動して、 SQS のキューを受信しながら、 GitHub API を叩いて SimpleDB に結果を入れる
  • 定期的に、 SimpleDB のデータを Lambda で JSON にしてs3 に PUT する。

という風にしています。APIにも優しいように、1日かけて1ループするくらいの周期で処理をしています。

DynamoDB ではなく SimpleDB なのは、最後の処理で一括でデータを取得する必要があるのですが、DynamoDB はスループットの設定的に一括取得には向いていないので、課金的な意味で SimpleDB にしてます。無料枠を考えないと、ミニマムコストが SimpleDB はが$0で DynamoDB は$0.67なので。ただ、DynamoDBで読み書き1ずつにして、s3にPUTするときだけ scan しても、もしかしたら DynamoDB の方が安い、ということはあるかもしれません。この部分の比較は見たことがないというか、SimpleDBに関する情報をあまり見かけません。 Lambda からもデフォルトで使えるし、ちょっとした時に便利だと思うのですが、管理画面にも無いし、そのうちサービスが終わってしまうのではないかというのが心配です。

Lambda 開発環境は、最近知った node-lambda がシンプルで使いやすいです。手元での実行とデプロイが出来ます。

HTML側は、S3 + CloudFront です。最近 CloudFront が HTTP/2 に対応したので、個人的には静的ページの配信に HTTP/2 対応のサーバを立てる意味がほぼなくなりました。あと、React で描画してるので、対応してないブラウザでは見えないです。

JSON の URL はパブリックなので、直接叩いても良いです。見ればフォーマット何となくわかると思いますので、 jq とか使って絞り込めば、例えば 「Awesome iOSで、Buttonのカテゴリで、500スター以上付いているレポジトリを開く」とかもすぐ出来ます。

curl https://s3-ap-northeast-1.amazonaws.com/awesome-repositories/ios.json | gunzip | jq -r 'map(select(.category1 == "Button")) | map(select(.stargazers_count >= 500)) | "http://github.com/"+.[].path' | xargs open

※ 一気にブラウザ上でページが立ち上がるので、内容に注意して下さい!

最初 iOS だけ作ったら、他のものもほぼ同じコードで生成できたので、自分がよく使う言語だけですが、6個作りました。 Elixir 力を上げたい。

Awesome 某のスター付き一覧