ベータコンピューティングの活動や技術、開発のこだわりなどを紹介するブログです。



【IT×他業種インタビュー】第1回:運輸業 野々市運輸機工株式会社 代表取締役 吉田章様

こんにちは。Beta Computing株式会社の吉村です。

ITの活用がどの業界でも叫ばれるようになってから数年が経ちました。
しかし、現場レベルではまだまだ浸透しているとは言えず、活用しきれていないと感じることが多くあります。
その度に弊社は皆様にとってどのような存在でいればよいのか、兼ねてより、より具体的に価値を見出そうと考えておりました。

どのような価値を提供できるのか──。
どのような存在になれるのか──。


皆様が、どのような業務をこなし、どういった課題に直面し、どんな対策や取り組みを行っているのか、まずは知らなければならない。
であれば直接話を伺う方が正確で早いと、インタビューする企画を思いつきました。

IT×運輸業インタビュー

第1回目として取材させていただきましたのは、運送事業をメインに手掛ける 野々市運輸機工株式会社 の代表取締役である吉田章さんです。
よろしくお願いします!



大手がやりたがらないものをやる。そこにニーズがある。

──事業内容を教えて下さい。

吉田さん:
お客様にあった物流を提案させていただき、お客様にあった運送を行っています。 主に、北陸3県を範囲とした運送と北陸-大都市圏の運送がメインです。 様々な運び方がありますが、主力の1つに重たくて長いモノに特化した運送サービス"メタル便"があります。
全国に構成された運送ネットワークを使い、北は北海道から南は九州までリレーのバトンを渡すように目的地まで荷物をお届けしております。
メタル便は全国を網羅できるよう中小企業7社で作っています。

──7社はどうやって?

吉田さん:
メタル便の歴史は古く、2000年から開始されているサービスになります。
メタル便は長尺物や重量物を運送するサービスですが、この長尺物や重量物というのは大手運送会社が嫌がる荷物で、業界では「ゲテモノ」呼ばわりされていました。
大手が運送の対象物としなかったことで、それらを運ぶ需要が生まれました。
関東では多くの重量物が運ばれ、大阪では長尺物ばかり集まっていたようです。 「総合トラック」という会社が中心となり、関東と大阪をサービス圏にメタル便が開始され、それが2000年になります。
弊社は2016年度に北陸地域の運送会社として加入し、現在では7社となっています。


──メタル便をはじめてみて反響はありましたか?

吉田さん:
メタル便が利用できるからこそ商売を続けられる会社さんもいらっしゃいます。
メタル便として北陸地域に向けてDMをうった次の日の朝一番から「こんなサービスがあるのか!」とDMを握りしめたお客様が訪ねてきました。
「メタル便がなければ商売をやめていた」と言われたこともあり、お客様から求められていることを強く実感できました。

現在、働き方改革や2024年問題によりドライバーが不足しており、今後も需要が高まると予想されます。
さらにはガソリン高騰によって大手企業の費用も高くなっているので、メタル便に注目が集まっています。

──御社の強みをお聞かせください。

吉田さん:
北陸エリアでの混載・共同配送を得意としております。
また、メタル便では大手が引き受けない長尺物・重量物の全国運送を行っています。
その他では、大都市圏の大手企業が北陸まで荷物を運ぶのは手配の手間やコストがかかるということで、北陸に拠点(ヤード・倉庫)を作りたいという企業が増えてきました。
これまでは、高速道路の整備やトラックの普及が進み、地方の在庫が無くなっていき、東京や大阪に集約される動きでした。
ところが、長距離ドライバーの労働時間規制の動きが大きくなり、大手企業はコンプライアンス違反を気にするようになったため、地方に在庫を確保し工期に合わせて運送するような形に変わっていきました。それにより、保管業務の依頼が増えてきています。
弊社は機械等を運ぶだけでなく、お客様の工場内へ搬入し据え付けまで行います。
大型機械等の移動も専門に行っており、お客様の工場内にある機械のレイアウト変更などすることも可能です。


──お客様の業種は?

吉田さん:
製造業、建築業など、大きくて重たいものを運ぶ必要がある業種です。
機械装置や、鋼材・鉄・ステンレスの素材、木材など建築資材を運送します。

──現場の業務の流れを教えて下さい。

吉田さん:
現在40人ほどのドライバーさんがいます。ドライバーは長距離ドライバーと地場ドライバーにわかれます。
長距離ドライバーは北陸3県から大都市圏にモノを持って行く、大都市圏から北陸にモノを持って帰ってきます。
地場ドライバーは北陸3県内にモノを持って行きます。毎日日帰りになります。
長距離ドライバーは泊まりになることが多いです。1日かけて運送します。

──長距離ドライバーは県を跨ぐことになります。コロナの影響はありましたか?

吉田さん:
県を跨ぐことによる影響ですが、ドライバーは1人の時間が長いので、感染者もなく、県外には行くが他の人と触れ合う機会は少ないので感染者が出た等は特にありませんでした。
ただ、お客様の出荷が止まってしまったため、売上に大きく影響がありました。

──業務の中で課題はありますか?

吉田さん:
課題はたくさんあります。
外部環境としてコロナが落ち着きそうで落ち着かないことと、さらにはウクライナでの戦争も始まってしまいました。
原油高が非常に辛く、同じ距離(少ないくらいなのに)で昨年度より1千万円のコスト差が出ております。
どうしても外部環境の影響を受けてしまいますね。

社内では、直接のコミュニケーションを取りづらくなってしまいました。
飲み会や食事でのコミュニケーションが減り、細かな情報共有や社員の調子などわかりづらくなっています。
チームワークが重要であるのに、それを強める機会が減っています。

IT導入はスモールスタートが良い。受け入れてもらうことが大事。

──情報共有について、ITツールを使用していますか?

吉田さん:
ITや情報に興味があり、10年ほど前から会社の基幹システムを入れ替えました。
また、社員とのコミュニケーションでいうと、2018年に社内でスマートフォンを支給しました。
スマートフォンの普及が進み、父親60代でも使えているのを身近で感じたこともあって、全社員に渡しました。
一番の目的はチャットツールを利用するためです。

支給前の業務連絡は電話でを行っており、例えば、どこにモノを降ろしました、卸し終わりました、どこに向かっていますなど、社員みんなが電話を掛けるため、つながらないことがしばしばありました。
以前から電話での情報共有に不満があったので、業務連絡は基本電話禁止し、全てグループチャットでやることにしました。
つながらない、折返し、などの作業の無駄が無くなり、また、エビデンスとして残るようになったため、言った言わない問題も無くなりました。
注意事項の情報共有など、すぐに周知できるのも良いところです。

──ちなみに支給したスマホはiPhone?Android?

