Plaidでの画面遷移
しほちゃんです。
前のブログ続きです。
今回はDynamic Feature Moduleを採用しているPlaidがどのように画面遷移を実現しているのかをまとめます。
Dynamic Feature Moduleでの画面遷移の難しさ
- 依存関係が一般的なアプリの依存関係とは逆になる
- 各featureモジュールがappモジュールを知っている
- appモジュールがが各featureを知ることができないので、
Intent(ACTION_VIEW, ActivityName::class.java)
を利用してclass名指定でのactivity起動ができない
Plaidでの実装方法
- 遷移のための
AddressableActivity
interfaceを作成
/** * An [android.app.Activity] that can be addressed by an intent. */ interface AddressableActivity { /** * The activity class name. */ val className: String }
- 各画面への遷移は
AddressableActivity
を継承してパッケージからの絶対パスでクラス名を指定する - 更に下記に示す
intentTo(addressableActivity: AddressableActivity): Intent
メソッドを利用して遷移のためのIntentを作成する
/** * Create an Intent with [Intent.ACTION_VIEW] to an [AddressableActivity]. */ fun intentTo(addressableActivity: AddressableActivity): Intent { return Intent(Intent.ACTION_VIEW).setClassName( PACKAGE_NAME, addressableActivity.className) }
intentTo(addressableActivity: AddressableActivity): Intent
IntentExtra
を含まない最も簡単な例は下記のようにclassName
プロパティのみを持つものになる
/** * Base object for DesignerNews activities. */ object DesignerNews { /** * DesignerNews LoginActivity */ object Login : AddressableActivity { override val className = "$PACKAGE_NAME.designernews.ui.login.LoginActivity" } ~~~~ }
まとめ
- Dynamic Feature Module構成のアプリではappモジュールが遷移できる画面を知らないのでどうしても文字列などの指定で遷移しなければならない
- Plaidではinterfaceとユーティリティメソッドを利用して遷移を行う
- 参考:ActivityHelper.kt
- 次回はJetpackのnavigationを利用した遷移を検討予定
Plaidでのリソースファイルの分割Tips
しほちゃんです。
前のブログ続きです。
リソースファイルを各Featureモジュールに分割する際のTipsについてまとめます。
prefixでの対応
- リソースにはパッケージがないのでprefixを利用する
- 例)dribbbleでのみ使用されるリソース => dribbble_xxx
- styles.xmlなど複数のモジュール用のリソースを含むファイル
- モジュールごとに構造的にグループ化、各属性にもpreffixを追加
- 例)plaid/search/src/main/res/values/styles.xml
<style name="SearchViewTheme" parent="PlaidDarkOverlay"> <item name="colorControlActivated">?android:colorAccent</item> <item name="android:searchViewStyle">@style/Widget.Plaid.SearchView</item> </style> <style name="Widget.Plaid.SearchView" parent="android:style/Widget.Material.SearchView"> <item name="android:searchIcon">@android:color/transparent</item> <item name="android:searchHintIcon">@android:color/transparent</item> <item name="android:queryBackground">@android:color/transparent</item> <item name="android:submitBackground">@android:color/transparent</item> </style>
リソース分割の例
search/src/main/res/values/strings.xml app/src/main/res/values/strings.xml core/src/main/res/values/strings.xml about/src/main/res/values/strings.xml dribbble/src/main/res/values/strings.xml designernews/src/main/res/values/strings.xml
- search/src/main/res/values/strings.xml
resources> <!-- about screen --> <string name="about_plaid_0">Plaid is a source of design news & inspiration that serves as a concrete example of [material design principles](https://www.google.com/design/spec/material-design/introduction.html#introduction-principles). Plaid pulls data from [Designer News](https://www.designernews.co/), [Dribbble](https://dribbble.com/) & [Product Hunt](https://www.producthunt.com/); it is in no way an official client for these services nor endorsed by them. It is rather good though.</string> <string name="about_plaid_1">Plaid is written by [Nick Butcher](http://twitter.com/crafty), [Florina Muntenescu](http://twitter.com/fmuntenescu), [Ben Weiss](http://twitter.com/keyboardsurfer), [Tiem Song](http://twitter.com/tiembo) and the Android community.</string> <string name="about_plaid_2">The source code is available on [GitHub](http://github.com/nickbutcher/plaid)</string> <string name="about_icon_0">"Plaid\'s icon is lovingly crafted by the inimitable Roman Nurik"</string> <string name="about_icon_1">[Twitter](http://twitter.com/romannurik) | [Google+](http://google.com/+RomanNurik)</string> <string name="about_libs_intro">Plaid is built with the help of these awesome libraries</string> <string name="about_lib_link">website</string> </resources>
Plaidでのパッケージ構成の変更
しほちゃんです。
前のブログ続きです。
Plaidにおいてマルチモジュール化した際にパッケージを適切な形式に変更、統一するためのルール・Tipsについてまとめます。
パッケージ構成の変更
- 例)dribbbleモジュールの場合:
io.plaidapp
toio.plaidapp.dribbble
- Rクラスの問題
- Rクラスを明確にするため完全修飾名を利用しなければならない
:coreのリソースを利用する場合に
io.plaidapp.core.R.drawable.avatar_placeholder
これを下記のKotlinのimport aliasingを利用することで
import io.plaidapp.core.R as coreR
このように書けるので簡潔で読みやすい。
coreR.drawable.avatar_placeholder
Plaidでのマルチモジュール化の手順
しほちゃんです。
前のブログ続きです。Plaidでのマルチモジュール化の依存関係と手順についてまとめます。
Plaidのモジュール間の依存関係
Patchwork Plaid — A modularization story
- :bypass と :shared dependenciesモジュールはcoreに含まれる
- :app は :core に依存
- 各feature module は :app に依存
Plaidでのマルチモジュール化の手順
- featureモジュールの作成(Plaidではまず :about から作成)
- 関連するActivity, View等とResource (drawable, string, transition…)を移動
- 他featureモジュールでも同様の手順を繰り返す
- coreには共有ソースとhome feedの機能のみが残り、home feedはapplication moduleのみで表示する機能なので関連コードとリソースをappモジュールに戻す
Plaidのマルチモジュール化を調べてみた
しほちゃんです。
所属プロジェクトでマルチモジュール化を進めていきたいと思い、Plaidのマルチモジュール化について調べたことをメモ程度ですが残しておこうと思います。 まとめていたら書いていることがまとまらなくなってきたので、あまり深く考えずに小分けにざざっと書いてしまいます。
内容はPatchwork Plaid — A modularization storyの記事と、nickbutcher/plaidのリポジトリに基づきます。
Plaidについて
- Google製のニュースアプリのサンプル
- マテリアルデザインとDynamic Feature Moduleが適用されたアプリ
- ニュースソースのDesigner News, DribbbleなどそれぞれがDynamic Feature
- 検索、このアプリについてなどの各画面もDynamic Feature
- 各Dynamic Featureはbaseのアプリに含まれず、必要に応じてオンデマンドに配信
Plaidでのマルチモジュール化
- 60%以上のインストールサイズの削減
- コードの衛生面の向上
- オンデマンドでのコード配布
非マルチモジュールプロジェクトのモジュール化の手順
- すべてのコードとリソースをcoreモジュールに移動
- モジュール化できる機能を特定
- Featureモジュールを作成しコードとリソースを移動
coreモジュール
- はじめにすべてのコードとリソースを移動する
- リファクタリング後にはFeatureモジュール間で共有されるコードとリソースのみが残る
- これにより依存関係を明確に分離可能
2016年の社外活動を振り返ってみる。
こんばんは、渋谷でAndroidエンジニアをしている しほちゃん @shihochandesu です。
先日のブログで思っていたよりも1年間が整理できたので、社外活動においても今年の活動を簡単に振り返りたいと思います。
特にOSSの活動については思ったようにコミットできなかったので、GitHubの記録は寂しいことになっており泣きそうですが、来年へ向けて気を引き締める意味も込めて傷口に塩を塗っていきたいと思います。
OSS
コントリビューション
DroidKaigi
github.com
github.com
github.com
Developer向けAndroidカンファレンス DroidKaigi 2016の公式アプリに英語でプルリク投げました。今まで☆とかウォッチしてるだけだったので初PRビクビクしてたんですが、やってみるとなんでもっと早くやらなかったんだと世界が広がりました。
これから更にダメダメなOSSに活動を晒していくので、技術力や英語に自信がない人もOSSした方がいいよ・ω・
ここからあまり内容がないのでダイジェスト
- EasySplashScreen
Updated README.md for a tiny bit by shihochan · Pull Request #1 · pantrif/EasySplashScreen · GitHub
たまたまタイポ見つけたのでREADMEのPR送りました。
- BottomBar
サービスのデザイン要件を満たすために微修正を投げたんですが、ガン無視されたまま(´・ω・`)
- RecyclerViewSnap
こちら他の方法を打診されたんですが力尽きた切ないやつ(´・ω・`)
勉強会での登壇
LTで登壇した勉強会についてまとめます。
スライドはこちら↓
Presentations by Yuki Shiho // Speaker Deck
- potatotips #28 (iOS/Android開発Tips共有会) - connpass
- UX JAM 8 - connpass
- potatotips #29 (iOS/Android開発Tips共有会) - connpass
- kyobashi.dex #3 - connpass
- 神泉Firebase勉強会 #1 - connpass (主催)
- shibuya.apk #9 - connpass
- 【好評につき増枠!】道玄坂BeerBash#1 LT夏祭 CA系メディアサービス編 - connpass
たくさん喋ったなぁ・ω・
勉強会への参加
- DroidKaigi 2016 - connpass
- Rx Ja Night 2016 #1 - connpass
- UX JAM 7 - connpass (ブログまとめ枠)
- shibuya.apk #6 - connpass
- potatotips #27 (iOS/Android開発Tips共有会) - connpass (ブログまとめ枠)
- Android Testing Bootcamp #1 - connpass
- shibuya.apk #7 - connpass
- Drink Meetup with Mercari #33 - connpass
- Google I/O 2016情報共有会 - connpass
- Android Testing Bootcamp #2 - connpass
- shibuya.apk #8 - Report from Google I/O 2016 - connpass
- 2016年6月定例会 Google I/O 2016報告会 - connpass
- WWDC16情報共有会 - connpass
- Firebase ハンズオン勉強会 - connpass
- potatotips #32 (iOS/Android開発Tips共有会) - connpass (ブログまとめ枠)
- DevFest Tokyo 2016 - connpass (スタッフ)
たくさん参加したなぁ・ω・
Schooの講師
僭越ながらお話を頂きまして、オンライン学習サイトのSchooで授業をしました。
1週間毎に1時間分50枚のスライドを作り続けるの本当にしんどかった(´・ω・`)
おかげさまで数字もそこそこ良かったらしいので一安心です。
変なこと言ってるかもしれないです、とてつもなく恥ずかしいので動画は見ないでください。ぼくも一生見ないと思います。
とある執筆
来年の春予定でとある準備を進めてます、お陰で11月〜無休でございます・ω・
また報告できるかと思います、よろしくお願いします。
2016年の仕事を振り返ってみる。
こんばんは、渋谷でAndroidエンジニアをしている しほちゃん @shihochandesu です。
年末になると毎年一年を振り返るエントリーを投稿していたのですが、先日の飲み会でエンジニアは仕事が全部記録に残るとか偉そうに話していたので、今年はきちんとデータで振り返りたいと思います。
※会社のGHEのデータのみとします。
年間データ
===
Contributions in the last year
1,677 total
Dec 30, 2015 – Dec 30, 2016
===
本日30日までですが年間のContribution*1は1,677回でした。
===
Longest streak
29 days
January 12 – February 9
===
次に連続で作業した日数ですが、1月12日〜2月9日までの29日でした。年始たくさん開発したんだなーと。
担当プロジェクトでの開発
更に細かく担当プロジェクトでの数字を見てみます。
Contribution
===
760commits / 26,518++ / 20,927--
===
760回作業して、26,518行追加して、20,907行消しました。
760commitsという数字が多いのか少ないのかというところですが、日毎の作業数とコミット粒度という観点から見ると、
日毎の作業数
760commits / 年365日 ≒ 2commits
毎日2commitsの作業をした計算になります。
コミット粒度
1commitの中にファイル変更をどの程度含めるのか、というのも人によって異なってきます。単純に10ファイルを変更して1ファイルずつcommitすれば10commitsになるわけです。
これについてはぼくの場合、作業のまとまりを明確にして可能な限り細かくしてcommitを見ただけで作業内容が分かる状態が理想だと思っています。
ここまで話しておいてなんですが、つまり人毎の開発思想やスタンスがあるので多いのか少ないのか分からないってことです・ω・
コミット数の推移をグラフで見ると、
年始とてつもなく作業して、7月ぐらいにまた作業量が増えてますね。
今年作ったもの
今年作った機能などをまとめます。
- アプリフルネイティブ化
- BottomNavigation導入
- CircleCI移行
- RxでEventBusを実装 => すぐ止める・ω・
- 記事の既読表示の実装
- AJAレコメンド導入
- 秋葉原ラボと共同で推薦エンジンを利用したプッシュ通知の導入
- Facebook Audience Networkの導入
- サードパーティ製の動画広告SDKの開発補助と導入
広告関連が多いな〜・ω・
社内でやったこと
今年はビジネスサイドにも関わらせてもらうことが多かったのでそちらもまとめておきます。
- 年明けの1月〜事業部の経営ボードに参加(若手枠)
- 職種横断の勉強会開催や若手懇親会など事業部活性のための活動を実施
- 複数事業部からなる部門の技術ボードに参加
- 全エンジニア懇親会、在宅勤務に向けた活動を実施
- 所属プロジェクトの経営ボードに参加
- 事業計画というものを考える・ω・
しほ、海外進出
エンジニアとして一番大きなイベントだったのが、海外カンファレンスに参加できたことです。10月末にロンドンで開催した Droidcon London 2016 に行ってきました。
弊社ではGitHubを通じて社外的に成果を出せば海外カンファレンスの参加費用を会社負担してくれるという素晴らしい制度があるので来年も海外いきたいなぁ・ω・
まとめ
今年もお疲れ様でした。作業量自体は去年に負けずそれなりに確保できたんじゃないかと思う一年でした。
ただ品質がまだまだ低いので来年はOSSに比重を置いて、しっかり通用する技術力を身につける一年になればいいなぁと思います。