Droidkaigi2018 day2 参加メモ

まだ途中

詳解 ViewGroupのレイアウト内部実装

http://seto-hi.hatenablog.com/entry/2018/02/03/163035

各ViewGroupの内部実装がどうなっているのか理解できる素晴らしい発表でした。
内容が盛りだくさんでほとんどメモ取れていないので少しだけ。詳しくは資料で。補足も充実してる。

  • MeasureSpecでどの程度でMeasureしてほしいか指定する
  • ConstraintLayoutはCassowaryを使っている
  • Cassowaryを使うほど複雑ではないViewの場合にOptimizerを使う実装になっている

Elastic Team Building

https://www.slideshare.net/YukiNanri/elastic-team-building

  • 現場の生々しい話
  • エラスティックリーダーシップは良い本
  • フェーズ毎に取るべきリーダーシップは異なる
    • サバイバルフェーズ: チームに学習する時間が十分にない状態
    • 学習フェース: 十分なゆとり時間があり、その時間を使って学習や検証を行っている
    • 自己組織化フェーズ: 自分がいなくてもチームがある程度回る
  • それぞれのフェーズでどのようなことがあったか紹介

サバイバルフェーズ

採用

  • 採用に苦労した。コネがない、エンジニアのことがわからない、誰も来ない。
  • グローバルの存在に気がつき、グローバルもターゲットにした。
  • 面接効率が悪い。
  • 面接を2段階にした。1段階目がダメならそこで終了し、効率良くした。

チャットコミュニケーション

  • プライベートメッセージでコミュニケーションする人が多い。情報共有が一部だけになる。
  • プライベートメッセージが来たらパブリックに促すようにする
  • slackのAnalyticsでプライベートとパブリックの比率が見れるので定量的に傾向を分析できる

会議

  • 会議が増えてきた。会議は何も生み出さない。
  • アジェンダのない会議が多く、非効率
  • アジェンダを事前共有してもらうように促していった。フォーマットも用意。
  • ブレストはOK。だが、ブレストで何を決めるかまで明確にして効率的にする。

グローバルメンバーとのコミュニケーション

  • 日本語で始まった会話でも英語になるように促してあげる
  • コミュニケーションを定量化して評価することが難しい
  • 英語を学んでいこうという雰囲気にはなった

学習フェーズ

ドメイン設計

  • ドメイン知識がプランナーからエンジニア等に広がっておらず、認識のずれが大きくなってきた
  • DDDのユビキタス言語の整備と分からないと発言しやすい環境にする

技術的負債

  • 問題になっている箇所をメンバーで話し合う
  • 定量化しずらいなのでどのように評価するかチームで話し合う必要がある

自己組織化フェーズ

  • リモートワークで、自分がいない環境になった
  • 自分がいなくても機能していた
  • リモートワーク大変。解決できていない。

React Native Androidはなぜ動くのか

Reactとは

  • Viewがツリー階層になる。propsもツリー要素になる。
  • 再描画が強い

Reactではないもの

  • React, React DOM, React Nativeに役割分担されている

React Native Andriodとは

JSとJavaのブリッジ機構

  • JavaのクラスをJavaScriptの公開するイメージ
  • @ReactMethodのメソッドは先程のスレッドなのでネイティブのUI処理はUIスレッドで行う必要がある
  • jsとjava側の両方に仮想DOMがある

すばらしきGraphQLのSEKAIへようこそ

https://speakerdeck.com/gfx/subarasikigraphqlfalsesekaiheyoukoso

SSD Schema Driven Development

  • schemaとロジックの開発を同時に進めること

  • リソース取得系が非常に柔軟かつ強力

  • リソース更新系はメリットは少ない
  • GraphiQl
  • リクエストからレスポンスがだいたいわかる
  • 方は基本JSONと同じ。intとfloatの違いはある
  • non nullも定義できる
  • relay
    • ...
  • クエリは手書き

GraphQLとAndroid

  • Appolo Client。クエリからJavaコードを生成するライブラリ
  • 本命はjavascriptかなという感じはある
  • view componentとqueryを同じファイルに書く
  • モデルや腐敗防止層は不要になりそう

gRPCとProtocol Buffersで作る、一味違う通信周り

https://speakerdeck.com/kmats/protobuf