吉田さん:
通信会社から良い提案があったので、Android端末を支給しました。
格安スマホなどもまだ無かった中、ショップでは無理でしたが、通信会社と直接交渉したところ、安く提案いただけました。

──スマホを支給したことによる社員の反響はありましたか?

吉田さん:
60代社員でも使えており、業務中の電話がすごく減りました。
1人だけ64歳の人が3日たっても電源の入れ方がわからないと戸惑っていましたが、すぐに解決しました。
1週間で電話からチャットワークの体制に変更できたのは良かったです。

また、情報のやりとりがグループチャットになので、誰がどこで何をしているのかの会話が見えるようになりました。 当事者同士の会話が見えなかった以前は、あいつばっかり楽をしているではないか等の不満が募っていたのが、グループチャットだと他の人の苦労が見え、他人への不満が減りました。

──チャットワークを選んだ理由を教えて下さい。

吉田さん:
みんなが使いやすいシンプルなのはチャットワークかなと思い選びました。
使用に対する社員からの声は特にありません。ただ、何もないことは良いことだと思っています。

チャットワークにはAPIの提供があるので、それを利用していけばいろいろな情報を自動的に社員に発信できるようになります。 自分で調べながら工夫して進めています。
例えば、ありがとうカードをチャットワーク上で行えるようにしました。
ありがとうカードとは、他人への感謝を伝える取り組みになります。
ドライバーは孤独な作業が大半であり、会社で褒められることが多くありませんので、社員同士で感謝の言葉を紙に書いて社内に設置したポストに入れるようにしていました。 今では会社のカルチャーとなっています。
ただ、これまでに何千枚と紙が使われていた上、外出中のドライバーでも利用しやすいように、ありがとうカードをチャットワークに移行しました。
Googleフォームとスプレッドシートとチャットワークを連携し、自動で配信・集計するようにしています。
加えて、くじびき機能もつけて100分の1で当たりが出るという、少し遊び要素も入れています。

──社内・社員のITに対するイメージは変わりましたか?

吉田さん:
根本は変わっているわけではないですが、慣れていっていると感じます。
ITを勉強しているわけでは無いので、プログラミングできる人が増えましたとか、どんどんITツールを提案してくる人が増えたということではありませんが、ITツールを使いましょうということにたいしては受けいれてくれます。
コミュニケーションインフラとしてチャットワークもみんな利用してくれています。

現在、これまで紙で管理していたものがどんどん電子化していってます。
FAXをpdfで保存し、サーバーからGoogleドライブに自動保存し、自動でチャットワークに配信するようにしました。
FAXもできるだけ出力しないようにしています。
ただ、お客様側がFAXなので、現状は完全に無くすのは難しいです。

──業界ではITやIoTの活用は進んでいない?

吉田さん:
同業者はまだIT化が進んでいないと思います。
IT導入は、スモールスタートで費用をかけずに進めていって、ここから先は自分たちでは無理だと感じたときに本業のソフトウェア会社に依頼できるような流れが良いと思います。
自分たちで少しでもITを理解、挑戦していくことが必要だと思っています。
弊社としても同業者にITを普及させていきたいと考えています。

今後も積極的にITを活用していく。AI分野にも興味がある。

──新しいIT活用に興味・関心はありますか?

吉田さん:
興味がありすぎて・・・

Withコロナは今後も続いていくと思っています。
人が集まれる機会や時間が少なくなって、本来はもっと集まって社員教育やコミュニケーションを取れればと思っています。
現状は、社員教育をスマートフォンで見る動画のサービスを利用しています。
年に3回くらいの集合型もあったりしますが、まだまだ少ないと感じます。
最近ではそれが難しい時代と考えて進めていった方が良いと捉えるようになりました。
さらにITツールを活用し、社員教育を改善できればと思います。

また、現在は運送業とIT業のコンソーシアムに参加しています。
1日に百枚~千枚という数のFAXが届くので、紙から電子化をAIを使って自動化できないか実験を行っています。
FAXから自動で情報を取得というのは、AIが進化したからといって自由記述が多いとやはり難しいとわかってきました。
ですので、現時点ではソーター(仕分け作業)だけでも自動化できないかと考えています。

──今後、連携したい他業種はありますか?

吉田さん:
やはりIT企業ですね。
IT化進み、ITが現実空間を飲み込んでいると感じています。

様々なIT企業が物流業界に参入してきてますが、まだまだ攻略できてないのが現状だと思います。
どこもイニシアチブをとれたと言えるところまでは行っていません。

物流の全部は難しくても、セグメントでわけることで運送でシステム化をめざしていくといいのではと思っています。
メタル便はそれの一つになりうるかもしれません。

──以上になります。ありがとうございました。

吉田さん:
ありがとうございました。

野々市運輸機工株式会社様 連絡先

〒920-0211 石川県金沢市湊1丁目55番地23
野々市運輸機工株式会社
代表取締役 吉田 章
https://nonoichiunyu.com/

日本標準産業分類

大分類:運輸業
中分類:道路貨物運送業
小分類:一般貨物自動車運送業


おわりに

普段聞けない大変貴重なお話をお聞きすることができました。
業界の動向や、ITの取り組み方、ITに対する捉え方など、勉強になることが大変多くありました。
60代の社員がいらっしゃる中で、社内のスマートフォン導入がスムーズに進んだことは驚きでした。

吉田さん、お忙しいところインタビューを快くお引き受け下さり、本当にありがとうございました!

本内容が少しでも皆様のご参考になりましたら幸いです。
今後も他業種インタビューを更新していければと思いますので、次回をお楽しみに!

Jetpack Composeに入門してみた

弊社Android・クロスプラットフォーム担当のd-ariakeです。
先日 Jetpack Compose の正式版がリリースされたので、さっそくうちでも試してみることにしました。

作ったもの

以前の記事 でご紹介したQiitaの簡易クライアントアプリと同じものを今度はJetpack Composeで実装してみました。
リポジトリはこちらです。
https://github.com/BetaComputing/SimpleQiitaClientAndroid/tree/compose

イメージ

良いと思った点

Jetpack Composeを使ってみて、4点ほど良いと思った点があったのでご紹介いたします。

角丸などの細かなUIデザインが簡単

このアプリでは ユーザアイコン画像記事タグ に角丸を設定しています。
従来のViewでは、角丸を設定するのにbackground用のdrawableを作らないといけませんでした。
(参考: AndroidでViewを角丸にする - Qiita)

しかし、Jetpack ComposeではModifierで

RoundedCornerShape(corner = CornerSize(4.dp))

をセットすることで、簡単に角丸を実現することができます。
(該当コード: アイコン画像, 記事タグ)

