掲題のとおり、アプリをGoogle Play Storeに公開した。
名前は"Omnitweety"。「オムニツイーティ」と読む。
機能はホントにシンプルで、「ブラウザ系アプリのシェア機能から、ワンタップでURLをTwitterに共有する」だけだ。
ブラウザの共有からOmnitweetyを選択
画面下部にポップアップが表示される。あとは待っていれば自動でTwitterに共有される。真ん中の青いボタンをタップすれば即座に共有される。
もし共有する前にコメントを入れたい場合は、ポップアップの鉛筆アイコンをタップすれば編集画面が起動する。(文字数はURL短縮を考慮)
操作は基本的にこれだけだ。あとは設定画面で"NowBrowsing:"の部分(ヘッダー)を編集できる。
私はTwitterにURLをシェアすることが結構あるんだけど、その際のフローは大体下記のとおりだ。
結構手順多くて、しかもこれが毎回のことだから非常にめんどくさい。 Google Play Storeを探してもこれをいい感じに短縮してくれるアプリが見つからなかったので、じゃあ作ってしまえ、となった。
作るにあたって決めた要件は下記の通り
そして、上記要件から導き出された仕様が下記のものだ。
こんな感じで開発を始めた。 いろいろと初めての挑戦をしたこともあって、だいたいコーディングだけで15人日くらいかかった。
とてもイケてるDIライブラリ。Componentの分割方法とか結構悩むところは多いけど、これなしでアプリ作るのはもう考えられない。
今回はグローバルのAppComponentが一つあって、その下に各Activity毎にActivityComponentを作る構成にしてみた。FragmentやViewにも、ActivityComponentからinjectする感じ。
public abstract book {
String title();
String author();
}
みたいなアブストラクトなモデルクラスを用意しておくと、アノテーションプロセッサを使ってイミュータブルなモデルクラスを作ってくれるライブラリ。ビルダークラス周りとか機能が充実しているので結構便利。
Gson連携もできるけど、後述するTwitter Kitが使ってるGsonの設定をいじれないのでうまく使うことができなかった。
最初はプレゼンテーション層やデータ層のモデルクラスを全部これで作ってたんだけど、最終的にRealmのLazy Loadをフル活用しよう、という方向になったので使う箇所が減ってしまった。DBにSQLiteを使う時やGsonを自由にいじれる時、そしてアプリの各層を疎結合にしたい時は(というかRealm使わなければ)とても便利だと思う。
色々リアクティブに扱えるライブラリ。リスト操作やスレッド周りの処理が楽に書けるので、今回もお世話になっている。
Androidにもついにやってきたデータバインディング。
xmlにロジックを書くの、なれるまでちょっとモニョるしAndroid Studioのサポートもまだまだだけど、モデルクラスに値を設定するだけで画面が更新されるっていうのはちょっとライフチェンジングだった。いい使い方を模索したい。
RecyclerViewで複数のViewTypeを扱う時の処理を簡単に書ける。基本的にいいんだけど、今回良く使ったEnumBindListAdapter
はEnumとDataBinderの関連付けが弱かったり、ちょっと足りないところがあるのでそのうちオレオレ版を書くかも。
前回作ったアプリで非常に便利だったので、今回も継続使用。
Twitterのステータス本文に関する様々な処理を行ってくれる。URLの短縮を考慮した文字数の計算とか、ステータス本文からURLのみ取得するとか。Twitter謹製なので、これ使っておけば間違いないかなーって感じ。
最近流行りのDBライブラリ。
動作は速くて最近よく使ってるけど、まだまだ制限多いかなーって印象。
RxJavaサポート待ってます。
マルチプロセスをサポートした、SharedPreferenceの代替ライブラリ。
個人的にはマルチプロセスもそうだけど、自動で作成日時や更新日時を保存してくれるのがよい。Android MのAuto Backupもサポートしている。
今回は昨今の流行りに乗ってMVPでの実装を試してみた。
https://github.com/android10/Android-CleanArchitecture 参考にしたのは↑このレポジトリで、いわゆる"Clean Architecture"だ。
今までビジネスロジックは機能ごとに一つのクラスにまとめるタイプの実装ばかりしていたので、1ユースケース1クラス、という実装はとても新鮮だった。クラス数・メソッド数はすごい勢いで増えるけど、ユースケース毎にクラスが分かれてるから実装がシンプルで見やすくなってよい。また、データの取得や保存ロジックも別レイヤに分かれているのでコードの見通しはやっぱりよい。
ただ正直言って、数画面しかないこのレベルのアプリケーションでは完全にオーバーキルだった。今回は単にClean Architectureやってみたかったから採用したけど、アプリの規模にあったアーキテクチャ選ぶのも重要だと実感した。
最初はこのレポジトリの実装例に忠実に、各レイヤで別々にモデルクラス用意して、レイヤ間で受け渡しするときにパースして…ってやってたんだけど、そのやり方だとRealmの持ち味であるLazy Loadが活かせない。
なので、いろいろ悩んだ結果結局Realmで管理してるデータは、RealmObject
をそのまま各レイヤで使うことにした。アーキテクチャ的にはあまり美しくないけど、Realmの利点を活かしたいなら仕方ない気がしている。うまいことRealm使えるアーキテクチャ模索したい。
アイコンは今回かなりこだわった箇所で、99designsというサイトでクラウドソーシングしてみた。3万円ほどでたくさんデザインが集まり、非常に満足している。ただ、満足しているとはいっても応募作品の中に盗作があったりして思うところはあるので、そのうちまとめようと思っている。
同じような機能のChrome拡張機能を以前リリースしてるので、名前揃えたほうがいいよなーと思ったのでこの名前に。Chromeのオムニバー(アドレスバー)からツイートするので"Omnitweety"だ。ホントは"Omnitweet"にしたかったけど名前がとられてたから"y"をつけてみた。
拡張機能と名前を揃えよう、と思いつく前は"TweetLink"とかそのまんまの名前を考えていた。
幾つか機能追加を検討中。
こちらからは以上です。
Omnitweety PlayStoreリンク: https://play.google.com/store/apps/details?id=net.yslibrary.omnitweety