RPC

  • RPCは他のアドレス空間にある処理を実行すること
  • REST:リソースを中心に考える
  • RPC:アクションを中心に考える
  • RESTが向いているサービス:ブログAPI(CRUD)
  • RPCはURLにアクションが入ってくる(事が多い。仕様で決まっているわけではない)
  • CRUDに収まるのであればRESTの方が良い
  • RPCが向いているサービス:slackのようなチャットサービス   - チャンネルを去る leave   - チャンネルから強制的に退出させる kick   - 同じような処理だがちょっと違う   - RESTでは難しい。RPCにしてしまおう。   - 実際SlackのWebAPIはRPC

gRPC

gRPC-Android的に

  • 通信に必要なコードが自動生成される
  • RPCフレームワークとして無難。Googleの安心感
  • 双方向ストリーミング

デメリット

  • 世の中の情報がまだ十分ではない
  • セキュリティに不安
  • Twitch
    • 内部実装の浮く雑さに起因する問題
    • HTTP/1.1を使えない
  • TwitchがTwirpというフレームワークを使った   - シンプル   - HTTP/1.1化   - protobufだが、json mapping化(gRPCはない)prodobufにはある

protbuf

gRPC/protobuf

  • リクエスト部分までコード生成される

開発の工夫

  • 書く環境で.protoファイルをどのように同期するか
  • github webfuck - google cloud functions - digdag

ウィンドウサイズの変更に強い堅牢な画面の構築

https://speakerdeck.com/nakamuuu/droidkaigi-2018

  • 変更
    • 画面回転
    • マルチウィンドウ
  • 弱い画面とは?
    • レイアウト崩れ
    • 画面の状態を適切に保持できない

レイアウトの構築

  • マルチウィンドウ機能により
    • 幅高さともに狭い状態のレイアウトを考慮する必要がある
    • 通常と異なるシステムUIの配置
  • ステータスバーの高さを取得するというアプローチはいったん疑うべき
  • fitsSystemWindows問題
  • fitsSystemWindowsは一つのViewにしか設定できないのか。そんなことはない
  • View#onApplyWindowInsetsをオーバーライドしなくてもOnApplyWIんどwInsetsListnerで横取りすることができる
  • WindowInsetsの扱いを工夫する

画面の状態を適切に保持

  • android:configChangesを指定して自前でも管理できるが基本的にはなし
  • Handling COnfiguration Changeに詳しく書かれている
  • toolargetool
  • onSaveInstanceStas¥te or setRetainInstance
  • 寿命が違うのでデータの保持
  • 復元可能化どうかで使い分ける
  • サーバから取得して復元可能なものはsetRetainInstance
  • 入力途中の状態のものはonSaveInstanceState
  • onSaveInstanceStateからの移行
    • retainer を作った
  • 寿命が異なるものを用いたときの整合性を担保したい
    • AACのViewModelを使う

Gradleプラグインを作って開発効率を改善しよう

https://speakerdeck.com/tnj/guide-to-build-gradle-plugin-for-efficient-development

  • build.gradle
    • 純然たるGroovyスクリプト
    • .gradleファイルはリモートにおける
  • Projectはbuild.gradleと同義に考えて良い
  • Extension
  • 設定値を格納するオブジェクト
  • 実態はJavaBean
  • setting.gradleはルートを示すために必要なのでからで良い
  • バージョン指定するだけ
  • groupは先程のidの前半。 archivesBaseNameは先程のidの最後

Droidkaigi2018 day1 参加メモ

まだ途中

Kotlinアンチパターン

以下の環境で得られたアンチパターンについて紹介

  • 巨大なアプリ
  • メンバーの開発経験が様々
  • 最大11人

lateinitのnull初期化

  • 通信後などonCreateなどよりはるか後の処理で初期化してしまい、初期化前にアクセスしてしまう

補足

  • kotlin 1.2 から isInitializedが追加され

apply内でプロパティアクセス形式の処理を書く

  • ローカル線数を宣言すると参照する変数が変わりバグになる

解決策

  • メソッドがあればメソッドアクセスにする
  • apply内はthis必須にする
  • applyを禁止してalsoを使う

nullableのままデータを引き回す

  • 毎回nullの考慮が必要になる

nonnullにするために無効なデータを入れる

  • 無効なデータに意味がある場合にバグる
  • nullが何を表すかで処理するレイヤを決めることで解決

