もやもやエンジニア

IT系のネタで思ったことや技術系のネタを備忘録的に綴っていきます。フロント率高め。

責務を意識してReact/Reduxを使う

rei19.hatenablog.com

  • ↑の続き。仕事でReact/ReduxなSPAを書き始めているのですが、引き継いだコードを読んだり書き直したりして思ったことなど。

TL;DR

  • Componentの仕事はもらってきたpropsを素直に表示するのとEventの発火だけにしような。

FatなComponent

  • なかなかに巨大でやたらRender以外の処理が太ってるReactのComponentだな。。。と思いながらコードを読むと、以下のようなロジックになっていました。具体的なコードは書けないので雑なイメージはこんな感じ

containers/Sample.tsx

const mapStateToProps = (state: GlobalState) => {
    const { hogeList, fugaList } = state;
    return {
        hogeList,
        fugaList
    };
};

const mapDispatchToProps = {
    callGetHogeApi,
    callGetFugaApi,
    callPostHogeFugaApi
}

export default connect(mapStateToProps, mapDispatchToProps)(Sample)

components/Sample.tsx

interface Props {
    hogeList?: Hoge[]; // HogeAPIのレスポンス
    fugaList?: Fuga[]; // FugaAPIのレスポンス
    callGetHogeApi: () => void; // 表示に必要な情報をGetするActionをDispatchするやつ
    callGetFugaApi: () => void; // 表示に必要な情報をGetするActionをDispatchするやつ
    callPostHogeFugaApi: (param: HogeFugaRequestParam) => void; // 更新をPostするActionをDispatchするやつ
}

// 略

export default class Sample extends React.Component<Props, State> {

// 略

    public componentDidMount() {
        this.props.callHogeApiAction();
        this.props.callFugaApiAction();
    }

// 略

    public render() {
        // 各APIのレスポンスが全部揃っているかpropsを見て判定

        // レスポンスが全部揃ってたらrender開始。それ以外はローディング表示
        const piyoList = createPiyoList();
        return (
            // 略
        );
    }

    // Componentの状態をサーバー側に送信する的な処理 
    private onSubmit() {
        // Props/StateからAPIにリクエストするための情報を作成する
        const params: HogeFugaRequestParam = {
            // 略
        };
        this.props.callPostHogeFugaApi(params);
    }

    private createPiyoList() : Piyo[] {
        const { hogeList, fugaList } = this.props;
         // 表示するために必要なpiyoListをhogeListとfugaListをいい感じにマージして作る
        return piyoList;
    }
}

上の例だと表示するために呼んでるAPIは2本ですが、実際には4本とか5本とかあったりします。今の作りでのReact/Reduxなアプリの各レイヤーの責務を見てみると以下の感じになります。

  • Action
  • Reducer
    • APIのレスポンスをそのまま新しいStateとしてReduxStoreに保存する
  • Container
    • Storeから画面で使うレスポンスとdispatchするActionをcomponentに渡す
  • Component
    • APIを呼ぶActionをdispatchする
    • レスポンスから必要な値を抜いて自分が必要な形に加工する。またcomponentによってはそれをstateに保存していたりしている。
      • 加工のためのutilityあるいはhelperという名で切り出されたロジックが大量にある。または各component内のprivate関数で重複して存在しているものもある
    • APIに投げるパラメータを作る(ActionのIF === APIのIFになってる)

という感じで、API呼ぶ->storeにレスポンスが保存される->containerはそれをcomponentにスルーパス->componentが色々頑張るといった形になっていて、componentにロジックが集中する作りになってます。

どうやってcomponentを薄くするか

今の作りの問題は以下の点です。

  • Propsとして生のAPIのレスポンスを受け取って自分で加工しているため、componentはAPIのレスポンスを意識しなければいけなく、そのための余計なロジックを実装しなければいけない。
  • Actionを通り越してAPIの詳細な実装をcomponentが意識しなければいけない。

本来、Reduxに状態の管理を移譲することでReactのComponentは渡ってきたPropsを素直に表示するだけという作りになるはずなので、componentではなくてcontainerに仕事をさせてcomponentが望む形に加工したものを渡すようにします。また、Action周りも実装を意識させないようなIFにしてAPIの存在をAction内に閉じ込めます。修正後はこのような形になりました。

containers/Sample.tsx

const mapStateToProps = (state: GlobalState) => {
    const { isLoading, hogeList, fugaList } = state;
    const piyoList = createPiyoList(this.props.hogeList, this.props.fugaList);
    return {
        isLoading,
        piyoList
    };
};