また、ripple effect を付けたい場合も、

indication = rememberRipple()

をセットすることで、簡単に実現することができます。
(該当コード: 記事項目, 記事タグ)

このように、細かなUIの作り込みはJetpack Composeの方がラクに実現できるかと思います。

リストUIが簡単

従来のViewでは RecyclerView を使ってリスト系のUIを実装していたと思います。
RecyclerViewではAdapter/ViewHolderの実装や、リストの変更通知の仕組みが大掛かりになりがちで大変だったと思います。

Jetpack Composeでは、描画の仕組みが従来から大きく変更されているので、RecyclerViewのようなViewを使いまわしたり、細かな変更通知を行う仕組みが不要になりました。

LazyColumn を使って、

LazyColumn(
    modifier = modifier.scrollable(state = rememberScrollState(), orientation = Orientation.Vertical),
) {
    items(items = articles ?: emptyList(), key = { article -> article.id }) { article ->
        ArticleView(
            article,
            onArticleClicked = viewModel::onArticleClicked,
            onTagClicked = viewModel::onTagClicked,
        )
    }
}

このようにスッキリ書けるようになりました。
(該当コード)

ただし、まだスクロールバーまわりの機能が弱いみたいなので、今後の進化に期待です。🚀

MVVMパターンの考え方がJetpack Composeでも通用

このアプリでは、UI以外の部分 (ViewModelから上位のレイヤ) に対してほとんど手を加えずにJetpack Compose化することができました。
既存のコードがMVVMパターンで設計されている場合、ViewModelから決まってくる状態の、UIへの紐付けの記述の仕方が少し変わるくらいで、従来とほとんど変わらない設計になると思います。
既存の知識があれば、ほとんど学習コストを掛けずにに対応できると思われます。

参考: 状態と Jetpack Compose | Android Developers

既存のアプリにも部分的に組み込み可能

Jetpack Composeには ComposeView という従来のViewにJetpack ComposeによるUIを組み込むための仕組みが用意されています。

このアプリでも ↓ のコミットで、RecyclerViewのみを部分的にJetpack Compose化し、検索用UIの部分などは従来のViewのままで実現するといったことをしてみました。

記事リスト部分をJetpack Composeを使って実装 · @9e4c88d

xml中での RecyclerView 使用箇所を ComposeView に置き換えて、

<!-- リスト部分 -->
<androidx.compose.ui.platform.ComposeView
    android:id="@+id/articleList"
    android:layout_width="0dp"
    android:layout_height="0dp"
    android:visibility="@{viewModel.isProgressBarVisible ? View.GONE: View.VISIBLE}"
    app:layout_constraintBottom_toBottomOf="parent"
    app:layout_constraintLeft_toLeftOf="parent"
    app:layout_constraintRight_toRightOf="parent"
    app:layout_constraintTop_toTopOf="parent" />

ComposeView#setContent{} でJetpack Composeで作ったUIをセットしてあげるだけでした。

//  一時的に記事リスト部分のみJetpack Composeで実装する。
this.binding.articleList.setContent {
    ArticleList(viewModel = this.viewModel, onArticleClicked = this, onTagClicked = this)
}

(該当コード: main_activity.xml, MainActivity.kt)

このようなことができるので、新規で開発する部分やJetpack Composeの恩恵を受けながらリファクタリングしたい部分だけでも、かんたんに導入することができます。

参考: 相互運用 API | Jetpack Compose | Android Developers

おわりに

私たちBeta Computing株式会社は、石川県にあるスマホアプリ開発会社です。
Kotlin・Swiftによるスマホアプリ開発も、FlutterやXamarin.Forms、Unityによるクロスプラットフォームのスマホアプリ開発も、どちらも得意としているスマホアプリ開発のプロフェッショナルです。

Jetpack Composeに限らず、FlutterやSwiftUIに関しても幅広い知識を持っていますし、従来の開発手法に関しても確かな経験と実績があると自負しています。
スマホアプリ開発をご検討されているのでしたら、是非私たちBeta Computing株式会社におまかせください! 業種・ジャンル問わず対応可能ですので、ぜひご相談下さい。

Flutterでパズルを作ってみた話

弊社Android・クロスプラットフォーム担当のd-ariakeです。

弊社でもクロスプラットフォーム開発においてFlutterを採用しています。
今回はFlutter for Webでシンプルなパズルを作ってみたので、紹介させていただこうと思います。

作ったもの

このようなパズルを作ってみました。

flutter_puzzle

GitHub Pagesに置いてあります。
ぜひ遊んでみてください。
https://betacomputing.github.io/flutter_puzzle/

ソースコードはこちらに置いてあります。
https://github.com/BetaComputing/flutter_puzzle

Flutter for Webについて

3/4に Flutter 2.0 がリリースされましたが、その際にFlutterのWebサポートがstable化しました。
私もなにかFlutterでWebアプリを作ってみたいと思ったので、さっそくこのパズルを作ってみました。

特に手動で有効化設定を行わずともWebサポートが有効化されているので、

flutter create --org jp.co.betacomputing --platforms web ./flutter_puzzle

といったコマンドでWeb用のFlutterプロジェクトが作成することができます。

Webアプリ用ビルドは

flutter build web --web-renderer html

というコマンドで行うことができます。

上記ビルドコマンドにもオプションとして指定していますが、Flutter for Webには htmlcanvaskit の2通りのレンダリング方式があります。
それぞれダウンロードサイズの削減・他プラットフォームとの互換性とパフォーマンス性というメリットがあるようです。

ですが、現状はCanvasKitによるレンダリングにおいて正しく文字列が描画されないというバグがあるようなので、 --web-renderer html を指定したほうが良さそうです。

参考:

スライドアニメーションについて

このパズルを遊んでもらうとわかると思いますが、ピースを選択するとスライドアニメーションが再生されるようになっています。
これは AnimatedPadding を利用して実現させています。

パズルのピースを配置するコード は以下のとおりです。
各ピースの左と上のパディングを設定することによって任意の位置に配置するという実装アプローチを取っています。

//  パズルの複数のピースを生成する。
Widget _buildPieces(double pieceWidth, double pieceHeight) {
  return Stack(
    children: puzzle.pieces.map(
      (piece) {
        final offsetX = pieceWidth * piece.currentPos.hIndex;
        final offsetY = pieceHeight * piece.currentPos.vIndex;

        return AnimatedPadding(
          padding: EdgeInsets.only(left: offsetX, top: offsetY),
          duration: animDuration,
          child: SizedBox(
            width: pieceWidth,
            height: pieceHeight,
            child: _buildPiece(piece),
          ),
        );
      },
    ).toList(),
  );
}