data classのインスタンス生成用のメソッドで制約を持たせる

  • copyメソッドで1部のプロパティのみ変更できるので、制約が守られなくなる

処理を共有化するためだけにBaseクラスを肥大化させる

  • javaでは継承余地も異常と言われていたが、intefeceのdefault実装で共通化すると良さそう
  • java8からあるがminSDKversionを24以降にする必要があったのでKotlinのアンチパターンとして紹介
  • 状態を使いたい場合はclass delegationを使うと良い

拡張関数

  • 一般性がない、局所的にしか使わないメソッドを追加する
  • 公式でありそうな名前なのに雑に実装する
  • 拡張関数が便利なので乱発しがち
  • interfaceのデフォルト実装のスコープに限定する

通常の代入、lazy、custom getterをよくわからすに使う


補足

  • delegated propertyを使うとgetter/setter処理を移譲できる

fragmentのviewをlazyにする

custom getter 値を取得する過程で副作用がある、計算量が多い

  • このような場合はメソッドにする

custom setter で常に必要とは限らない処理をしている

  • 値だけを変更することができなくなってしまう
  • 更新用の処理は関数で提供するほうが良いケースも有る

Deep dive into LayoutManager for RecyclerView

  • キャッシュは2つある
    • recycle
    • scrap
  • RecyclerView.LayoutManagerのsupportsPredictiveItemAnimationsを紹介

DataBindingのコードを読む

  • BindingAdapterをインスタンスメソッドに定義できる
    • Componentを用意して追加する感じ
  • InverseBindingAdapterを使って双方向バインディングの定義ができる

Android における Model-View-Intent アーキテクチャ

セッションは聞いていないのでtwitterを見ていて気になったところだけメモ

マルチモジュールのすヽめ

なぜマルチモジュールなのか

  • 主要機能だけではなくログイン・ログアウトや強制アップデートのサブ機能が多く複雑になっている
  • ログイン・ログアウト、強制アップデートの機能をモジュールとして切り出してマルチモジュール化
  • Android Instant App対応するにはマルチモジュールする必要がある
  • Android Gradle Plugin 3.0.0からマルチモジュールプロジェクトのパフォーマンス・チューニングが行われた
  • domainそうにAccessTokenを持っていてでもそれはinfra層から使うよね。
  • AccessTokenを別モジュールに分けることで上位の層を用意していろいろなところからアクセスできるようにした

デメリット

  • databindingとの相性が悪い
  • appにもmoduleにもdatabindingの生成物か生成作られるようになった
  • moduleでrecyclerViewのBindingaAdapterを定義した場合にappにもrecyclerViewを追加するする必要がある
  • Data Binding Compiler V2で解消される予定

モジュールの分け方について

  • レイアで分ける or 意味のある単位で分ける
  • レイアだけでやるのはおすすめしない。
  • 意味あるまとまりで分けて、さらにレイアで分けると良い

Case Annict

  • 機能整理する
  • 明らかに主要機能から外れている機能を探す
  • 機能間の依存関係を洗い出す
  • グルーピングして依存関係を考える
    • 基盤機能を考える

実際にマルチモジュールにしてみる

  • New Moduleすれば追加できる
  • Androidに依存するならAndroid Module。そうでなければJava Module。
  • modulesディレクトリを作ると見通しが良くなる

モジュール間の連携について

  • moduleをまたがった情報を表示するときどうするか
    • 各moduleでfragmentを定義して、まとめ画面ではatatchするだけにしている
  • 他モジュールから情報を取得したい
  • 最上位層のみを公開する。ViewとServiceで分けている

CA.kt #4 (Kotlin Conf報告会) 参加メモ

cyberagent.connpass.com

『Kotlin Conf Keynote』森 洋之

  • 一言でいうと kotlin anywhere
  • 様々なplatformで採用されている

server side

  • パワフルなJVM
  • KtorというKotlin製のWebフレームワーク
  • コルーチンがたくさん使われている
  • コルーチンはexperimentalだが、experimental=不安定ではないので、今すぐ使おう

kotlin android

  • GoogleI/Oでの発表以降Kotlin製のアプリが2.5倍に増えた
  • アプリのKotlin採用率は17%
  • Android Studio 3.0
    • Plugin同封
    • Lintサポート
    • プロジェクトテンプレート
  • Support Library 27.0.0からKotlinのNullablityの対応がすすでいる

