kobakei's blog

たまに書きます

初めての確定申告(eTax)に滅茶苦茶苦労した

2017年から個人事業主で開業したため、今年初めて確定申告しました。滅茶苦茶苦労したので、来年の自分用にメモ。

注意: 正確な確定申告の手順などについては、税務署や税理士にご確認ください。この記事の内容及びリンク先からいかなる損失や損害などの被害が発生したとしても、当方では責任を負いかねます。

続きを読む

#DroidKaigi 2018で「開発者が知っておきたい通知の歴史」という内容で講演しました

DroidKaigi 2018

今年はセッションが採択されたので、スピーカーとして参加しました。去年までは普通に参加者としてだったので、スピーカーとして参加するのは今年が初です。

発表したぞい

speakerdeck.com

「開発者が知っておきたい通知の歴史」というタイトルで、Androidの通知の機能追加の歴史と、互換性を維持してどう実装していけばいいか?というテーマで話させていただきました。内容はスライドを見ていただくとして、この発表をするに至った動機や、当日の発表、オフィスアワーで頂いた質問などを紹介しようと思います。

続きを読む

2017年振り返り

雑に今年一年を振り返ってみます。

転職した

Kyashという個人間送金サービスの会社に転職しました。

一人目のAndroidエンジニアなので、Androidアプリを0から作りました。どんな感じで開発していたかはshibuya.apkで発表しました。

speakerdeck.com

なお、Androidエンジニアとして入社しましたが、Androidチームに超デキる同僚氏が入ってくれたりiOSチームのリソース不足もあって、最近はiOSを書いています。僕と一緒にiOS書いてくれる人を絶賛募集しているので、興味ある人は連絡ください!

DroidKaigi採択された

昨年はリジェクトされたDroidKaigiに今年は採択されました。リベンジ達成。

余談ですが、継続的に社外で発表するというテーマでここ2年くらい活動していた成果なのか、徐々にAndroidエンジニア界隈では認識されつつあるように感じました。今年は社外のAndroidエンジニアと話す機会が多かったのもよかったです。

副業を始めた

知り合いのつながりで、某社でAndroidチームの顧問?アドバイザー?っぽい感じで関わり始めました。基本平日の夜とか休日にちょろっと関わっている程度です。

本業は自分で0から書いたコードなので、技術的負債もなく気になるところは自分でゴリっと書き換えていけばよかったんですが、副業の方はかなりレガシーな設計になっていてクラッシュも多く、優先度を切って順次改善していく作業を進めています。

あと、副業を始めるにあたって個人事業主の登録をしたり確定申告の方法を調べたりとサラリーマンやってる分には知る必要のない勉強もしました。開業freee、MFクラウド確定申告、MFクラウド請求書にはお世話になっています。

投資を始めた

ほぼ預金だけだった資産をそろそろ真面目に運用しようと思い、投資を始めてみました。はじめはロボアドでの積立から始め、途中からSBIでNISA枠を活用したり個別に気になる銘柄を買ったりしています。まだ半年も経ってないので参考程度ですが、一応プラスで推移してます。

最近流行りの仮想通貨は、投機という前提で失っても痛くない程度の金額だけ買ってます。税金考えるとこまめな売買がしづらいので、基本長期保有する予定。

なお投資を始めたことにより資産の推移を簡単に確認したくなり、マネーフォワードを使い始めたのも今年。投資でも個人事業主でもお世話になりまくってます。

ノロわれた

健康面では正月早々ノロウィルスにかかるという幸先の悪いスタートでしたが、その後は大きな怪我や病気もなく一年を終えること出来たのがよかったです。

来年もよろしくお願いします。

広告を非表示にする

Androidアプリを設計する上で考慮したポイント

この記事はAndroid Advent Calendar 2017の13日目です。

僕が今業務で開発しているAndroidアプリの設計の紹介と、そこに行き着くまでの僕の設計に対する考え方を紹介します。

こんな設計にしています

f:id:keisukekobayashi:20171210023107p:plain

どういうポイントを考慮してなぜこの形に行き着いたのかを以下紹介します。

ビューとモデルのライフサイクルの違いに対応したい

Androidアプリにおいて、アプリのプロセスを通して保持したい情報がある一方、画面の状態などはユーザーの操作によって簡単に破棄されることがあります。つまり、モデルは長命だが、ビューやビューモデルは短命ということです。