あるピースがクリックされ、1つ右のマスに移動する状況を考えます。
右に移動するため、水平方向のインデックス piece.currentPos.hIndex の値が + 1 されます。
すると、 EdgeInsets.only()left には、更新前の値 offsetX よりも pieceWidth 分だけ大きな値が指定されます。
ここで AnimatedPadding を利用しているので、更新前と更新後の左パディングの値を線形補間しながら、なめらかに表示されるように描画してくれます。

更新後の値を渡すだけで、アニメーションの途中経過の面倒な座標計算を一切せずとも、Flutterが自動的にいい感じにしてくれました。 🙌

参考:

GitHub Pagesについて

最後にビルドとデプロイに関して軽く説明します。

見ての通り、このパズルはGitHub Pagesに配置しています。
タグをプッシュすると自動的にビルドが走り、ビルド内容が gh-pages ブランチにコミットされるように設定しました。

Release.yml:

  - name: Build (Web)
    run: flutter build web --web-renderer html

  - name: Deploy
    uses: peaceiris/actions-gh-pages@v3
    with:
      github_token: ${{ secrets.GITHUB_TOKEN }}
      publish_dir: ./build/web

gh-pages ブランチへの配置には peaceiris/actions-gh-pages@v3 というactionを利用しています。 GitHubのトークンとビルド先のディレクトリと指定するだけで、自動的にいい感じにしてくれます。 🙌

FlutterとGitHub Pagesを使えば、こんなに簡単にWebアプリが作れちゃいました。
今後も簡単なWebアプリであればFlutterで作ってみようと思います。 😤

おわりに

Beta Computing株式会社は石川県のスマートフォンアプリ開発に特化したソフトウェア会社です。 Kotlin・Swiftによるスマホアプリ開発も、FlutterやXamarin.Forms、Unityによるクロスプラットフォームのスマホアプリ開発も、得意としているスマホアプリ開発のプロフェッショナルです。

スマホアプリ開発をご検討されているのでしたら、是非私たちBeta Computing株式会社におまかせください! 業種・ジャンル問わず対応可能ですので、ぜひご相談下さい。

Xamarinの共有プロジェクトでも単体テストが書きたい!

弊社Android担当のd-ariakeです。

現在、Xamarinの改修案件をさせてもらっています。
そのプロジェクトで単体テストを書こうと思ったのですが、少しハマってしまいましたので、それを共有したいと思います。

このプロジェクトはXamarinネイティブの 共有プロジェクト でした。
共有プロジェクトは単なるソースコードの置き場で、AndroidとiOSのそれぞれのプロジェクトでそのソースファイルを参照するといった仕組みです。

この案件には既存のコードがあり、そのソースではがっつりそのままXamarin固有のコードが多用されていました。
ですので、そのまま .NET CorexUnit プロジェクトで共有プロジェクトの参照を追加してしまうと、Xamarin固有のコードを含むソースファイルでエラーになってしまいます。

↓ こんな感じに、Xamarin.AndroidプロジェクトとXamarin.iOSプロジェクトから見たときはビルドが通りますが、単体テストプロジェクトから見たときにエラーになります。

f:id:betacomputing3:20201124135257p:plain f:id:betacomputing3:20201124135309p:plain

単体テストでテストしたい部分というのはXamarinに依存しない計算ロジックや判定ロジックだったりします。
そのため、 共有プロジェクトをまるごと参照に追加するのではなく、ソースファイル単位での追加をすること で解決することができました。

↓ これです。

f:id:betacomputing3:20201124135316p:plain

既存のファイルの追加で、Xamarinに依存していないソースコードのみを単体テストプロジェクトに追加します。
もし、テストをしたい箇所でXamarin固有の機能 (Preferencesなど) を使用している場合、適切にリファクタリングをしてあげましょう。

固有の機能を必要とする箇所を IHogeHogeProviderIHugaHugaRepository などといったインタフェースで切り、テストをしたいビジネスロジックがインタフェースのみに依存するように変更します。

先ほどの画像でも Xamarin.Essentials.Preferences を使っている箇所がありましたが、 IHogePrefereces というインタフェースと HogePreferences (Impl) という具象型をつくり、単体テストプロジェクトには IHogePrefereces のみを追加しました。
これでちゃんと単体テストプロジェクトでもビルドが通るはずです。

そして、もう一箇所ハマったので、そちらも共有します。
私はテストに Moq というモックライブラリを使っているのですが、何も設定せずに使うと以下のようなエラーが発生しました。