各プラットフォームのコードシェアについて

  • 共通のロジックを作る仕組みが導入された
  • expectとactual

『Kotlin Conf Overview』藤原 聖

『Spring and Kotlin』長澤 太郎

  • Bootiful Kotlinが良かった
  • ライブコーディングなので動画待ち
  • SpringはReactorというライブラリを使っている
  • Exposed
    • Kotlin製のSQLライブラリ

『Kotlin Types』荒谷 光

  • FRESHのエンジニア。サーバサイドでも使っている。
  • KotlinのStringはJavaのStringをいい感じにラップしている
  • Unitとvoidは一緒

『Kotlin Puzzlers』仙波 拓

データサイエンティストにどうやって学べば良いか聞いてみた

ざっくりどうやって学べば良いか聞いてみた

  • https://www.datacamp.com/を紹介頂いた
    • ハンズオンでデータ分析を学ぶ感じ
    • ここで概要を理解すれば、後はWEBのナレッジが理解できるようになるらしい

次に機械学習をやる場合について教えてもらった

次にデータ分析を業務で行うことについて教えてもらった

次に業務を離れてそもそもデータ分析とはについて聞いてみた

追加で聞いてみた

  • Q: どういう数値を取っていくかというのは、勉強するよりも業務をやってく中で学んだり、他社事例をキャッチアップするという感じになりますでしょうか?
  • A: 最先端の手法を使うなどでもない限り、他社の模倣や定番の手法のみである程度のバリューは出せるかなという印象ですね。

最後に参考情報として次のサイト・ページを紹介頂きました

iOSDC 2017 day 2 午後 参加メモ

iOSDC 2017 2日目午後の参加メモです。

コード生成による静的なDependency Injection

発表資料
コード

  • DIの概要について
  • ConstructorInjectionについて
  • DIなし密結合だがインスタンスの生成が簡単
  • DIあり疎結合だがインスタンスの生成が面倒
  • 疎結合インスタンスの生成が簡単にしたい
  • DIをサポートする仕組み
  • インスタンスを自動的に取得する方法
    • DI用のInitializerを登録する(各ノードの生成を定義)
    • DI用のprovider Methodを用意する(全体の生成を定義)
    • コード生成による依存関係の解決

Swiftでの実践

DI用のInitializerを登録する

  • protocol Injectableを用意
  • associatedtype Dependencyを持ち、Dependencyを受け取るinitを定義
  • 依存するものをDependencyにまとめる

DI用のprovider Methodを用意する

  • マーカー用にprotocol Resolverを用意(定義はなし)
  • protocol Resolverを継承したprotocol AppResolver(命名は任意)を用意し、provider Methodを記述

コード生成による依存関係の解決

  • SourceKittenを使う
  • Resolverのprotocol extensionにインスタンスを取得するメソッドを生やす
  • Resolverの実装を行うだけで、インスタンスの生成が可能になる
  • 自動的に取得できないdependencyについては、resolveメソッドに引数を渡せるようにしてある

Human Interface Guidelinesから滲み出る限界感を考える

  • sansanのiOSエンジニアの方
  • Human Interface Guidelines(以下、HIG)の限界について
  • 3つの違和感
  • Apple Storeアプリを例に確認してみる
  • ボーダーのついたボタン
    • 購入するボタンはボーダーがついている
    • Webも同じ
    • AppleStoreのサービスとしてWebとも一貫性がある
    • 一貫性というガイドラインに準拠
  • Toast
    • アラートを使わないためにToast
    • アラートの使用は最小限というガイドラインに準拠
  • セクションの文字がボールド
    • ボールドナビゲーション
    • 要素を明瞭に区別する工夫
    • 明瞭性を上げるためにボールドにする
    • 明瞭性を上げるというガイドラインに準拠
  • AppleStoreアプリ以外でも使われている角丸View
    • iPhoneXで画面が角丸になるのでそれに合わせたのではないか
  • ストアレビューガイドラインには独自のアイデアを生み出してくださいと書いてある
  • 狩野モデルからアプリ品質を考える
  • UIの軸と機能の軸で見てみる
  • HIGは当たり前品質として考えられる
  • UIに魅力的品質を求めるのであればHIGに書かれていないようなことを実装していく必要がある

