10/9に開催されたDevFest Tokyo 2017に行ってきたので、雑なメモ。
Tangoで踊らされたオトコがARCoreと向き合う話
- Tangoではdepthセンサー必須だったが、ARCoreでは普及機のカメラで実現できるようになった(iOS 11のARKitに追随した形)
- 3本柱
- モーショントラッキング
- 水平面の推測 (Environment understanding)
- Light estimation
- 画像解析にによる推定
- TangoではToF(time of flight)
- Tango → ARCoreで難しくなったこと
- 壁面の認識
- エリアラーニング
- アプリの開発は、Android Studio 2.3, Unity, UE4
- 実行環境(端末)に、ARCore process appをインストールする必要がある
- Devices: Pixel XL, Pixel, Galaxy S8
- Pixel 2/2XL
- ほかの機種で動かす試みをしている人はいる
- UX: ARのソリューションでなく、モバイルのソリューションであることを意識したい
- JAG ARCore(Tango) Working Group - Google+
React Nativeアプリをリリースし続けるために、最初に行う8つの取り組み
www.slideshare.net
- 開発部分はJSにひとでもできるが、一部、Google Play, Xcode, iTunes Connectなど、ネイティブアプリ開発の知見が必要
- ネイティブのノウハウが必要なところ:設計〜開発の継ぎ目あたり、リリース〜保守
- init後の作業
- application id(Android) , bundle identifier(iOS)
- init直後は適当なものが入っているので必ず変更する
- version
- Semantic Versioningを採用している
- プラットフォーム間でバージョン番号をそろえるか?
- そろえたほうが楽、という運用になった
- リリースノートの書きやすさ
- Gitのタグ付け
- package.jsonのversionを元にコピーしている
- Google Playの制約。version codeは加算のみを許す
- major+minor+patchを組み立ててGradleで自動生成する案
- Google Playにアップロードしなおすために都度patchを上げる必要がある
- 代替案:major+minor+patch+buildという構成(2.1.3-build4 → "2010304"とか)
- major+minor+patchを組み立ててGradleで自動生成する案
- そろえたほうが楽、という運用になった
- build types
- デバッグビルド(同じapplication id)を同じ端末にインストールしたい
- アイコン、表示名も分けないと見分けがつかないので、適切に設定する(スライド参照)
- 運用に便利なツール
- Fabric/Crashlytics (JSのエラーは見えない)
- Fabric/Beta
- AS plugin/Mac appからリリースできる
- Google Play/ iTunes Connectでもベータ配布はできるが、タイムラグがあるのとバージョンを上げる必要があるため
- Deploy Gateでもいい
- faselane
- gitにtagをつけてpush → CIサーバがfastlaneでリリースタスクを実行
- Firebase
- アナリティクス、ストレージ、ABテスト、プッシュ通知
- アナリティクスのためだけに使ってる
- JSのクラッシュレポート
- Sentryを使う
iOS版でアイコン切り替えができていない、というお話でしたが、デバッグビルド向けのビルドターゲット作り、そこでリリース版とは別のinfo.plist
を指定、その中の記述を分けることができます。『iOSアプリテスト自動化入門』のChapter 6「ビルドと配布の自動化」に書きました。
- 作者: 長谷川孝二
- 出版社/メーカー: 秀和システム
- 発売日: 2014/03/19
- メディア: 単行本
- この商品を含むブログ (1件) を見る
Goによるプロダクト開発 〜設計、テスト、Go2に向けて〜
- GAE/Goのaetestが遅い件
- Travis CIからCircle CIに移行して少し早くなった
- package構成
- 実装の歴史的経緯を伝えるためにもペアプロは便利
- 鵜飼さんのスライドを読む
- たぶんこれ: Goに入ってはGoに従え
- 正規表現使いすぎない、map使いすぎない(LLの習慣でやりがち)
- aetestが遅いので、テストを増やすと遅くなるので余り書けていない
- メルカリUSはカバレジ80%くらい
- AWAも80%くらい
- テストを書いていくといい設計になる
- Go2
- ジェネリクス、例外、いる?
- なくても書けている
FlutterでAndroid/iOS両対応のアプリ開発
- FlutterのUIは宣言的、レイアウト/スタイルを編集しやすいのでデザイナさんにも触ってもらえる
- Android, iOS, Fuchsia
- Dartで書く
- Reactive framework(inspired by React)
- 自前UI(Material and iOS)
- OSS(GitHub) developed by Google and community
- GitHubがミラーでなく中心
- dart → ネイティブのARMコードにコンパイル。高い実行パフォーマンス
- 2D GPU-accelerated APIs
- IntelliJ plugin & IDE debug & hot reload
- まだアルファ版(I/O 2017でアルファ)
- 自前UIなので、OEM UIと混在できない。Flutterとプラットフォーム画面の往来は可能
- Widget(FlutterのUI component)だけで1,000近くある。extendsしてカスタマイズできる
- StatefullWidget
- Stateを継承して作り、setState()で処理すると、再度build()が呼ばれて再描画。差分だけ描画してくれる
- テスト
- Platform Channels
- カメラ、位置情報など、プラットフォームのAPIを呼び出すこともできる
- 事例はまだ少ない
- Googleの"mobile sales tool app"
- Hamilton musical
- Newsvoice
- CARTUNE
- CARTUNE - 車好きのコミュニティ
- @najeiraさんが組んだもの
- なぜ選んだか
- クロスプラットフォーム
- Dartの型チェック
- IntelliJのplugin, debug機能
- 開発が活発、Googleの本気度を感じた
- いくつかバグには遭遇した
- stackoverflowで質問したら即回答
- フレームワークもDartなので、ソースを読める
- 新規アプリには有力な候補(本アプリ、プロトタイプとも)
- 既存アプリにハイブリット的に組み込むのは向かない(作成済UIを組み込めないので)