はてなブックマーク

はじめに ソフトウェア開発、とくに Web やモバイルアプリなどの GUI アプリケーションの開発において、MVVM や MVC といったアーキテクチャパターンの話題は避けて通れません。 GUI アプリケーションの開発において頻出する課題を「パターン」として捉え、それに対する一般的な解決策に名前をつけることで、ひとつひとつのプロジェクトが 1 から解決方法を模索することなく効率的にその課題に対処できることから、これらのパターンはよく参考にされ、実際のソフトウェア開発で取り入れられます。 しかし、内容的にも状況的にも、これらのパターンはただ「取り入れれば良い」という単純なものではありません。 アーキテクチャパターンに対する認識齟齬 アーキテクチャを策定、適用するにあたって大事なことのひとつに メンバー同士の認識を合わせる ことが挙げられます。 アーキテクチャを策定しただけではまだ「絵に描いた

Flutter をやっていて、 BuildContext というクラス名を聞いたことがないという方はいないのではないかと思います。build() メソッドの引数で渡されてくるあれです。 使いどころとしては、画面遷移をするための Navigator.of(context) であったりダイアログを表示するための showDialog(context: context) であったりすると思いますが、この記事ではこの BuildContext が何者なのか、書けるだけ書いていきたいと思います。 なお、まとまりがなく勢いで書き出せるだけ書いた記事ですので、暇な時にのんびり斜め読みで読むのがおすすめです。 BuildContext は Element BuildContext の説明をするためにはまず Element について説明しなければなりません。 Everything is a Widget と

Flutter の UI は、状態 を定義し、それを build() メソッドで参照しながら「宣言的」に構築される設計になっています。 そしてその 状態をどのように参照し、どのように状態の変更を検知してリビルドするか という課題をひとことで 状態管理 と言い、その状態管理の手法にはさまざまな（覚えきれないくらいの）選択肢があることはご存じの通りかと思います。 ひとつひとつを独立した手法ととらえて理解しようとするととても難しく感じてしまいますが、それぞれの状態管理手法を眺めていると、だいたい大きく分けて以下の 3 つの要素で成り立っているように思えます。[1] ステート: 状態を保持するオブジェクト メンテナ: ステートを生成、変更するオブジェクト プロバイダ: ステートへアクセスする手段や変更を通知するオブジェクト この記事では、具体例として Riverpod パッケージを見ながらこの 3

前回の記事 では、今仕事で開発中のアプリのアーキテクチャを クリーンアーキテクチャ本 の教えを頼りに頑張って考えた話を書きました。 前回の記事では主に レイヤーを分割して依存関係を整理することの意義 について書きましたので、この記事ではそれをさらに深掘りし、具体的にそれぞれのレイヤーがどのような役割を担当し、なぜそれをレイヤーとして独立させる必要があると考えたかを説明していきます。 「クリーンアーキテクチャを適用する」とは このアプリの具体的な話に入る前に、この記事での「クリーンアーキテクチャを適用する」という言葉のイメージをちゃんと書いておこうと思います。 個人的な理解ですが、「クリーンアーキテクチャを適用する」という言葉が表す内容は、あの有名な同心円上の 4 つのレイヤーを忠実に再現することではありません。 クリーンアーキテクチャ本では、例の図の直後に 図 22-1 の円は、概要を示し

この記事は Flutter アドベントカレンダー 2021 最終日の記事です。 Flutterはカレンダー3までほぼ全ての日程が埋まってしまうほどの盛り上がりでしたね！ ラストはさらに Flutter への理解を深めていくためのとっかかりになる記事をと思って書いてみましたので、読んでみてください。 Flutter は公式ドキュメントがとても充実した技術です。 flutter.dev にはチュートリアルやAPIリファレンスだけでなく、Flutter のアーキテクチャの解説や描画の仕組みなど、 Flutter という技術がどう成り立っているのか という部分についてもとても丁寧に説明されています。 Inside Flutter はその中でも アプリ開発者が配置した Widget が画面に描画されるまでの仕組み [1] を中心に解説しており、安全で高速に動作するアプリを開発するためにとても役立つ知

モバイルアプリ開発の選択肢の1つとして大きな人気を得ている Flutter フレームワーク、みなさんはその「内側」を理解して使いこなしているでしょうか？ この本では、Flutter が UI を作り上げるための中心的な役割を担っている「Element ツリー」に着目しながら、多くの入門書では触れられない Flutter の内側を研究します。 "Everything is a Widget" の考え方にもある通り、たしかに Flutter は Widget の使い方さえ知っていればある程度のアプリ開発が可能な、素晴らしい API デザインの上に構築されたフレームワークです。 しかし、そのフレームワークの内側を理解することは、Flutter の公式ドキュメントから得られる情報の理解をさらに素早く正確なものにし、アプリの規模が大きくなってもバグなく重くならないアプリを実現するためにとても重要です