iOSエンジニアのためのNLP基礎

発表資料

言語判定

  • 文字N-gramを活用して判定を行うことが多い
  • 言語判定は簡単ではないので、予め言語がわかっていれば指定したほうが良い
  • 例えば、HELLOは英語、イタリア語、ドイツ語ある

トークン化

  • 文を単語に分けるようなこと
  • 日本語の制度は微妙

品詞タグ付け

  • 単語に対して品詞をつけていく

レンマ化

  • 辞書の見出し語を抽出する処理
  • 過去形から現在形、複数形から単数形を取得するような処理

固有表現抽出

  • 固有名詞や時間表現をテキストから抽出する技術
  • テキストにおいて固有名詞は重要情報

まとめ

iOSと人工知能(AI) -GPU並列演算の仕組みと機械学習

人工知能とは

  • 生物の知能を模倣する技術
  • 強いAIと弱いAIがある
    • 強いAI:人の知能に迫るAI
    • 弱いAI:限定的な問題解決や推論
  • 弱いAIの利用例:画像処理、音声会話、文章の認識サウ性、機械制御、作曲絵画
  • 種類:機械学習遺伝的アルゴリズム、群知能、その他にもファジイ制御、エキスパートシステムなどある

機械学習とは

iOSの中のAI

  • CoreML訓練済みのモデルをアプリに導入
  • MPS GPUを用いたMetalの高い演算機能をアプリに導入
  • MetalはCoreMLより下のレイア
  • MetalはCPUとGPUのシームレスな連携
  • Metalを用いた学習のデモ

15分でわかるバックグラウンドアップロード

発表資料

  • バックグラウンアップロードはドキュメントが少ない、サンプルがしずらい、デバックがしづらい
  • iOS7以降の処理のBackgroud Transfer Serviceの話
  • 他のアプリを使っている時も自分のアプリで比較的大きなファイルをアップロードできる
  • ForegroundではないイコールBackgroudではない
  • SuspendedやNotRunningもある
  • SuspendedはBackgroundと行き来する
  • バックグラウンド以外にもSuspended, Not Runningもある

仕様

  • 簡単な特徴
    • アップロードはiOS上のキューに積まれ制御される
    • パフォーマンス最適化のためにシステムの都合でスケジュール
    • 失敗したら自動リトライ
  • 制約
    • NSURLSessionはクロージャではなくDelegateを使う
    • Dataではなくファイルで渡す必要がある
    • ユニークなIDを生成して渡す必要がある
  • 呼び出せれるDelegateは2つ
  • エラーについてはアプリ起動時にAppDelegateに用意されているメソッドで検知できる(はず)

役立ツール

  • Network Link Conditioner(通信状況を悪くできる)
  • Charles(Proxyツール)
  • Swiftybeaver(ログライブラリ)
    • 反映に遅延があるのでその想定でつかう必要がある
    • バックグラウンドに入るログを確認する時に使える

ハマりどころ

  • timeoutが難しい
  • timeout関連のプロパティは2つ
    • timeoutIntervalForRequest
    • timeItervalForResource
  • forRequestは検証が難しくあまり理解できていないがサーバでの処理時間だと思われる
  • forResourceの方はリトライ含めたタイムアウトなので、望まないリトライはこれで制御できる
    • デフォルトは7日で長めに設定されている
  • iOS11からAPIが増えた
  • プロセスは別で動く

サポート効率を上げるログ収集環境の構築

発表資料

  • トレタでiPad担当をしている方
  • アプリが成長していく中で・・・
    • 再現性のない不具合問い合わせが増えてきた
    • コミュニケーションコストが増大
    • ハードウェアも使い始めてさらに複雑化
  • アプローチ
    • クラッシュ以外の通信エラーなどを検知できる体制
    • 調査に必要な情報をなるべく増やす
    • 問い合わせ時のコストを減らす

クラッシュ以外の通信エラーなどを検知できる体制

  • クラッシュ以外でもログを送れるサービスを選定
  • 今まではHockerAppを使っていた
  • Bugsnag, sentry, crashlyticsを比較
  • Bugsnagを採用することに
  • パンくずログが非常に便利なのでそれが使えるものを選んだ
  • パンくずログはエラーが発生するまでの道標を残す
  • iOS標準でもActivityTracingでパンくずログを確認できる(クラッシュ時のみ)