System.ArgumentException : Cannot set up 〇〇 because it is not accessible to the proxy generator used by Moq: Can not create proxy for method 〇〇 because it or its declaring type is not accessible. Make it public, or internal and mark your assembly with [assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")] attribute, because assembly 〇〇 is not strong-named.

怒られている内容に従い、 AssemblyInfo.cs に以下のような属性を追加します。

using System.Runtime.CompilerServices;

[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]

しかし、最初は Hoge.SharedHoge.Shared.Tests というプロジェクトがあったとき、Hoge.Shared の方に書いてしまい、エラーが消えてくれませんでした。
共有プロジェクトは単なるソースコード置き場で、それを取り込む側の単体テストプロジェクトでアセンブリが吐かれるので Hoge.Shared.Tests の方に書かないといけません。 (ここで少しハマってしまいました。)
単体テストプロジェクトの方に書き直すと、正常にMoqによるモックが動作してくれました。 🎉

共有プロジェクトの保守をする際には是非参考にしてみてください!

先日のFlutterでのサンプルアプリをAndroidネイティブアプリでも作ってみた件

Android担当のd-ariakeです。
先日 弊社もFlutter採用致します! - Beta Computingブログ という記事の中で このような サンプルアプリを作り、紹介したかと思います。

今回はこのサンプルアプリと同じようなアプリをAndroidネイティブでも作ってみたので、設計の比較やポイントをご紹介したいと思います。

作ったアプリ

仕様は先日のものとほとんど変わっていません。

https://github.com/BetaComputing/SimpleQiitaClientAndroid

image

この同じような仕様のアプリをネイティブで作った際のポイントを軽く解説していきます。

ポイント

以下が今回説明するポイントとなります。

  • UIの設計
  • ネット上の画像のロード
  • FlexboxLayoutの導入

UIの設計

Flutter版では BLoC パターンで設計していましたが、Androidネイティブ版では MVVM パターンで設計を行いました。

UIはxmlで記述し、ViewModelにUIを制御するための変更通知機構を持ったプロパティ (LiveData) をもたせ、データバインディングによってViewModelのプロパティの状態をUIに反映させています。

internal class MainViewModel(/* 省略 */) : ViewModel() {

    //  取得中かどうか
    private val isFetching: MutableLiveData<Boolean> = MutableLiveData(false)

    //  記事リスト
    private val _articleList = MutableLiveData<List<Article>>()
    val articleList: LiveData<List<Article>> = this._articleList

    //  検索キーワード
    val keyword: MutableLiveData<String> = MutableLiveData("")

    //  検索ボタンが有効かどうか
    val isSearchButtonEnabled: LiveData<Boolean> = MediatorLiveData<Boolean>().also {
        val onChanged = { it.value = this.isFetching.value == false && !this.keyword.value.isNullOrEmpty() }
        it.addSource(this.isFetching) { onChanged() }
        it.addSource(this.keyword) { onChanged() }
    }

    //  プログレスバーを表示するかどうか
    val isProgressBarVisible: LiveData<Boolean> = this.isFetching

    //  検索ボタンがクリックされたとき。
    fun onSearchButtonClicked() { /* 省略 */ }

    //  検索を行う。
    private suspend fun search(keyword: String) { /* 省略 */ }
}
<layout <!-- 省略 --> >

    <data> <!-- 省略 --> </data>

    <LinearLayout <!-- 省略 --> >

        <com.google.android.material.appbar.AppBarLayout />

        <LinearLayout <!-- 省略 --> >

            <androidx.constraintlayout.widget.ConstraintLayout <!-- 省略 -->>

                <com.google.android.material.textfield.TextInputEditText
                    android:id="@+id/keywordEditText"
                    <!-- 省略 -->
                    android:text="@={viewModel.keyword}" />

                <com.google.android.material.button.MaterialButton
                    android:id="@+id/searchButton"
                    <!-- 省略 -->
                    android:enabled="@{viewModel.isSearchButtonEnabled}"
                    android:onClick="@{() -> viewModel.onSearchButtonClicked()}" />

            </androidx.constraintlayout.widget.ConstraintLayout>

            <ProgressBar
                style="@style/Widget.AppCompat.ProgressBar.Horizontal"
                <!-- 省略 -->
                android:visibility="@{viewModel.isProgressBarVisible ? View.VISIBLE : View.INVISIBLE}" />

            <androidx.recyclerview.widget.RecyclerView <!-- 省略 --> />

        </LinearLayout>

    </LinearLayout>

</layout>

例えば、検索ボタンの活性の制御の場合です。
以下のコードで、取得処理中かどうかを表すLiveDataと検索キーワードを表すLiveDataから、検索ボタンの活性に変換しています。

val isSearchButtonEnabled: LiveData<Boolean> = MediatorLiveData<Boolean>().also {
    val onChanged = { it.value = this.isFetching.value == false && !this.keyword.value.isNullOrEmpty() }
    it.addSource(this.isFetching) { onChanged() }
    it.addSource(this.keyword) { onChanged() }
}

そして、xmlのデータバインディング構文を使ってボタンの android:enabled プロパティに反映させています。

<com.google.android.material.button.MaterialButton
    android:id="@+id/searchButton"
    android:enabled="@{viewModel.isSearchButtonEnabled}" />

Flutter版では RxDartcombineLatest2() で変換した Stream/SinkStreamBuilder で実装していましたが、本質的には同じことをやっています。
このように主流の設計パターンが両者とも似ているので、Androidアプリ開発者がFlutterを学習するのはとても敷居が低いと感じました。

ネット上の画像のロード

Flutterではネット上の画像を表示させたいときは、単に

Image.network('URL')

というように書けばOKでした。
Androidネイティブには標準でそのような機能が用意されていので、Glide を使用しました。

Glide.with(context).load("画像のURL").into(imageView)

Glideを使うとこのように書くだけで、通信を行い、画像を反映させ、自動でキャッシュまで行ってくれます。
今回はデータバインディングを使った設計をしていたので、

@BindingAdapter("imageUrl")
fun ImageView.setImageUrl(url: String?) {
    Glide.with(this.context).load(url).into(this)
}

このような BindingAdapter を書いて、

<androidx.appcompat.widget.AppCompatImageView
    app:imageUrl="@{article.authorIconUrl}" />

xml上で画像の指定をできるようにしてみました。

このような処理はよく書くので、Flutterが公式で用意してくれているのはとてもありがたいですね。

FlexboxLayoutの導入

記事のタグを表示している部分は、動的に要素数を変えたり、横幅からはみ出た際に折り返しをしなくてはなりません。

Flutterだと Wrap を使うことで自動的に折り返しを設定してくれます。
Androidネイティブだとそのような機能が標準ではありません。

そこで FlexboxLayout というライブラリを使うことにしました。
使い方はとってもかんたんで <FlexboxLayout /> の下に <RecyclerView /> を入れてやり、FlexboxLayoutManager をセットしてやるだけです。

RecyclerView recyclerView = (RecyclerView) context.findViewById(R.id.recyclerview);
FlexboxLayoutManager layoutManager = new FlexboxLayoutManager(context);
layoutManager.setFlexDirection(FlexDirection.COLUMN);
layoutManager.setJustifyContent(JustifyContent.FLEX_END);
recyclerView.setLayoutManager(layoutManager);

引用元: https://github.com/google/flexbox-layout#flexboxlayoutmanager-within-recyclerview

しかし、Androidネイティブのリスト (RecyclerView) を扱おうと思うと、Adapterに関する部分のコードを書く必要があり、多少めんどくさいです。
そこで、コードの見通しを良くするために、カスタムViewを作ることにしました。

internal class TagList(/* 省略 */) : FlexboxLayout(/* 省略 */), TagClickedListener {
    internal var listener: TagClickedListener? = null
    private val adapter = Adapter(this)

    init {
        LayoutInflater.from(this.context).inflate(R.layout.tag_list, this, true)

        val layoutManager = FlexboxLayoutManager(this.context, FlexDirection.ROW)
        this.recyclerView.layoutManager = layoutManager
        this.recyclerView.adapter = this.adapter
    }

    internal fun setTags(tags: List<String>) { /* 省略 */ }
    override fun onTagClicked(tag: String) { /* 省略 */ }

    private inner class Adapter(private val parent: TagList = this) : RecyclerView.Adapter<BindingHolder>() {
        private val inflater: LayoutInflater by lazy { LayoutInflater.from(context) }
        var tags: List<String> = emptyList()

        override fun getItemCount(): Int = this.tags.size
        override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): BindingHolder =
            BindingHolder(TagBinding.inflate(this.inflater, parent, false))
        override fun onBindViewHolder(holder: BindingHolder, position: Int) {
            holder.binding.tag = this.tags[position]
            holder.binding.listener = this.parent
            holder.binding.executePendingBindings()
        }
    }

    private class BindingHolder(val binding: TagBinding) : RecyclerView.ViewHolder(binding.root)
}