この辺はこちらのスライドが神資料なので是非読んだことない人は読んでみるとよいと思います。少し古い資料ですが、十分に今でも通用する考え方がわかると思います。

では、長命のモデルから短命のビューに結果を返すときはどうすればよいでしょうか?

結論から言えば、ビューとモデルの境界にはRxJavaを採用しています。理由は、ビューが死んだときの非同期処理を中止するといったハンドリングが簡単だからです。そして、ビューとモデルの間にRxを採用するなら、モデルの内部もRxに統一した方が見やすいため、アプリ全体でRxを採用しました。 今ならArchitecture ComponentsのLiveDataで統一するのもアリだとは思いますが、非同期処理の結合周り(直列処理、並列処理)などはRxの方が向いている気もしています。

依存関係をシンプルに保ちたい

大事なのは依存関係を一方向にすることです。自分より上の層に依存するのは当然NGですが、自分と同じレイヤーにも絶対に依存してはいけません。すぐに循環参照が発生してカオスになるからです。

この設計の場合、ビュー、ビューモデル、モデルが一方向の依存になります。さらに、モデルはユースケースビジネスロジック)、リポジトリCRUDを責務とする層)、データ(APIやDAO)の3層構造にしています。

なお、Clean Architectureも検討したことはありますが、現状そこまで厳密にはやっていません。なぜなら、Clean Architectureを実現しようとした場合、タマネギの内側から外側へアクセスさせるためにインタフェースを用意するのがめんどくさかったからです。

この依存関係を一方向に保つためのツールとして、DI(Dagger)を使うのはおすすめです。循環参照のような上記のルールを守らない依存関係を作ろうとすると、コンパイル時にエラーにしてくれます。

同じコードを二度書きたくない

この設計の中で、ユースケース層は果たして本当に必要なのかと聞かれることがあります。ビューモデルが直接リポジトリを呼んでいいんじゃないかと。

答えはアプリごとに違うと思いますが、私の現在の環境ではユースケースはあったほうが良いと思います。例えば、ログインの直後にプッシュ通知のトークンを登録するなど、複数のリポジトリを一連の流れで呼ぶことがあります。ログイン処理をただ1つの画面からしか呼ばないのであればよいですが、複数の画面でログイン可能な仕様の場合、この一連の処理をまとめておくことで同じ処理を二度実装しなくてよくなります。

データバインディングもビューの処理を共通化するのに役立ちます。Glideを使った画像の読み込みなど、ほとんど同じ処理を画面ごとに描くのではなく、BindingAdapterを使ってコードは共通化し、XMLで定義できるようにします。

まとめ

以上まとめますと、以下のような点を考慮して今の設計に行き着きました。

  • ビューはすぐに死ぬ前提で考える
  • 依存関係をシンプルにする
  • できるだけコードを共通化する

何がベストな設計かはプロジェクトやチームによって異なるとは思いますが、是非参考にしてください。

Android開発における定番ライブラリ22選

Androidをはじめたばかり or これから始める人向けにまとめました。UI系ライブラリは種類が多すぎるので除外しています。

公式系

1. サポートライブラリ

developer.android.com

※種類が多いのでまとめて1つとカウントしました

Android後方互換性を維持するために、Googleが提供しているライブラリ群です。機能ごとにパッケージが分かれていますが、ほぼ必須のものが多いです。

  • appcompat
  • support-v4
  • multidex
  • design
  • recyclerview
  • cardview
  • etc

2. Data Binding

developer.android.com

レイアウトにデータを紐付けることで、データの更新に応じて自動的にビューを更新することができるライブラリです。レイアウトの属性を増やしたり、findViewByIdを簡略化するだけでも使えます。

以前はButterKnifeというライブラリが使われることが多かったですが、data bindingの方が多機能なので最近はdata bindingの方が人気があると思います。

3. Architecture Components

developer.android.com

Androidフレームワークのライフサイクル関連の問題を扱うことができます。まだ情報が少ないので定番とは言いにくいですが、間違いなくこれから主流になると思います。主に以下4つのコンポーネントからなりますが、LifecycleとViewModelが優先度が高く、Roomが最も優先度が低いです。

  • Lifecycle
  • ViewModel
  • LiveData
  • Room

JSON

4. Gson

github.com

JSON文字列をPOJO (Plain Old Java Object)に変換したり、逆にPOJOJSON化するのに使います。