調査のヒントになる情報をとるように

  • どういう操作を行ったか、どういう状態、環境だったかを取る
  • どういう操作を行ったか
    • ViewControllerの遷移ログ
    • その他UIイベント
    • これらをパンくずに入れていく
  • どういう状態、環境だったか
    • ユーザの端末状態
    • 多くのサービスは自動収集
  • その他、Reachabilityのイベントをパンくずに追加している
  • コンソールのログ(AutoLayout崩れなど)を吐き出し場所を変更することができ、それも送っている

問い合わせ時のコスト

  • 課題
    • 調査に必要なログがそもそも取れてない
    • 日本語で的確に伝達するのが難しい
  • ロジックエラーも詳細に列挙すると良い
  • どういうエラーが発生したかを詳しく呼び出し側に渡す
  • エラーコードが大事
  • エラーコードをユーザにも表示して問い合わせしてもらうようにする

カンファレンスアプリを作ったぞ!!

  • BuildersConのアプリ
  • タイムテーブルについて

アプリ開発アンチパターンを踏み抜きながらアプリをフルリニューアルした話

  • sansanアプリをフルリニューアルしている話

5分でわかるServer-side Swift Vaporの魅力

  • vaporの紹介

関数を引数として渡す書き方のポイント

発表資料

  • 関数を引数に渡すところを少し書き方を帰るだけで、より宣言的に書ける方法を紹介

自分が欲しいとアプリを作った

発表資料

  • Typeというアプリを作った話

Fun with Swift 4 KeyPaths

  • Swift4の強力なKeyPathsについて

地方在住iOSエンジニアの生存戦略

  • 地方でどういう生活をしているかやどんなふうに情報をキャッチアップしているかなど

UIテストの実行時間の短縮に挑戦する

発表資料

  • bluepillや複数のMacを使ってUIテストを並列にして短縮した話

翻訳のススメ

発表資料

  • 翻訳作業を行っている方の翻訳のススメ

2017年におけるiOSアプリ開発のCI事情

  • CIそのものの紹介
  • CIサービスの比較

xcconfigの落とし穴

  • ビルド設定をconfigファイルに書くためのツール(xcconfig)の紹介

fastlane Contributorだけど何か質問ある?

  • fastlaneの運営の話やOSSの運用の話

拝啓 皆様。iOSチームの1人として伝えたいこと。

  • デザイナのポテンシャル発揮できていなくないか?と疑問に思い体制を変えた話。

いつかどこかで使ってみたい「着せ替えアイコン」を実装してみた

  • バックグラウンドで変更できない
  • 60x60を用意したらうまくいった
  • iPad用には専用のプロパティがある
  • キャッシュが強めに効くことがある

iOSDC Japan 2016 の賞金を放置しておくと1年でどうなったか?!

iOSDC 2017 day 2 午前 参加メモ

iOSDC 2017 2日目午前の参加メモです。

新しい画像フォーマットHEIFを用いたiOSアプリの通信量削減

  • 日経新聞社のiOSエンジニアの方
  • Live Photosのようなシーケンス画像を効率的に取り扱える
  • 深度、透過に対応
  • iOS11/iPhone7以上の写真がHEIFで保存されていることを確認
  • WebにアップするときはHEIFからJPEGに自動変換される
  • 日経新聞の朝刊画像を1週間分HEIF/WebP/JPEGで比較した
  • WebPはJPEGと比較して32%削減
  • HEIFはJPEGと比較して52%削減
  • エンコード処理は細かく調査していないがHEIFが一番遅かった
  • HEIFだとハードウェアデコードが可能(A9chip以降に限る)
  • HEIFは特許的にグレー(ffmpeg, GPAC/MP4Box)のところがあるので商業目的で使うのは避けた方がいい
  • 特許的にクリーンな方法を考えてみた(力技)
  • iPhoneをサーバしてHEIFエンコードするシステム

結婚式を支えた技術 Firebaseを活用したサーバレスiOSアプリケーション開発

  • メルカリ カウルのiOSエンジニアの方
  • 結婚式用のアプリを作成したアプリ
    • 写真を取って、サーバに送る
    • その写真にいいねできる
    • お知らせの表示
    • Push通知
  • Firebase Storage, Firebase Database, Firebase Notificationを利用して実現

