radioc@?

レディオキャットハテナ

【勉強会メモ】モバイルメソッド大阪 第1回

classmethod.connpass.com

  • 日時:2018/05/10(木) 19:00 〜 21:00
  • 場所:クラスメソッド株式会社大阪オフィス

クラメソさん主催のモバイルアプリ勉強会がスタートしました。モバイルアプリ全般ということですが今回は全てSwiftの勉強会です。

Serverless Swift

クラスメソッド株式会社 田中孝明さん

dev.classmethod.jp

SwiftのOSS

  • Ubuntuでのビルド
  • パッケージマネージャの公式対応

VAPOR

github.com

運用事例

aial.shiroyagi.co.jp

  • まだまだ運用事例が足りない
  • もっと気軽に使えれば

Serverlessへのアプローチ

サーバーレスアーキテクチャの教科書

speakerdeck.com

RestAPI⇒Swiftでもやりたい

AWS Lambda

Serverless server Side swift with Hexaville

medium.com

  • コードをデプロイして実行⇒動かない

サーバレスコンピューティング

サーバーについて検討する必要がなくなる

AWS Fargate

aws.amazon.com

  • サーバーやクラスタを管理することなくコンテナを実行

所感

  • AWS LambdaでSwiftを動かすのは現実的ではなさそう
  • サーバを意識しない構成としてFargeteの選択は良さそう

【ゲスト登壇】今さら聞けないRxSwift入門

株式会社tech vein 猪俣充央さん

speakerdeck.com

RxSwiftとは

  • 各言語で実装されているRxのSwiftライブラリ

ReactiveX

⇒組み合わせて実現

ここが嬉しいRxSwift

  • あらゆるデータをストリームとしてスマートに処理
  • コールバック地獄からの開放
  • 疎結合
    • 改変の影響範囲が小さい
    • 部品化・共通化
  • 各種ストリームを使う便利な道具が揃っている

RxSwiftの基本

  • Observable
  • Subject
  • Disposable

肝になるのはこの3系統のクラス

ストリームのイベント

  • ストリームはnextでデータを流し、completedで終了
  • completedが来たらその先はnext/errorできない
  • error(例外)が来たら、その先はnext/complated/errorは流せない

RxSwiftのSubject使い分け

  • PublishSubject…ボタンのタップイベント
  • BehaviorSubject…スイッチON/OFFユーザーステータスなど
  • ReplaySubject…あまり使ったことはない。履歴系で使えるかも(直近N件を取るなど)

Disposable

  • Subscribeすると戻り値として返ってくる
  • disposeを呼ぶと非同期処理のキャンセルなど監視する側として処理を止める

DisposeBag

  • 監視元インスタンスが死んだら自動でぜんぶdispose
  • DisposeBagインスタンスに突っ込んでおくとdisposeBagが解放される時にまとめてdispose
  • Rx標準ではないがめちゃくちゃ使える

オペレーター

Streamを操作する

  • map:ストリームを変換する
  • filter:ストリームをフィルタする
  • flatMap:ストリームを変換する
  • mapに近いが戻り値はObserver

try RX!

RxCocoa

  • RxSwiftのサブセット的なライブラリ
  • iOS/Mac開発に便利な付属クラス・拡張を提供
  • UIKit提供クラスのrx化

参考

ReactiveX

github.com

Codable用のDecoder/Encoderを作ってみる

クラスメソッド株式会社 中安佑一さん

Codableって使ってますか?

  • Swift4からFoundationに標準搭載
  • 特定の「フォーマットのデータと特定のクラスや構造体との相互変換を簡単に行える

Codable追加した構造体

  • JSONEncoderにSearchConditionを渡してやる
  • JSONDecoderにJSON文字列を渡してSearchConditionの型を指定してやる

Standard Prepared

  • Swift4で用意されているEncoder/Decoder

標準は2つだけ⇒自作してみよう

  • URLQueryItemEncoder
    • URLのクエリを生成
  • URLQueryItemDecoder
    • URLQUeryItemの配列を渡すとCodableなオブジェクトを返す

登場人物

  • EncodingContainer
  • Keyed
  • Unkeyed
  • SingleValue

Decorderも同様

CodingKey

コンテナ

  • EncoderとDecoderにそれぞれ3つのコンテナ

ネストコンテナ

  • ネストされた情報をコンテナに実装

共通するインターフェース

  • プリミティブな型に全部対応

Keyedコンテナ

  • "キー:値" になっている形式はこれが呼ばれる

共通メソッド

  • CodingKeyからキー名をstringValueで取得

エンコーダーの実装

  • コンテナから呼び出すためのfileprivateなメソッド作成
  • Keyedコンテナを返す
  • encodeメソッドは自前で作る(外から呼ばれる)

※メモ

Encoding and Decoding Custom Types | Apple Developer Documentation

qiita.com

iOSアプリ開発における単体テスト入門

クラスメソッド株式会社 山田良さん

テストの壁

  • テストしにくい部分が出て来る
  • 諦めも肝心

テストしやすいコード

  • DIする
  • 依存するモジュールを内部で生成するのではなく注入する

SwiftでのDI

  • protocolを上手に使う
  • 自分で書いたクラスであればinitializeで依存関係を注入
  • ViewControllerにDIできるライブラリも存在
    • 今回は別途Injectメソッドで対応

Presenterに絞って解説

  • ViewController
    • viewDidLoadでpresenterを作る

presenter

  • subscribeで成功したら画面表示
  • errorはダイアログ表示

⇒Mock化

単体テストしやすいモバイルアーキテクチャ

テストしやすいコードを無視して失敗した例

  • keychainを操作するシングルトンを使用したSDKをPresenterで直接操作してKeychainの値を書き換えてしまった

SDKがシングルトンオブジェクトを使っていた時の回避方法

  • Wrapperクラスを作ってprotocolを継承

単体テストを導入した弊害

  • 実装量は多くなる
  • インターフェースが変わる仕様変更の際、修正量が多くなって精神的につらい

ほか

  • APIを叩くテストを書きたかった
  • Schemeを分けて実APIを叩くテストを別途作成
  • CIツールにて単体テストAPIを叩くテストは対象外

感想

  • 破壊的変更を防げた場面はあった
  • 書き慣れていないので作業がなかなか進まない
  • ゆくゆくはTDDを導入したい