@BindingAdapter("tags")
internal fun TagList.setTags(tags: List<String>?) {
    if (tags != null) this.setTags(tags)
}

@BindingAdapter("onTagClicked")
internal fun TagList.setListener(listener: TagClickedListener?) {
    this.listener = listener
}

TagList というカスタムViewとそのBindingAdapterを生やし、

<TagList
    <!-- 省略 -->
    app:onTagClicked="@{tagClickedListener}"
    app:tags="@{article.tags}" />

このようにxml中で使えるようにしてみました。

Flutterだと数行で実現できたことですが、Androidネイティブでやろうとすると、ものすごく大変でした。

感想

UIに関して、シンプルなUIを組むことに限って言えば、Flutterだとものすごく簡単に感じました。
Androidネイティブの場合、ActivityとFragmentの概念や、ライフサイクルの理解と画面の再生成の対応など、知っておかなくてはならないことがたくさんあります。
Flutterだとそれらを意識せずに作れてしまうので、アプリ開発初学者に対する敷居もかなり低くなっていると思います。

当然、Android固有の機能であったり、一部のUIに関してはAndroidネイティブが必要ですし、ネイティブがすぐに不要になるとは思いませんが、今後はFlutterの選択肢も増えていくと思います。

弊社もFlutter採用致します!

弊社Android担当のd-ariakeです。
この度、弊社もFlutterを採用することにしました。

ここ1週間ほど前からFlutterを入門していまして、最低限の動くものが作れるようになってきたので、ざっくりと学習メモのような感じで知見を残しておこうと思います。

サンプルアプリについて

Flutterの学習を進めつつ、シンプルなアプリを作ってみました。
リポジトリとアプリの動作イメージは以下の通りとなります。

FlutterQiitaClient - GitHub
image

Qiitaの記事検索APIを使用し、技術記事をキーワードで検索してリストで表示するといった動作となります。
(このイメージでは1つ記事しか表示されていませんが、実際は検索キーワードに応じた記事がちゃんと表示されるようになっています。)

ポイント

Flutterの入門をする上でポイントであると思ったのは以下の点です。

  • BLoCパターン
  • 静的解析
  • CI

これらについて軽く知見を共有していきます。

BLoCパターン

BLoC (Business Logic Component) パターンはFlutterでよく使われる設計パターンです。
実装をする際には以下のルールに従います。

  1. Inputs and outputs are simple Streams/Sinks only
  2. Dependencies must be injectable and platform agnostic
  3. No platform branching allowed
  4. Implementation can be whatever you want if you follow the previous rules

引用元: Flutter / AngularDart – Code sharing, better together (DartConf 2018)

これらのルールに従って実装したBLoCは以下のようになります。

class SearchPageBloc {
  SearchPageBloc(ArticleRepository repository) : this._repository = repository {
    this._searchEventSubject.listen((_) => this._search());
  }

  final ArticleRepository _repository;

  final _articleListSubject = BehaviorSubject.seeded(List<Article>.empty());
  final _isFetchingSubject = BehaviorSubject.seeded(false);
  final _keywordSubject = BehaviorSubject.seeded('');
  final _searchEventSubject = PublishSubject<void>();

  //  記事リストを通知するStream
  Stream<List<Article>> get articleList => this._articleListSubject.stream;

  //  取得中かどうかを通知するStream
  Stream<bool> get isFetching => this._isFetchingSubject.stream;

  //  検索キーワードを流すSink
  Sink<String> get keywordSink => this._keywordSubject.sink;

  //  検索ボタンが有効かどうかを通知するStream
  Stream<bool> get isSearchButtonEnabled => Rx.combineLatest2(
        this._keywordSubject,
        this.isFetching,
        (String keyword, bool isFetching) => keyword.isNotEmpty && !isFetching,
      );

  //  検索が要求されたことを流すSink
  Sink<void> get searchEvent => this._searchEventSubject.sink;

  void dispose() { /* 省略 */ }

  //  検索を行う。
  Future<void> _search() async { /* 省略 */ }
}

ルール 1. の通りに、BLoCからWidgetへの変更通知を行うもの (表示データや活性フラグなど) は Stream<T> で公開し、WidgetからBloCへの通知を行うもの (入力イベントなど) は Sink<T> で公開しています。

また、BLoC内部でのストリームの変換には RxDart を利用しています。
例えば以下の部分です。

//  検索ボタンが有効かどうかを通知するStream
Stream<bool> get isSearchButtonEnabled => Rx.combineLatest2(
      this._keywordSubject,
      this.isFetching,
      (String keyword, bool isFetching) => keyword.isNotEmpty && !isFetching,
    );

Rxの combineLatest2() を使い、

  1. 検索キーワードのストリーム (_keywordSubject)
  2. データの取得中フラグのストリーム (isFetching)

の2つのストリームから検索ボタンの活性状態に変換するようなストリーム (isSearchButtonEnabled) を作っています。

また、ルール 2. の通り、このBLoCは依存しているリポジトリ (ArticleRepository) を constructor injection で注入可能な仕組みになっています。
もしテストをしたければ、コンストラクタに Mockito などで作ったモックを渡してやることでかんたんに通信部分の挙動を変えることができます。

そして、このBLoCをWidgetに持たせる部分ですが、私は provider を使って実装しました。

//  検索ページ
class SearchPage extends StatelessWidget {
  @override
  Widget build(BuildContext context) => Provider<SearchPageBloc>(
        create: (context) => SearchPageBloc(Dependency.resolve()),
        dispose: (context, bloc) => bloc.dispose(),
        child: _SearchPageContent(),
      );
}

create でBLoCのインスタンスを生成する処理を書きます。
コンストラクタに引数が必要なので Dependency.resolve<T>() という get_itラッパ を介して、リポジトリのインスタンスをサービスロケートしています。