触り心地の良いInteractive Transitionをマスターしよう

発表資料

  • エウレカでリードエンジニアとスクラムマスターを経験
  • アニメーションにこだわっているアプリは海外製が多い
  • アニメーションの基礎をマテリアルデザインから持ってきた
  • iOSガイドラインにはあまりアニメーションについて書かれていない
  • easing curveとdurationを意識
  • duraionの基準を設けてアプリで統一すると良い
    • 画面外への移動
    • 画面内への移動
    • フルスクリーンの移動
  • 人が遅いと感じる限界は400ms。その基準も設ける

実装について

  • アニメーションの2つのプロトコル
    • AnimatedTransitioning 通常のアニメーション
    • InteractiveTransitioning インタラクティブなアニメーション
  • 遷移のアニメーションはTransitioningDelegateで決める
  • 今日はInteractiveTransitioningについて
  • PanGestureでdispossしていく
  • duration 0.1にすると素早くジェスチャーした時に自然に見える
  • 指を離した時にSpringAnimationをしたい
  • UIViewAnimationのDurationを指定する必要がある
  • 適切なDurationの値は連立方程式を解く必要がある
  • そこでFacebookのpopを使う

AutoLayout と友達になる方法

発表資料

  • CyberAgentのエンジニアの方
  • IB上で行うAutoLayoutの設定の話
  • 友だちになる=1人でAutoLayoutを組めるようになる
  • 大切なこと2つ
    • 制約の正しい付け方と種類を理解する
    • 本当に正しい制約が貼られているか確認する

iOSDC 2017 day 1 午後 参加メモ

iOSDC 2017 1日目午後の参加メモです。

Build high performance and maintainable UI library

  • SpreadsheetViewを題材にした発表

高速なUIコンポーネントを書くためには

  • パフォーマンスチューニングのために大切なこと
    • 計測すること
    • 多くの場合トレードオフがあることを理解すること
  • 基本は負荷の高い処理を減らす
  • UIを遅くする要因を知る
  • UIViewが何をしているのかを理解する
  • UITableView/UICollectionViewのテクニックを学ぶ
  • UIViewについて
    • ビューの数が増えるほど遅くなる
    • 生成のコストは比較的高い
  • パフォーマンスチューニングにはコードの読みやすさやテストのしやすさが犠牲になることが多い
  • バランスの見極めが腕の見せ所

メンテナンスしやすいコード

  • テストしやすいコードはメンテナンスしやすいコード
  • 内部状態、入力、出力が明らかだとテストしやすい
  • UIのテストが困難な理由
    • 内部状態が複雑
    • 状態を変化させる要因が多い
  • テストしやすいコードのために大切なこと3つ
    • データの流れを1方向にする
    • 状態をモデルに分離する
    • 振る舞いを分離する
  • アクション→モデル→ビューと一方向にする
  • 役割を複数担っていても1方向にすることは価値がある
  • 依存関係には2つある
    • 状態の依存関係
    • 振る舞いの依存関係
  • 状態をモデルに分離する。こちらの方が簡単に分離できる
  • 振る舞いの依存関係をなくすにはMockを使う
  • テストしやすいコード、薄いビュー、分厚いモデルで良いコードに

RxSwiftのObservableとは何か

資料置き場
口頭発表原稿

  • ドワンゴの人
  • Reactive ExtensionのObserverbleについて
  • RxSwiftのコードを読む時に参考になる情報がまとまっっている

Observerパターンについて

  • 通知について考えてみる
  • 通知元が通知先に伝える時にどうすればいか考えてみる
  • 通知元が通知先に通知することが解決できる
  • 通知元が複数の通知先に伝える時にどうすればいか考えてみる
  • 通知先のInterfaceが共通でないと、通知先が追加された時に通知元の実装も変更しなければならない
  • そのため通知先に共通するプロトコルを切り、インタフェースを共通化
  • 通知先を配列で持てるようにもなる
  • 通知元がObservable観測可能なオブジェクト
  • 通知先がObserver観測するオブジェクト

Observerパターンのバリエーション

  • pull型のObserverパターン
  • 通知先に通知が届き、通知先が通知元の詳細を知る必要がある場合は取りに行く(pull)
  • push型のObserverパターン
  • 基本構造はpullと同じ
  • 通知先に通知元の詳細を通知する