const mapDispatchToProps = (dispatch: Dispatch<GlobalState>) => {
    return {
        onStart: () => {
            dispatch(fetchHogeFugaList());
        },
        onSubmit: (name: string) => {
            dispatch(createPiyo(name));
        }
    }
};

export default connect(mapStateToProps, mapDispatchToProps)(Sample)

components/Sample.tsx

interface Props {
    isLoading: boolean;  // 読み込み中か判定
    piyoList: Piyo[]; // 画面で表示するPiyoの一覧
    onStart: () => void; // 画面レンダリング開始時のイベント
    onSubmit: (name: string) => void; // 新しいPiyo作成時のイベント
}

// 略

export default class Sample extends React.Component<Props, State> {

// 略

    public componentDidMount() {
        this.props.onStart();
    }

// 略

    public render() {
        if (this.props.isLoading) {
            return (
                // くるくる表示する
            );
        }

        return (
            // PiyoList表示する
        );
    }

    private onSubmit() {
        // 実際にはこのへんもonChangeで全部reduxに流すのでstateは無くなる。
        this.props.onSubmit(this.state.name);
    }
}

という感じになりました。変更後の責務は以下の通り。

  • Container
    • Storeから画面で使うレスポンスとdispatchするActionをcomponentに渡す
    • Storeから必要なレスポンスを加工してcomponentに渡す
    • componentで発火するイベントに対応するActionをmappingする(mapDispatchToPropsの通りですね)
  • Component
    • APIを呼ぶActionをdispatchする
    • レスポンスから必要な値を抜いて自分が必要な形に加工する。またcomponentによってはそれをstateに保存していたりしている。
      • 加工のためのutilityあるいはhelperという名で切り出されたロジックが大量にある。または各component内のprivate関数で重複して存在しているものもある
    • APIに投げるパラメータを作る(ActionのIF === APIのIFになってる)
    • containerから受け取ったpropsを表示する
    • 画面で発生するライフサイクル/ユーザーのアクションのイベントをcontainerに通知する

また、複数API呼んでいたところは1つのアクションとして再定義しています。非同期部分はもともと redux-promise を使ってたのでそのまま使って、Promiseでまとめて2本走らせて両方取れたらreducerに回るようにしています。

actions/fetchHogeFugaList.ts