僕の観測範囲ではGsonが最もメジャーどころですが、他にもJackson, Moshiなどがあります。

Parcelable

5. Parceler

github.com

AndroidにはParcelableというシリアライズの仕組みがあり、画面遷移時のデータの受け渡しなどに使います。Parcelableを使うためにはボイラープレート(お決まりの定型文となるコード)を書く必要があるのですが、Parcelerはこれを自動的に生成してくれます。

KotlinではParcelizeという標準の仕組みがありますが、まだExpetimentalなので実戦投入にはご注意ください。

通信

6. OkHttp

square.github.io

Squareが提供しているHTTPクライアントです。ほとんどのAndroidアプリが採用しているといっても過言ではないかと思います。

7. Retrofit

square.github.io

インタフェースを定義するだけでAPIクライアントを生成してくれるライブラリです。ほとんどの人はOkHttpとセットで使用していると思います。また、後述のRxJavaと組み合わせて、APIの結果をRxJavaのストリームで受け取ることも出来ます。

画像

8. Glide

bumptech.github.io

簡単にサーバー上の画像を読み込んでImageViewに表示することができます。OkHttpと連携することで、画像のダウンロードをOkHttpに任せることも出来ます。

SquareのPicassoもメジャーですが、最近アップデートされていないので今ならGlideを使うほうが無難だと思います。

データベース

9. Orma

github.com

AndroidSQLite用のORMです。高速なIOや自動マイグレーションなど、豊富な機能がたくさんあります。

Architecture ComponentsのRoomも似ていますが、マイグレーション周りはOrmaの方が便利だと思うので僕はOrmaをおすすめします。

10. Realm

realm.io

こちらはNoSQLなデータストアです。高速なIO、簡単に暗号化できる点などが人気があるようです。Android組み込みのSQLiteではなく、完全に別のデータベースを組み込むのでアプリサイズが大きくなるかもしれません。

依存性注入

11. Dagger 2

google.github.io

依存性注入ライブラリの定番です。導入は難しいですが、一度導入してしまえばクラス間の依存関係を綺麗に保ち、テストを書きやすい状態を維持できます。

SquareのDaggerとGoogleのDaggerがありますが、Googleの方が新しくAPIやパフォーマンスが改善されているので基本はGoogleの方を使用しましょう。

非同期処理

12. RxJava

github.com

Reactive Streamsという非同期処理ライブラリのJava実装です。APIやデータベース処理などをストリームとして扱うことができます。RxAndroidと大体セットで使います。

13. EventBus

greenrobot.org

Pub/Subのライブラリです。AndroidフレームワークのBroadcastReceiverに似ていますが、Context以外のクラスでも受信できたり便利です。

使いすぎるとコードがカオスになるので用法・用量を守って以下略。

言語機能系

14. ThreeTen ABP

github.com

Java 8の日付関連のAPIのバックポートライブラリです。

15. Lightweight Stream API

github.com

Java 8のストリームAPIのバックポートライブラリです。mapfilterなど他のプログラミング言語のリストにあるメソッドが使えるようになります。

Kotlinの場合は、Kotlinのコレクションが多機能なので不要です。

ランタイムパーミッション

16. PermissionsDispatcher

permissions-dispatcher.github.io

Android 6から追加されたランタイムパーミッションに対応するためのライブラリです。アノテーションを付けるだけで、パーミッション周りのコードを自動生成できます。

17. RxPermissions

github.com

PermissionDispatcherと同じですが、RxJavaの形式でハンドリングできます。

デバッグ

18. Timber

github.com

ロガー。リリースビルドとデバッグビルドでログの出力を切り替えたり、本番だけCrashlyticsなどにログを送信したりできます。

19. Stetho

facebook.github.io

PCにつないでGoogle Chromeデバッグできます。通信のリクエスト/レスポンスの中身を見たり、アプリのデータベースの中身を見たり、UIの構造を調べたり出来ます。

20. LeakCanary

github.com

メモリリークを自動的に検出してくれるライブラリです。

テスト

21. Robolectric

Robolectric

Android単体テストJVMで実行するためのライブラリです。Android単体テストは通常Androidフレームワーク上でしか実行できないのですが、それだとテストの実行時にエミュレータの起動や実機の接続が必要になるため何かと不便です。Robolectricを使ってJVM上で実行することで、簡単かつ高速に単体テストを実行できます。

22. Mockito

site.mockito.org

