potatotips #43 の iOSブログまとめ枠で参加させていただきましたのブログです。
会場の Money Forward さんのオフィス。プレミアム会員になるぐらいにはお世話になっているのでテンションが上がる。
会場。とにかく新しくてオシャレという印象。
社員さんがいらっしゃったので、
「LINE Pay に対応して最高に便利になりました」
「bitflyerやmaneoとか銀行以外にも手広く対応してるのありがたいです」
「ただアプリで開くとあまりに堂々と総資産が表示されすぎて出先で開きにくいので非表示にするオプションをつけてくれ」
などなど日頃の感想を言いたい放題言いました。
以下発表内容です。間違いや気になるところなどあればご指摘ください。
iOSのBLEでハマった事 + Tips / tomoya0x00 さん
BLEデバイス(peripheral）がアプリから見つからない（フォアグラウンドのスキャンでは引っかかるが、バックグラウンドだけ見つからない）ということがあった。
まずバックグラウンド特有の制限に引っかかっているのではないかと考えたが違った。アドバタイズ間隔が広すぎるとバックグラウンドで検知できないのではないかと考えたが、それも違った。
その後、BLEスニファーというものを使って、BLEの伝播をキャッチして通信内容を見た。iOSだとスキャンレスポンスは無視されるのだが、スキャンレスポンスにService UUIDが乗っかっていたのがわかった。
どうするか？iOSは過去に接続したことあるBLEデバイスのIdentifierを記録しているので、これを指定すればスキャンせずに接続要求できる。ベストプラクティスに従うと吉。
感想
nRF Connect、BLEに触れてしまったカルマを背負うものの端末にはだいたい入っている気がする #potatotips
— どくぴー (@e10dokup) 2017年8月28日
BLE扱うのなかなか大変そう。どういう風に対処していったか、細かく紹介されていて参考になりました。
VIPERアーキテクチャのRoutingに関してTIPS / ヤマグチケイスケ さん
www.slideshare.net
まずVIPERの説明。VIPERとは
- View 画面。UIViewControllerとか
- Interactor ロジック
- Presenter 仲介するやつ
- Entity データとかenumとか持っている
- Routing なにがどこにあるか知ってる
の5種類のModuleを使ってアプリを構成していく設計。
それぞれに Input と Output の protocol を持たせて、どういうI/Fでモジュール間のやりとりをするのかを規定する。Generambdaという自動生成機を使えばModuleを簡単に生成できて便利。
Routingは全Moduleを知っている唯一の存在。これに hyperoslo/Compass をつかうとすごく良い。
hyperoslo/Compass は、画面の呼び出しや機能の呼び出しを一括で文字列のスキームとして扱えるので、Routingを1モジュールでやる場合に相性が良いとのこと。
2つ目のtipsは時間がなくて終了。（Storyboard のインスタンス化をenumを使って便利に安全にやるというやつっぽい）
感想
VIPER、何度も名前は聞いててMVVMで足りないときちょうど良さそう、という印象。
実際に使って作ってみたことがないのでそろそろ作ってみたい気分になりました。Generambda も使ってみたい。
Firebase Realtime Databaseを良さげに抽象化する / hiragram さん
Firebase Realtime Database を 良さげに Swift で抽象化した話。
Firebase Realtime Database はでっかいJSONをみんなで読み書きするようなイメージのDB。オフラインで読み書き可能で、再接続時に自動的にサーバーと同期してくれるのがお気に入りとのこと。
Firebase自体は便利なのだが、JSONそのまま扱うとぐちゃぐちゃになりそうで、抽象レイヤー（Repository層）を作りたいと思った。具体的にはモデルをプロトコル志向っぽく定義して、それらのプロトコル使って読み書きメソッドを共通化する。
たとえば RxSwift の Single<T> を返却する fetchAllFromFirebase<T: FirebaseSchemaMaster>() とかを定義して（FirebaseSchemaMasterは今回定義した、Firebaseのモデルが準拠するプロトコルで、マスターテーブルっぽく使う）、その中で firebaseDBRef を使う。
こうすることによって、FirebaseSchemaMaster に準拠しているモデル型は、fetchAllFromFirebase()を呼ぶだけでよくて、Firebaseに関する実装から切り離すことができる。
感想
Repository層を導入したくなった動機として以下が納得感が強かったです。
Firebaseの抽象層をちゃんと作りたかった理由もう一つ、FBの機能ありきのコードがアプリ全体に散らばるのが一番最悪だと思っていて、適切に抽象化して特にUI層と切り離しておくことでFirebaseを辞めなきゃいけなくなったときに傷を浅くできるかなと #potatotips
— 🙌🐼ひらり🐼🙌 (@hiragram) 2017年8月28日
たしかにテストのこと考えても抽象化しておいたほうがよさそうです。
全く同じ理由で抽象化してます。その結果Mockを差し込みやすくなって、UseCaseのUnit Testがしやすくなりました。
— Daiki Matsudate (@d_date) 2017年8月28日
本筋に関係ないですが try で JSON の値を取得してる拡張すごく直感的で良いので使ってみたいと思いました。
5分で理解が追いつかず hiragram さんには懇親会で色々質問しまくってしまったのですが丁寧にお答えいただきありがとうございました。
FirebaseUIとSDWebImageのコラボでFirebaseStorageの画像を表示する / kboy さん
受託したアプリでFirebase使った。サーバーサイドが書けないのでmBaaS使いたかった。mBaaS の他の選択肢として、ニフティの NCMB を使うこともできたが、今回はプッシュ送りそうなのでFirebase を使ってみた。
手前味噌ですが140文字でいい感じにまとまったので貼ります。
Firebaseのストレージの画像URLが取れなくてSDWebImage使えなかったが、firebase/FirebaseUI-iOS使ってfirebaseStorageのrefをSDWebImageに渡すとSDWebImageが拡張されててよしなにできる #potatotips
— Kazumasa Kumamoto (@kumamo_tone) 2017年8月28日
感想
Qiitaに追記されてましたが、本質的な原因は、downloadURL ではなく、 content-type が application/octet-stream になっていたからとのこと。
アップロードの際に content-type を image/jpeg などにすると、 downloadURL をそのまま指定してもいけるとのことでした。
downloadURL() で public なURLが取れるので、アクセス許可周りはいじらなくても大丈夫とのこと ( http://qiita.com/k-boy/items/3d6aa6c26a0c6510320e#comment-e712b0c042bcb5554765 )。
発表しっぱなしではなく、TwitterやQiitaコメントを拾って、本記事にスピーディーに反映していたのが素晴らしいなと思いました。
danger-swift / jp_pancake さん
danger は プルリクエストで人力"you forgot to …" をしないように予めルールを定義してCIでチェックできるツール。
最初にRuby版のDangerがあり、最近DangerJSというのができた。そしてごく最近danger-swiftというのができた。Ruby版は cookpad/dokumi というOSSがベースになっているらしい。
CI回さずにコンソールからでも実行可能で、GithubからPRの情報を取得してwarn関数で出力することができる。
danger-swiftでは Dangerfile（設定ファイル）をSwiftで書ける。DangerJSを中で使っているぽくて、ステータスは開発中。
感想
danger、話を聞く度に、すごく良さそうという気持ちにはなるのですが、後回しになっていて、そろそろ触ってみねばなという気持ちになってきました。
同じく jp_pancake さんの以下のスライドでは、fastlaneやRxSwiftでの事例も紹介されています。もっとガッツリ使うとどうなるのかも気になるところ。
Natural Language APIとその裏側を覗く / akatsuki174
Natural Language Processing and your Apps というWWDC2017のセッションのざっくりした内容と、裏側で使われている技術について。
セッションの内容に、ファーストパーティアプリでどのような活用がされるかという話があった。iMessageアプリで、予測変換で最初サジェストされていなかった語が、Webページを読むにつれ学習されていってサジェストされるようになるなど。
おそらく、固有表現抽出というのを使っている。固有表現抽出というのは、固有名詞、時間表現などをテキストから抽出する技術。 固有表現抽出の活用どころとして、Watsonなどの質問応答システムなどがある。
固有表現抽出とは何か？たとえば、「渋谷で明日19:30から予約できる店を探して！」とチャットボットに送ると、固有表現q=渋谷, 明日19:30を抽出する。
逆に、「昨日あった地震の最大震度、マグニチュード、震源地について知りたい」とやると、それに関して書いてある文章から固有表現を抜き出してというパターンもある。
固有表現抽出をするには、知識ベースで規則を定義しまくるか、SVMなどで学習することになる。でもNLP API ではそこら辺考えずに結果だけ使うことができる。
時間の都合上削った内容も含まれている完全版のスライドはこちら。
感想
SiriだけでなくAmazon Echo, Google home, Clovaなどの音声スピーカーの台頭により、音声認識や自然言語処理に関してはこのあたりこの先盛り上がっていくことは間違い無しなので、ここらへんのカジュアルな話がアプリ開発者向けにアレンジされている発表は個人的にありがたい感じでした。
固有表現抽出の説明がとてもわかりやすくて、人に説明するときに使いたいなと思いました。iOSDCの発表も楽しみです。
Getting all Enum element. / bannzai さん
Int型の連番のEnumのすべての要素を取得できるマイクロライブラリを開発したのでその紹介。
enumにどういうcaseがあるのか全列挙したり、要素の数が知りたいときに、自分で定義した Enumerable に準拠させれば、 .elements と .count でそれぞれ取れるようになる。
感想
Hashable に準拠していれば使える版のブランチも用意しているとのこと。
内容自体はシンプルなextensionで、なるほど〜で終わってしまいそうですが、ライブラリにしていい感じに共有する行動力と瞬発力が素晴らしいなぁと思いました。
ちょうど自分のお仕事で関わっているリポジトリでも同じことやっている人が最近いらっしゃったので、個人的にタイムリーでした。
さいごに
懇親会ではピザとポテチなどをいただきました。ポテチうまい！
全体的にバリエーションに富んだ発表でとても面白かったです。また参加したいです（毎回言ってる）