export function fetchHogeFugaList(): FetchHogeFugaListAction {
    return {
        type: FETCH_HOGE_FUGA_LIST,
        payload:  Promise.all([
            axios.get(GET_HOGE_LIST),
            axios.get(GET_FUGA_LIST),
        ]
    };
} 

おわり

  • このように対応を入れたことでcomponentの見通しが良くなり、componentがAPIを意識しなくなりました。また、メリットとしてテストが格段に書きやすくなりました。この記事の例だと大したことなさそうなのですが、実際には大量のPropsが定義されていてテストデータを作ろうにも本当に必要な情報はどれなんだーという感じだし、イベントの確認もAPIと密結合しているので大変でした。
  • reduxをちゃんと使えばreactのcomponentは薄く保つことができ、Viewとロジックを分離できるようになるので意識して書いていきたいですね。
    • まだredux触り始めな感じなので理解が間違ってたらコメントください m( )m

Webの仕事に戻ったのでReact-ReduxをTypeScriptで再入門してる

5月から知り合いが立ち上げた会社を手伝っていてB向けのWebサービスをspaで作ってるのですが、ここ2年くらいはほぼAndroidの仕事しかしていなくて、2年もたてば昔の知識は陳腐化している(というか忘れかけている)ので改めてチュートリアルやったり本読んだりしてます。今までReactをちゃんと仕事で使う機会もなかったのでちょうどいい機会かなと。

とりあえずTodoアプリから

  • 今の仕事は React/ReduxをTypeScriptで書いているので、それに近い感じでサンプルを作りました。yarnでパッケージ管理してwebpack2でbundleしてdeserverで配信みたいな感じ。テストのフレームワークはReactのチュートリアルに従ってJestを使ってます。あとはこれをベースにもうちょっとちゃんとしたアプリを作っていこうかなと。

GitHub - rei-m/typescript_react_redux: Sample of TypeScript/React/Redux with Webpack2

読んでよかったもの

Reactビギナーズガイド ―コンポーネントベースのフロントエンド開発入門

Reactビギナーズガイド ―コンポーネントベースのフロントエンド開発入門

github.com

おわり

  • 久々にWebのフロント書いてるけど楽しい

KotlinとDataBindingとMVVMとか

今までDateBindingをButterKnifeの代わりのような使い方しかしてなかったので、ちゃんとMVVMっぽい作りもやってみようということで前に作ったアプリをごそっと書き換えてみました。アプリはKotlin製です。

rei19.hatenablog.com

そもそものMVVM

  • 以下の記事・スライドを参考にしてます。こういうアーキテクチャ系の話の原点って何を探ればいいのかちょっとわからなかったので印象に残った記事を読みこんでます。

ugaya40.hateblo.jp

qiita.com

techblog.reraku.co.jp

techblog.reraku.co.jp

speakerdeck.com

  • 自分の中で噛み砕いたポイントとしては以下の点
    • MVVMのコンテキストでのModelはプロパティの公開と戻り値のないメソッドだけを実装している。ここでいうModelは例えばDDDのコンテキストでのDomainModelのようなものを指しているわけではないので切り離して考えること。
    • ViewModelはModelを監視している。メソッドの呼び出しによりModelの状態が変更された場合はその変化を翻訳してViewに伝える。
    • Modelは内部の状態が更新されたらViewModelに更新通知を送る
  • ※ 勘違いしてたらコメントください。。。

とりあえず作ってみよう

  • このアプリでははてぶの情報を取得するために、対象のユーザーのはてなのIDをSharedPreferencesに持っていていつでも更新することができます。なのでできることはユーザーIDの公開、ユーザーIDの更新です。

Model

  • ModelはシングルトンでViewModelにDIしてます。このアプリではユーザーIDを設定するダイアログとその呼び元のActivityのViewModelそれぞれでUserModelの更新イベントを監視しています。なのでユーザーIDが更新されたら呼び元のActivityも同時に更新されます。

UserModel.kt

    var user: UserEntity = getUserFromPreferences()
        private set(value) {
            field = value
            storeUserToPreferences(value)
            userUpdatedEventSubject.onNext(value)
        }

    // イベントを流す用のPublishSubject
    private val userUpdatedEventSubject = PublishSubject.create<UserEntity>()
    private val unauthorisedEventSubject = PublishSubject.create<Unit>()
    private val errorSubject = PublishSubject.create<Unit>()

    // PublishSubjectをObservableに変換して公開。PublishSubjectのままだとonNextが呼び元で使えてしまう
    val userUpdatedEvent: Observable<UserEntity> = userUpdatedEventSubject
    val unauthorisedEvent: Observable<Unit> = unauthorisedEventSubject
    val error: Observable<Unit> = errorSubject

    fun setUpUserId(userId: String) {

        // ここは http://b.hatena.ne.jp/[UserId]/ を叩いて200が返って来るかを確認して存在するユーザーかチェックしている
        hatenaBookmarkService.userCheck(userId).map {
            // 特定の記号が入っている場合にTopページを取得しているケースがあるのでトップページが返ってきたら 存在しないユーザー = 404として扱う
            return@map !it.contains("<title>はてなブックマーク</title>")
        }.onErrorResumeNext {
            if (it is HttpException) {
                when (it.code()) {
                    HttpURLConnection.HTTP_NOT_FOUND -> {
                        Single.just(false)
                    }
                    else -> {
                        Single.error(it)
                    }
                }
            } else {
                Single.error(it)
            }
        }.subscribeAsync({ isValidId ->
            // Model内でスレッドを指定して配信。subscribeAsyncは拡張関数
            if (isValidId) {
                // 有効なIDだったら渡されたIDを内部に保存
                user = UserEntity(userId)
            } else {
                // 無効なIDだったら認証できなかったイベントを発行
                unauthorisedEventSubject.onNext(Unit)
            }
        }, {
            // 通信エラーなどの場合は一律エラーのイベントを発行
            errorSubject.onNext(Unit)
        })
    }
  • ここでModel内のUserが更新されたらSharedPreferecesに保存して、userUpdatedEventを発行してます。
    var user: UserEntity = getUserFromPreferences()
        private set(value) {
            field = value
            storeUserToPreferences(value)
            userUpdatedEventSubject.onNext(value)
        }

ViewModel

  • ViewModelはonStartでModelのイベントの監視を開始、onStopで解除という感じにしてます。
  • DataBinding周りでProgressDialogとかSnackBarとか表示したい時はEventBus経由でActivityに通知しています。。。が、もっといいやり方がある気がします。
    • TwitterでアドバイスをもらってProgressDialogはViewModelにDIしたり、Activity/Fragmentにどうしても何かさせたい場合はViewModelがEventを公開してActivity/Fragment側でそれを監視するようにしました。EventBusは見通しが悪くなるのでこちらの方が追いやすいですね。

EditUserIdDialogFragmentViewModel.kt

    override fun onStart() {
        super.onStart()
        // Modelから通知されるイベントを翻訳してViewに伝える
        registerDisposable(userModel.userUpdatedEvent.subscribe {
            progressDialog.dismiss()
            idErrorMessage.set("")
            userId.set(it.id)
            dismissDialogEventSubject.onNext(Unit)
        }, userModel.unauthorisedEvent.subscribe {
            progressDialog.dismiss()
            idErrorMessage.set(userIdErrorMessage)
        }, userModel.error.subscribe {
            progressDialog.dismiss()
            snackbarFactory?.create(R.string.message_error_network)?.show()
        })
    }

    override fun onResume() {
        super.onResume()
        userId.set(userModel.user.id)
    }

    fun onClickSetUp(view: View) {
        progressDialog.show()
        userModel.setUpUserId(userId.get())
    }

おわり

  • Modelのメソッド呼び出しの結果をイベントベースで受け取るのはメソッドでObservableを返すよりわかりやすいかなと思いました。その場合はエラーハンドリングでどんなエラーが流れてくるか内部の実装を知っていなければならないので発生しうるイベントとして公開されてる方がModelを呼ぶ側は使いやすいです。

  • コードはこちら。主要な画面だけDataBindingとViewModelで書き直してます(わりと前に書いたものがベースなのでちょっと変なところがあるかも)。

百人一首暗記するアプリ作ってからの振り返り

rei19.hatenablog.com

  • 上の記事から3ヶ月たったので、数字とかやったこととかの振り返りメモです。

3ヶ月たった時点の数字

項目 数値 取得元
インストール 13,500(うちアクティブは5,500) play store
平均評価 4.382 play store
レビュー/評価数 31/76 play store
DAU 400 ~ 600 (うち新規は100 ~ 150くらい) Fabric
Crash率 99.50% Fabric
AdMobからの収益 飲み会1回分くらい/month AdMob

リリースしてからやったことなど

Bug-Fixの対応

  • 4.1系だけ札が真っ黒になる。
  • カスタムフォントの使い方がまずくてOOM出てた。

機能追加

  • レビューでもらった要望や自分でこれはあってもいいかなと思ったものは追加していった。
  • 読み上げの要望が何個か来ていたけどアプリのコンセプトには合わないかなと思ってるのでその辺は対応してない。シンプルが一番。

ASO

  • 百人一首"、"百人一首 暗記"で上位に来るようにアプリ名やら紹介文やら変えて様子を見た。後半はPlay StoreでABテストもしてみたけど有為な差が見られなかった。多分、僕の対抗馬の出し方が悪い。
  • 今のとこ"百人一首"は2位、"百人一首 暗記"は1位を取れてる。

レビューの返信

  • Googleの中の人のアドバイスに従ってレビューの返信をできるだけ頑張ってやってみた。

気づき

  • ニッチなジャンルでそんなに使われないかなと思ったけど、思ったよりインストールされたしDAUも安定してる。それなりに競合のアプリもあったがあまり更新されてないものも多いので、丁寧に作り込んで検索で引っかかるようにすればちゃんと使ってもらえる。
  • 上述のバグが原因で1点のレビューしてた人がいたけど、直した連絡をレビューの返信でしたら5点に変えてくれた。少なくとも低い評価のレビューしてる人にはちゃんとケアしてあげるとよさそう。
  • Firebaseを入れてみたけど、想定してた数字が取れていないので使い方の認識がズレてるとこがある。ドキュメント読み直して手を入れたい。

RecyclerViewにインクリメンタルサーチをくっつけたライブラリを作った

こんな感じでRecyclerViewにインクリメンタルサーチくっつけたやつを作りました。ライブラリを公開するのは初めてだったりします。

https://github.com/rei-m/filter-recyclerview/blob/master/images/demo.gif?raw=true

github.com

僕はAndroidアプリの開発を仕事として関わり始めたのが Lolipop が出たくらいのときでわりと後発です。特に凝ったことをしない限りはやりたいことを実現するライブラリはだいたい用意されていて、自作のライブラリを作る機会もなかったのですが、上で貼ったキャプチャのViewを作る要件に対応するライブラリはさくっと見つからず。。。

MsvSearchというライブラリがそれっぽい動きをしたけどViewやイベントの拡張ができなくて入れられなかったので、動きの部分だけ参考にして自前で書きました。で、せっかくなのでたいしたコードでもないけどお試しでライブラリ作るにはちょうどいい機会かなと思って、共通化できる部分を切り出して公開してみました。

だいたいREADMEに導入の仕方は書いておきましたが、導入側はフィルターの条件とRecyclerViewの表示部分だけを実装すればいいように作ってあります。

公開はJitPack.ioを使ってGitHub経由で落とせるようにしたのでandroid-mavenプラグインを突っ込むだけでした。お手軽ですな。BintrayにアップロードしてさらにJCenterに・・・というのは今回はやらなかったです。

TextViewでカスタムフォント使ったら InflateException が出るようになった

先日、下のアプリをリリースしました。で、ありがたいことに正月の暇つぶしに使ってくれてるのか、ちょこちょこインストールされてるのですが、CrashlyticsにInflateExceptionが結構な頻度で飛んでくるのに気付きました。

rei19.hatenablog.com

開発中の実機確認は自分の持ってるNexus5xを使っていて問題なかったのですが、試しに嫁が使っている割と古めのXperiaで動作確認してみると確かに落ちました。。。しかも落ちるタイミングが不定期なのでOOMっぽい。↓の画面のViewを作成しようとしたタイミングです。

f:id:Rei19:20170104231035p:plain:w150

原因と対応

  • このViewの札の部分はカスタムViewにしてありました。できるだけ本物の札っぽくみせたかったので縦書きにしてフォントもIPAフォントをカスタムしたものを使っていたのですが、そこの内部がよくありませんでした。
Resources resources = context.getResources();
Typeface typeface = Typeface.createFromAsset(context.getAssets(), resources.getString(R.string.app_font_file));     
setTypeface(typeface);

まあ見ての通りですが、Viewを作るたびにフォントファイルを読み込んでたので、表示のたびにめちゃくちゃメモリを使っていたというオチでした。Typefaceをシングルトンにして一回しか読み込まないようにして解決できました。

  • ↓の画像はFabricのクラッシュ数のグラフです。インストール数の増加に応じてクラッシュ数が増えていくのがわかりますが、対応後は激減しましたね。今回はちょっと確認が甘かったので反省。

f:id:Rei19:20170104234545p:plain:w300

ちはやふるにはまったので百人一首を暗記するアプリ作った

今年もぼちぼち終わりですね。さて、毎年1個くらいプライベートで何かWebサービスなりアプリなりリリースすることを目標にしてるんですが、今年はちはやふるにはまったのがトピックとしてあって、百人一首に興味が湧いたので暗記用のアプリを作りました。

※ちなみに ちはやふるはこちら。勧められて観る前は恋愛ものかなと思ってたらスポ根青春もので展開が熱かったです。開発合宿で聖地巡礼したりしましたね。

アプリはこちら (Androidのみ)

play.google.com

技術的な話

  • 仕事ではkotlinでアプリ書いてるので、今回は一周回ってJavaで書きました。Jack & Jillとか新しいツールも出てきてるし、メインストリームに乗っかったアプリを手元に置いておきたいなあという気持ちからJavaにしてます。
  • 技術的には目新しいことはしてないのですが、個人的に今回初めて使ったのは以下のもの
    • Orma
    • RxJava2
    • BottomNavigation
  • Ormaを使った理由も、仕事でRealm使ってるのでDB使うならSQLiteがいいなあってことで選択しました。一長一短あるなと思ったのですが、Realm使うとRealmに依存する設計になるので、個人的にはOrmaの方が自分の好みには合ってるかなと感じました。あとAuto Migrationが圧倒的に楽ですね。(まあアプリ自体は別にDBなくても作ることができる規模なのでこの辺は使いたいから使ったという感じ)
  • RxJava2はだいぶインターフェース変わったので、思ったより学習コスト高かった印象です。まだMaybeの使い所がよくわかってない。。。
  • そんな感じで技術的なチャレンジはあまりできてないのですが、目標のアウトプットはできたかなという感じで、仕事も気分良く納まることができました。来年は何作ろうかな。

コードはこちら

  • セキュアな情報は含まれてないのでローカルでビルドするには自分で足りないものを埋める必要があります。

github.com