本記事で紹介している賃貸物件検索サービス Comfy は 2021/07/30 13:48 をもって閉鎖いたしました。使用していた物件データに関して、データの掲載元より利用許諾を得られなかったためです。本記事で紹介しているサービスが閲覧いただくことができなくなってしまい、大変申し訳ございません。本記事は、サービスに関する一部の内容を削除した上で、使用技術等に関する内容についてはいったんそのまま残しておきますが、近いうちに記事自体を削除するかもしれません。 ※ 2021/07/30 19:00 頃追記 こちらを見に来ていただいた方に、サービスが動いていた頃の動画を下記ツイートにアップロードしています。 サービスを直接お試しいただけない状態で申し訳ございませんが、少しでもサービスの雰囲気が伝われば幸いです。 下記、元の記事の内容です 個人開発で 賃貸物件検索サービス Comfy (上記サービス

この記事は Flutter #3 アドベントカレンダー 2020 - Qiita 8 日目の記事です。 Flutter でアプリ開発をする上で StatefulWidget の setState() を使ったことが無い、という方はおそらくいないでしょう。StatefulWidget の「状態」を管理する State に対して、その状態が変化したことを教えて画面の再描画を依頼するアレです。 Flutter のチュートリアルでも真っ先に出てくる、誰もが知っているこの State.setState ですが、この記事では Flutter のソースコードを読みながら具体的に Element ツリー上で何が起きて画面が更新されているのかを見ていきたいと思います。 これが何の役に立つのかと言われると微妙なところですが、例えば「setState() って細かく何度も呼んじゃって良いの？」のような疑問がもし

この記事は Flutter #3 アドベントカレンダー 2020 - Qiita 19 日目の記事です。 Flutter アプリを作っていると、どこかで一度は MediaQuery のお世話になるのではないかと思います。 例えば、Widget のサイズを画面の幅や高さに合わせるために width: MediaQuery.of(context).size.width, height: MediaQuery.of(context).size.height と記述することが少なからずあるのではないでしょうか。 この記事では、何気なく「画面サイズを取得する」ために使用することの多い MediaQuery について、 MediaQuery とは何なのか、どのように作られているのか、また他のどのような場面で活用できるのかについて考えていきたいと思います。 参考 公式ドキュメントです。主に画面サイズの取

Dart にも Null safety が導入されました。 （11/20 現在では beta） Flutter 2 で正式に導入されましたね！(2021/3/4) Sound null safety | Dart 今までも ? を使った null チェックはあったのですが、それは null かもしれない変数に安全にアクセスする ための手法で、「そもそも変数に null が代入されることを防ぐ」というものではありませんでした。 そこで今回新しく導入されたのが、 変数そのものを、「null かもしれない変数」と「null になり得ない変数」で区別する という仕組みです。 パッと見た感じ、書き方は Swift の Null safety と同じ感じのようですので、Swift を書いたことがある方はイメージしやすいかもしれません。[1] Dart の Null safety の基本 例えば、今まで

Flutter には 2 種類の画面遷移があります。 1 つが「命令的」な画面遷移で、これは例えば Navigator.push や Navigator.pop など Navigator （実際には NavigatorState） が持つメソッドを呼ぶことで 直接的に画面遷移の実行を「命令」する ものです。 もう 1 つが「宣言的」な画面遷移で、Flutter の UI = f(State) の考え方と同じように State を変えてリビルドすることで画面が遷移する というものです。これは Navigator 2.0 という呼称で以前から設計と実装が進められており、 Flutter 1.17 では Page API が、 Flutter 1.22 では Router API が段階的にリリースされています。[1] おそらくほとんどのアプリ開発者は命令的な画面遷移に慣れているのではないかと思

この記事は Flutter #2 アドベントカレンダー 2020 - Qiita 3 日目の記事です。 この記事は、 Flutter アプリ開発で頻繁に利用する Navigator.of(context) の実装を読みながら、Flutter を理解する上でとても重要な「3つのツリー」についての理解を深める記事です。 ターゲット この記事は、以下のような方が読むことを想定しています。 Widget を使って簡単なアプリを作ることができるようになった方。 Widget は知っているけど、 Element とか RenderObject とか言われてもよくわからない方。 Navigator.of(context) ってよく書くけど実際アレ何なんだろう？という方。 逆に、Flutter の公式ドキュメントやソースコードをすでに読んでいて、Flutter のレイアウトの仕組みについてある程度の知識が

フリーランスの働き方、稼ぎ方が様々であることは拙著 フリーランスと○○ に書いた通りです。 私の場合、ひとり、もしくは2, 3人のフリーランス仲間と一緒にモバイルアプリ開発を請け負うことが多いのですが、この記事ではそんな 1人（もしくは少人数）で 0 からソフトウェア開発するための技術 を紹介します。 あくまで私の経験の範囲内ですので、当然他にもいろいろありますが、フリーランスの仕事の一例として読んでいただければと思います。 よくある依頼内容 先に、私がフリーランスをしていてよく依頼される内容を説明しておきます。 私がフリーランスをやっていてよく依頼されるのが、「こんなサービス作りたいんだけどどうすれば良いですかね？」というざっくりとした相談からスタートし、相手のアイデアを詳しく聞きながらそれを実現するための技術を選定し、詳しい要件や仕様を取りまとめ、開発し、リリースし、必要に応じて保守を