Rxについて

  • RxのObservableは3点拡張している
    • 通知先に通知する値はEvent(next, error, completed)
    • next以外のEventが通知されるとそれ以降は通知されない
    • unsubscribeの責務をDisposableに分離している
  • push型でもunsbscribeのときはもとのオブジェクトに参照する必要があったがそれを避けるためにDisposableが用意されていると考えている

File数が1300ある巨大SNSアプリを全てSwiftに書き換えてるNow

  • ひま部 学生限定SNSアプリのiOSエンジニア
  • ViewController106個あった(=画面数が106個という意味ではない)
  • 現在のアーキテクチャ積極的な継承を認めるMVC
  • 最大継承数7, 平均継承数3くらい
  • 直面した問題
    • BaseClassの変更で意図しないところでBugが発生する
    • BaseClassの管理が難しくなり開発スピードが下がる
  • Class継承は変化の伝達が横方向
  • Protocolは変化の伝達が横方向

メルカリで実施した過去最大規模のABテスト「ドロワー vs 下タブ」の舞台裏

  • メルカリでUSアプリの下タブ開発を担当した方

下タブ化とメルカリUSについて

  • 下タブ化は一人で担当した
  • スピード最優先
  • コードベースは4年物
  • 画面数200くらい

メルカリのABテスト

  • 独自実装
  • サーバー側でコントロール
  • 開発当時は20個程度並行して実施
  • 現在のメルカリJPだと40個程度並行して実施
  • ABテストの目的
    • 効果測定
    • 不具合発生時のリスク軽減
    • 深観測のための段階リリース

下タブのABテスト

  • rootViewControllerを変えてABテストを実施
  • AppDelegateがでかくなりそう
  • AppDelegateを見直す
  • Windowいらない
  • WindowのサブクラスのMainWindowを作成
  • obj-cから使えないのでNS_FEFINED_FOR_SWIFTを使ったりした
  • 初回起動時にAB切り替えたいと言われて苦労した
  • depplinkの情報にタブのIndexがなくて苦労した

ABテストの結果

  • 圧倒的な差が出て下タブになった
  • しかし、下タブと同じタイミングで他の変更もしたので本当にタブが良かったのかわからなかった

The latest info of ReactiveSwift and ReactiveCocoa

  • ReactiveSwift と ReactiveCocoa の最新情報について

第3の課金形態「寄付モデル」ってどうなの?

  • Bitcoinによる寄付モデル
  • 最終的にTip Jarにした
  • 今のところ寄付率0%

SwiftでShift_JISをデコードする

Swiftで音楽を奏でる

  • AVAudioEngine, AVAudioNodeを使って音楽を奏でた話

iOSDCだけではもったいない!iOSアプリケーションエンジニアの他言語コミュニティ生存戦略

  • みんなにカンファレンスのスタッフに興味をもってもらうための話

多次元宇宙と画面遷移

  • 画面遷移をrootViewControllerで管理した話

ARC vs. GC?ARC in GC

  • GCの話
  • ARCもGCの一部
  • GCは参照カウント
  • JVMGCはトレーシングコレクタ
  • トレーシングコレクタと参照カウントの比較
  • GCは静的自動と動的自動に分類できる

iOSで利用できるデバイスファームのメリット・デメリットの紹介

  • バイスファームを使った見た話
  • AWS Device Farm, Xamarin Test Cloud, Testdroid TextObjectの比較

ローカライズの苦しみに立ち向かう

発表資料

  • 日本語英語対応しているsansaniOSアプリのローカライズで苦しんだ話

この単語、なんて読むんだっけ?

  • 開発で出て来る読みづらい単語の紹介

クラス名に個人の名前を含めるとこうなる

  • BASEアプリに個人名(イニシャル)を含めた話
  • Crashlyticsに出てきたりISSUEになったりしてねたになる

はじめよう!OSSコードリーディング!

  • コードリーディングのメリットデメリットについて
  • コードリーディングのはじめかた

IPAファイルの中身を覗いてみよう

  • 仕事柄ipaファイルを確認するDeploygateのエンジニアの方の発表
  • ipaファイルをunzipして中身を確認した話

子育てエンジニアの家庭内生存戦略

  • 子育て用のアプリを開発した話

これ、リークしますか?