テスト時にモックを簡単に作成できるライブラリです。

iOSはじめました

最近仕事でiOSを書き始めた。正直まだ全然書けないのでひたすら本読んだりググったりしながら、練習がてら簡単そうな機能から作っている。

AutoLayout辛い

AndroidのConstraintLayoutの元ネタのレイアウトの仕組み。XcodeGUIでUIを組み立てていくのにまだ慣れない。些細なことでレイアウトが崩れるし、Storyboard開くだけでGitでdiffが出たりして辛みがある。iOS書いてると「なんてAndroid Studioはいい子だったんだ」と再認識するんだけど、原因の8割くらいはAutoLayout関連な気がする。

AutoLayout含め、iOS開発では「お前らXcodeGUIで色々できるようにしといたからそれ使って開発しろよ。それ以上のことやりたい?知るか」的なAppleの思想を感じる。Androidは逆に最低限のGUIしか提供してない代わりに、XMLいじれば大抵の要素をいじれるようにしてくれてる気がする。ConstraintLayoutも、結局XML触るしね。

Swiftはそんなに抵抗ない

もともと書いてなかったけどコード読む機会はそこそこあったので、割とすんなり入れてる。AutoLayoutで消耗しすぎて進捗は著しく悪いんだけど、慣れてくれば普通に書けると思う。今年はKotlinも書き始めたんだけど、Javamよりは文法近いのでなおさら抵抗がないのかもしれない。

ネットの記事やサンプルにたまに出てくるObjectibve-Cは、4~5年前くらいにちょっと書いてたこともあってすでに克服していたのはよかった。

昔より物覚えが悪くなったかもしれない

今回久しぶりに新しい技術を勉強してるわけだけど、20代の頃の自分だったらもっとすんなり習得できたんじゃないかという気がしていて、歳とったんだなとしみじみした。10年前のフレッシュな脳みそが欲しい。

あとは「一人前にiOS書けるようになった」と自信を持つには、簡単な趣味アプリでもいいのでゼロから書いて公開する体験が必須だと思ってるんだけど、いいネタが無い。毎年Appleにお布施を払わないといけないというのも腰が重い理由かも。誰か儲かるアプリのアイデアください。

広告を非表示にする

DroidKaigi 2018でリジェクトされたネタ

DroidKaigi 2018で、「開発者が知っておきたい通知の歴史」というセッションが採択されました。通知のAPIや仕様の変遷を辿り、後方互換姓を考慮した実装をするにはどんな風に書けば良いのかを紹介するセッションです。特に最近Android開発を初めて昔の通知を知らない人に是非聞いてもらいたいと思っています。

一方で、他に応募していた3本のセッションがリジェクトされたので、どんな内容を話すつもりだったかを備忘録的に残しておきます。今後shibuya.apkなど他の勉強会で機会があればショートバージョンにして話すかもです。

データバインディングをもっと使いこなそう

データバインディングの初心者や基本的な使い方しか知らない人向けに、実践的な使い方を紹介する予定でした。具体的には、以下の様な内容をカバーします。

  • BindingAdapter & InverseBindingAdapter
  • ObservableList と RecyclerView
  • アニメーション関連。特にOnRebindCallback
  • MVVMパターン with data binding

過去発表した以下のセッションの内容+αなイメージでした。気になる方はこちらのスライドも見てください。

speakerdeck.com speakerdeck.com

Androidアプリ開発をラクにするCI/CD

今の会社で実戦投入しているCI/CDの事例や小技を紹介するセッションの予定でした。CircleCI Meetupで発表したこのスライドをベースにするつもりでした。

speakerdeck.com

バイスファームのセッションを除くと、CI/CD系のセッションは今回一件も採択されていなかったので需要がなかったのかも?一昔前に比べると情報が見つけやすい気はしますね。

Robolectricで単体テストを書けるようにするには

Robolectricそのもののセッションではなく、Robolectricでテストを書きやすい状態にするための設計のセッションの予定でした。DIの導入やMVWパターン、staticメソッドの潰し方やテストしづらい外部SDKFacebook SDKなど)のラッパーを書く、などの話をする予定でした。改めて応募を見返すと内容が薄そうに見えたので、どこかの勉強会でLTで話せばちょうどいい分量のような気がしました。

総括

結果1勝3敗ということで、DroidKaigi全体の採択率通りの結果でした。来年はもうちょい数を絞って練った応募を出せるようにしたいです。