2021年6月22日付 日本経済新聞に掲載いただきました。
WEB版はこちら www.nikkei.com
2021年6月22日付 日本経済新聞に掲載いただきました。
WEB版はこちら www.nikkei.com
2021年5月26日付 毎日新聞に掲載いただきました。
WEB版はこちら mainichi.jp
弊社Android・クロスプラットフォーム担当のd-ariakeです。
弊社でもクロスプラットフォーム開発においてFlutterを採用しています。
今回はFlutter for Webでシンプルなパズルを作ってみたので、紹介させていただこうと思います。
このようなパズルを作ってみました。

GitHub Pagesに置いてあります。
ぜひ遊んでみてください。
→ https://betacomputing.github.io/flutter_puzzle/
ソースコードはこちらに置いてあります。
→ https://github.com/BetaComputing/flutter_puzzle
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には html と canvaskit の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に配置しています。
タグをプッシュすると自動的にビルドが走り、ビルド内容が gh-pages ブランチにコミットされるように設定しました。
- 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株式会社におまかせください! 業種・ジャンル問わず対応可能ですので、ぜひご相談下さい。
2021年1月21日付 毎日新聞に掲載いただきました。
WEB版はこちら mainichi.jp
弊社Android担当のd-ariakeです。
現在、Xamarinの改修案件をさせてもらっています。
そのプロジェクトで単体テストを書こうと思ったのですが、少しハマってしまいましたので、それを共有したいと思います。
このプロジェクトはXamarinネイティブの 共有プロジェクト でした。
共有プロジェクトは単なるソースコードの置き場で、AndroidとiOSのそれぞれのプロジェクトでそのソースファイルを参照するといった仕組みです。
この案件には既存のコードがあり、そのソースではがっつりそのままXamarin固有のコードが多用されていました。
ですので、そのまま .NET Core の xUnit プロジェクトで共有プロジェクトの参照を追加してしまうと、Xamarin固有のコードを含むソースファイルでエラーになってしまいます。
↓ こんな感じに、Xamarin.AndroidプロジェクトとXamarin.iOSプロジェクトから見たときはビルドが通りますが、単体テストプロジェクトから見たときにエラーになります。

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

既存のファイルの追加で、Xamarinに依存していないソースコードのみを単体テストプロジェクトに追加します。
もし、テストをしたい箇所でXamarin固有の機能 (Preferencesなど) を使用している場合、適切にリファクタリングをしてあげましょう。
固有の機能を必要とする箇所を IHogeHogeProvider や IHugaHugaRepository などといったインタフェースで切り、テストをしたいビジネスロジックがインタフェースのみに依存するように変更します。
先ほどの画像でも 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.Shared と Hoge.Shared.Tests というプロジェクトがあったとき、Hoge.Shared の方に書いてしまい、エラーが消えてくれませんでした。
共有プロジェクトは単なるソースコード置き場で、それを取り込む側の単体テストプロジェクトでアセンブリが吐かれるので Hoge.Shared.Tests の方に書かないといけません。 (ここで少しハマってしまいました。)
単体テストプロジェクトの方に書き直すと、正常にMoqによるモックが動作してくれました。 🎉
共有プロジェクトの保守をする際には是非参考にしてみてください!
Android担当のd-ariakeです。
先日 弊社もFlutter採用致します! - Beta Computingブログ という記事の中で このような サンプルアプリを作り、紹介したかと思います。
今回はこのサンプルアプリと同じようなアプリをAndroidネイティブでも作ってみたので、設計の比較やポイントをご紹介したいと思います。
仕様は先日のものとほとんど変わっていません。
https://github.com/BetaComputing/SimpleQiitaClientAndroid

この同じような仕様のアプリをネイティブで作った際のポイントを軽く解説していきます。
以下が今回説明するポイントとなります。
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版では RxDart の combineLatest2() で変換した Stream/Sink と StreamBuilder で実装していましたが、本質的には同じことをやっています。
このように主流の設計パターンが両者とも似ているので、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が公式で用意してくれているのはとてもありがたいですね。
記事のタグを表示している部分は、動的に要素数を変えたり、横幅からはみ出た際に折り返しをしなくてはなりません。
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の選択肢も増えていくと思います。
弊社Android担当のd-ariakeです。
この度、弊社もFlutterを採用することにしました。
ここ1週間ほど前からFlutterを入門していまして、最低限の動くものが作れるようになってきたので、ざっくりと学習メモのような感じで知見を残しておこうと思います。
Flutterの学習を進めつつ、シンプルなアプリを作ってみました。
リポジトリとアプリの動作イメージは以下の通りとなります。
Qiitaの記事検索APIを使用し、技術記事をキーワードで検索してリストで表示するといった動作となります。
(このイメージでは1つ記事しか表示されていませんが、実際は検索キーワードに応じた記事がちゃんと表示されるようになっています。)
Flutterの入門をする上でポイントであると思ったのは以下の点です。
これらについて軽く知見を共有していきます。
BLoC (Business Logic Component) パターンはFlutterでよく使われる設計パターンです。
実装をする際には以下のルールに従います。
- Inputs and outputs are simple Streams/Sinks only
- Dependencies must be injectable and platform agnostic
- No platform branching allowed
- 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() を使い、
_keywordSubject)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で実行させることで、本質的でないコードレビューを避けることもできてとても良いですね。
みなさんもぜひ使いましょう!
弊社では普段から GitHub を使っているので GitHub Actions でのCIも設定してみました。
設定ファイルは以下のような感じです。
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が公開されていたので、これを利用させてもらいました。
全体の処理の流れは以下のようになります。
フォーマッタとLinterを走らせて、その実行結果を Danger JS で報告させています。
(少し雑ですが dangerfile.ts も自分で書いてみました。)
もし、フォーマッタとLintで引っかかると以下のような怒られが生じてCIがコケます。
これで本質的なコードレビューに集中できると思います。

このように、開発ツール・CIまわりについても基本的な使い方を学ぶことはできたかと思います。
1週間程度の駆け足で入門してみましたが、Flutterはそこそこ使えると感じました。
Dartの機能不足感を感じたり、一部だけ実現が難しいUIがあったりしましたが、基本的なマテリアルデザインのアプリならば十分だと思います。
開発ツールも公式が必要なものを提供してくれていますし、ホットリロードも爆速で開発体験も非常に良かったです。
ということで、Flutterでの開発もバリバリ対応できますので、ネイティブ (Kotlin・Swift)・クロスプラットフォーム (Flutter・Xamarin.Forms) 問わず、ぜひ我々にお任せください!
お仕事お待ちしております!