(単体テストはドメイン層からBLoCやViewModelまでの部分に対して書くのが最も費用対効果が高いと思っているので、今のところ provider#create でのサービスロケータで問題はないと思っています。UIの自動テストをやろうと思った場合は別のアプローチが必要になるかもしれません。)

Stream<T> の変更に応じて、Widgetをリビルドする部分は StreamBuilder<T> を使います。
監視対象の Stream<T> と、その流れてきた値からWidgetをビルドする関数を渡してやります。

以下はプログレスインジケータを構築する部分のコードとなります。

//  プログレスインジケータを構築する。
Widget _buildProgressIndicator(SearchPageBloc bloc) => StreamBuilder<bool>(
      initialData: false,
      stream: bloc.isFetching,
      builder: (context, snapshot) =>
          snapshot.data ? const LinearProgressIndicator() : Container(),
    );

SearchPageBloc#isFetching: Stream<bool> を監視して、取得中ならば LinearProgressIndicator を返し、取得中ではなければ空っぽの Container を返すことで、プログレスインジケータの表示・非表示を切り替えています。

(Androidでは visibility = View.INVISIBLE というようにプロパティで制御をしていましたが、Flutterではまるごと再構築を行うことで制御するんですね。UIパーツが状態を持たないという考え方はちょっと新鮮です。)

というのが、BLoCパターンによる設計のポイントです。
他にもReduxやFluxなどもありますが、ひとまず標準的だと思われるBLoCパターンで実装を行っていました。
必要ならばこれらのアーキテクチャについても学んでおこうと思います。

静的解析

Dart & Flutterには標準で強力なフォーマッタ・Linterがついています。

analysis_options.yaml という名前で設定ファイルを置いておくと、その設定に応じた静的解析を行ってくれます。

このサンプルアプリでも設定をしています。
https://github.com/BetaComputing/FlutterQiitaClient/blob/master/analysis_options.yaml

Dartのフォーマッタを走らせるには以下のコマンドを実行し、

dart format --fix 

FlutterのLinterを走らせるには以下のコマンドを実行します。

flutter analyze

私は結構コードのスタイルを気にするタイプなのですが、これらを走らせることで誰か書いても良いコードスタイルになります。 そして、Dangerと組み合わせてCIで実行させることで、本質的でないコードレビューを避けることもできてとても良いですね。
みなさんもぜひ使いましょう!

CI

弊社では普段から GitHub を使っているので GitHub Actions でのCIも設定してみました。
設定ファイルは以下のような感じです。

CI.yml:

name: CI
# (※一部省略しています。)
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Setup Flutter
        uses: subosito/flutter-action@v1
        with:
          channel: 'stable'
          flutter-version: '1.22.2'

      - name: Restore dotenv
        run: echo ${{ secrets.DOT_ENV }} | base64 -d > .env

      - name: Restore dependencies
        run: flutter pub get

      - name: Build (Android)
        run: flutter build apk --debug

      - name: Test
        run: flutter test

      - name: Format and Report
        run: dart format --fix ./ > dart_format_report.txt

      - name: Analyze and Report
        continue-on-error: true
        run: flutter analyze > flutter_analyze_report.txt

      - name: Run Danger
        uses: danger/danger-js@9.1.8
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

flutter-action という便利なactionが公開されていたので、これを利用させてもらいました。
全体の処理の流れは以下のようになります。

  • Flutterのセットアップ
  • 環境変数 (flutter_dotenv) の復元
  • 依存関係の復元
  • ビルド (Android)
  • 単体テスト
  • フォーマット
  • Lint
  • Danger

フォーマッタとLinterを走らせて、その実行結果を Danger JS で報告させています。
(少し雑ですが dangerfile.ts も自分で書いてみました。)

もし、フォーマッタとLintで引っかかると以下のような怒られが生じてCIがコケます。
これで本質的なコードレビューに集中できると思います。

f:id:betacomputing3:20201020153915p:plain

このように、開発ツール・CIまわりについても基本的な使い方を学ぶことはできたかと思います。

入門してみた感想

1週間程度の駆け足で入門してみましたが、Flutterはそこそこ使えると感じました。
Dartの機能不足感を感じたり、一部だけ実現が難しいUIがあったりしましたが、基本的なマテリアルデザインのアプリならば十分だと思います。
開発ツールも公式が必要なものを提供してくれていますし、ホットリロードも爆速で開発体験も非常に良かったです。

ということで、Flutterでの開発もバリバリ対応できますので、ネイティブ (Kotlin・Swift)・クロスプラットフォーム (Flutter・Xamarin.Forms) 問わず、ぜひ我々にお任せください!
お仕事お待ちしております!

AndroidでQRコードとJANコードを扱ってみる

Beta ComputingのAndroid担当のd-ariakeです。
Android案件でバーコードを扱う機会があったので、実装方法を残したいと思います。

行うこと

今回は以下の2点を共有したいと思います。

  • ZXing Android Embedded を使い、QRコードとJANコードを生成する。
  • Glide のカスタムModel Loaderで生成・キャッシュさせる。

ZXing Android Embeddedによるバーコードの生成

ZXing Android EmbeddedZxing をAndroid向けに使いやすくしたライブラリです。
このライブラリを使うと以下のようなコードを書くだけで、簡単にバーコードを生成することができます。

//  QRコードを生成するコード
val hints = mapOf(
    EncodeHintType.ERROR_CORRECTION to ErrorCorrectionLevel.H,
    EncodeHintType.CHARACTER_SET to "Shift_JIS",
    EncodeHintType.QR_VERSION to 12
)
val bitmap: android.graphics.Bitmap =
    BarcodeEncoder().encodeBitmap(contents, BarcodeFormat.QR, width, height, hints)
//  JAN (EAN) コードを生成するコード
val bitmap: android.graphics.Bitmap =
    BarcodeEncoder().encodeBitmap(contents, BarcodeFormat.EAN_13, width, height)

本当に簡単に生成できちゃいます!

余談:
JANコードを生成する際には12桁か13桁の数値文字列を渡す必要があります。
13桁目はチェックサムとなっていて、誤り検出に使われるみたいです。
EAN13Writer.javaUPCEANReader.java のソースを読んだ感じ、12桁のコードを渡すと自動的にチェックサムを計算して13桁として生成してくれるようです。

GlideのカスタムModel Loaderの実装

Androidで画像を扱う際には何かしらの画像管理ライブラリを使うかと思います。
今回は私が一番慣れているGlideを使用して、QRコード・JANコードを生成・キャッシュし、ImageView に表示させるといったことを行いました。

ネット上の画像の場合はそのままURL文字列を渡してしまえばすぐに実現できてしまいます。

Glide.with(this.applicationContext)
    .load("https://画像のリンク.png")
    .placeholder(R.drawable.プレースホルダー)
    .into(this.imageView)

しかし、今回のようにQR・JANコードを生成する場合は自分で ModelLoader を実装する必要があります。
以下に実装手順を載せていきます。

(公式ドキュメント: Glide v4 : Writing a custom ModelLoader)

まず、以下のようにライブラリを追加します。
(必要に応じて apply plugin: 'kotlin-kapt' を追記してください。)

//  https://mvnrepository.com/artifact/com.journeyapps/zxing-android-embedded
implementation("com.journeyapps:zxing-android-embedded:4.1.0")

//  https://mvnrepository.com/artifact/com.github.bumptech.glide/glide
implementation("com.github.bumptech.glide:glide:4.11.0")

//  https://mvnrepository.com/artifact/com.github.bumptech.glide/compiler
kapt("com.github.bumptech.glide:compiler:4.11.0")

次に、Glideの Model に相当する BarcodeRequest を定義します。
sealed class で定義し、Qr 型と Jan 型で表現しました。

package jp.co.betacomputing.barcodeapp

import com.google.zxing.qrcode.decoder.ErrorCorrectionLevel

sealed class BarcodeRequest {

    abstract val content: String

    data class Qr(override val content: String, val level: ErrorCorrectionLevel) : BarcodeRequest()
    data class Jan(override val content: String) : BarcodeRequest()
}

次に ModelLoader<Model (= BarcodeRequest,) Data (= Bitmap)>DataFetcher<Data (= Bitmap)> の実装です。
BarcodeRequestwidthheight とともに Fetcher に渡し、そこで Bitmap を生成しています。

今回は特にネット経由で何かをダウンロードするといったことはないので、getDataSource()DataSource.LOCAL を指定しており、リソースの解放処理も不要なので clearnup() では何もしていません。
(公式のドキュメントのBase64の例でも同じような感じでしたね。)

loadData() で実際のバーコードの生成処理を行います。
オプションを指定して BarcodeEncoder().encodeBitmap() を叩くだけです。
生成に成功したら DataCallback#onDataReady() を叩いて完了を通知します。

package jp.co.betacomputing.barcodeapp

import android.graphics.Bitmap
import com.bumptech.glide.Priority
import com.bumptech.glide.load.DataSource
import com.bumptech.glide.load.Options
import com.bumptech.glide.load.data.DataFetcher
import com.bumptech.glide.load.model.ModelLoader
import com.bumptech.glide.signature.ObjectKey
import com.google.zxing.BarcodeFormat
import com.google.zxing.EncodeHintType
import com.journeyapps.barcodescanner.BarcodeEncoder
import jp.co.betacomputing.barcodeapp.BarcodeRequest as Req

internal class BarcodeModelLoader : ModelLoader<Req, Bitmap> {

    override fun buildLoadData(model: Req, width: Int, height: Int, options: Options): ModelLoader.LoadData<Bitmap>? =
        ModelLoader.LoadData(ObjectKey(model), Fetcher(model, width, height))

    override fun handles(model: Req): Boolean = true

    private class Fetcher(
        private val request: Req,
        private val width: Int,
        private val height: Int
    ) : DataFetcher<Bitmap> {

        override fun getDataClass(): Class<Bitmap> = Bitmap::class.java

        override fun cleanup() = Unit

        override fun getDataSource(): DataSource = DataSource.LOCAL

        override fun cancel() = Unit

        override fun loadData(priority: Priority, callback: DataFetcher.DataCallback<in Bitmap>) {
            when (this.request) {
                is Req.Qr -> this.generateQr(this.request, callback)
                is Req.Jan -> this.generateJan(this.request, callback)
            }
        }

        private fun generateQr(request: Req.Qr, callback: DataFetcher.DataCallback<in Bitmap>) {
            try {
                val hints = mapOf(EncodeHintType.ERROR_CORRECTION to request.level)
                val bitmap = BarcodeEncoder()
                    .encodeBitmap(this.request.content, BarcodeFormat.QR_CODE, this.width, this.height, hints)

                callback.onDataReady(bitmap)
            } catch (e: Exception) {
                callback.onLoadFailed(e)
            }
        }

        private fun generateJan(request: Req.Jan, callback: DataFetcher.DataCallback<in Bitmap>) {
            try {
                val bitmap = BarcodeEncoder()
                    .encodeBitmap(request.content, BarcodeFormat.EAN_13, this.width, this.height)

                callback.onDataReady(bitmap)
            } catch (e: Exception) {
                callback.onLoadFailed(e)
            }
        }
    }
}

そして、この BarcodeModelLoader をGlideに登録する部分です。
これはほとんどドキュメント通りです。

package jp.co.betacomputing.barcodeapp

import android.content.Context
import android.graphics.Bitmap
import com.bumptech.glide.Glide
import com.bumptech.glide.Registry
import com.bumptech.glide.annotation.GlideModule
import com.bumptech.glide.load.model.ModelLoader
import com.bumptech.glide.load.model.ModelLoaderFactory
import com.bumptech.glide.load.model.MultiModelLoaderFactory
import com.bumptech.glide.module.AppGlideModule

@GlideModule
internal class BarcodeGlideModule : AppGlideModule() {

    override fun registerComponents(context: Context, glide: Glide, registry: Registry) {
        registry.prepend(BarcodeRequest::class.java, Bitmap::class.java, Factory())
    }

    private class Factory : ModelLoaderFactory<BarcodeRequest, Bitmap> {

        override fun build(multiFactory: MultiModelLoaderFactory): ModelLoader<BarcodeRequest, Bitmap> =
            BarcodeModelLoader()

        override fun teardown() = Unit
    }
}

最後に、この BarcodeModelLoader を実際に使った簡単なアプリを作りました。
ボタンを押すと、このModel Loader経由でバーコードが生成され、ImageView に設定されます。

f:id:betacomputing3:20200824180053p:plain:w300

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:gravity="center"
    android:orientation="vertical"
    tools:context=".MainActivity">

    <ImageView
        android:id="@+id/qrImageView"
        android:layout_width="256dp"
        android:layout_height="256dp"
        android:layout_margin="10dp"
        android:background="#ef5350"
        android:contentDescription="@null" />

    <ImageView
        android:id="@+id/janImageView"
        android:layout_width="256dp"
        android:layout_height="102dp"
        android:layout_margin="10dp"
        android:background="#42a5f5"
        android:contentDescription="@null" />

    <Button
        android:id="@+id/button"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_margin="10dp"
        android:text="PUSH ME!"
        tools:ignore="HardcodedText" />

</LinearLayout>
package jp.co.betacomputing.barcodeapp

import androidx.appcompat.app.AppCompatActivity
import android.os.Bundle
import com.bumptech.glide.Glide
import com.google.zxing.qrcode.decoder.ErrorCorrectionLevel
import kotlinx.android.synthetic.main.activity_main.*

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        this.setContentView(R.layout.activity_main)
        this.button.setOnClickListener {

            //  QRコード
            Glide.with(this)
                .load(BarcodeRequest.Qr(content = "あいうえお", level = ErrorCorrectionLevel.H))
                .into(this.qrImageView)

            //  JANコード
            Glide.with(this)
                .load(BarcodeRequest.Jan(content = "020000100001"))
                .into(this.janImageView)
        }
    }
}

以上、GlideのカスタムModel Loaderを作って、バーコードを表示させる方法でした。
Glideのキャッシュやロード機能を使いたいけれども、画像の取得部分は自分で実装したいというときは是非やってみてください。