私たちのチームでは、リリース中となる動画視聴アプリのFlutterでのフルリニューアルの鋭意対応中です。Flutterは、標準のwidgetが豊富に揃えられているのが魅力の一つとなるF/Wですが、それそのままでは複雑な機能要件を全て満足することができないケースがしばしば発生します。
リニューアル対象のアプリでは、動画コンテンツの商品パッケージやシーンのサムネイルといった画像のプレビュー機能があるのですが、それがまさにそうでした。
InteractiveViewerが近しいwidgetになりますが、ピンチ操作による拡大・縮小といった一般的な画像ビューワの操作性はもちろんですが、タップ操作でのオートスケール、フリック操作で画面を閉じる等、特徴的なジェスチャ操作と共存させる上で難しい課題があり、結論としてゼロから実装することになりまして、どうせならpackageとして公開しちゃおうよー
、といった感じで今に至ります。
作業過程でぶつかった課題や、画像ビューワを実装する上での勘所等をお話し、同じような壁にぶつかり、乗り越えようとしてきている皆さんへ共有させていただき、少しでも助力にしていただけたらと思います。
モバイルアプリを長期的に運用・メンテナンスするうえで、機能や複雑化したシステムを削減し、効率的な運用を実現するための「スリム化」が重要なテーマとなっています。
本セッションでは、FacebookとX(旧Twitter)ログインの削除を例に、サービスのスリム化をどのように実行するかについて考察します。
スリム化を進める上での具体的なステップとして、ユーザーへの通知方法、新規登録・ログイン導線の変更、既存ユーザーの対応策などを取り上げ、サービスのスリム化によって得られる利点と潜在的な課題について議論します。
また、削除までの意思決定を行うためにどのようなことを行い、機能のスリム化の意思決定をしたかの流れをお話し、サービス運用に携わるさまざまな役割の方々が直面する課題に焦点を当て、スリム化による具体的な利点と実施方法をお伝えします。
Dart3で以下を実行するとどうなるでしょうか?
void main() {
final l = <String>['あいざわ', 'アイザワ', '相澤', 'いとう', 'イトウ', '伊藤'];
l.sort();
print(l);
}
出力結果は以下です。
[あいざわ, いとう, アイザワ, イトウ, 伊藤, 相澤]
当然空気を読んでくれるはずもなく、無情な結果が出力されました。
ひらがな→カタカナ→漢字どころか、伊藤が相澤より前になりました。
万年出席番号1番だった相澤さんもこれにはびっくりです。
現在観測できる限りでは、Dartでは現状これを直接解決するパッケージが存在しません。
本セッションではこの単純だが厄介な問題に対して、複数の観点から向き合っていきます。
本セッションでは、Flutterを用いたマルチプラットフォーム災害危機情報可視化システムの開発について詳しく解説します。
みちびき(準天頂衛星システム)の災害・危機管理通報情報を専用の受信機を通じ、マルチプラットフォームデバイス(Android, Web, macOS)で受け取り、インターネット接続環境の有無に問わない状況下での災害危機情報の提供を実現します。
(本プロジェクトは進行中のため、内容は変更される可能性があります)
ローカルDBは手軽にアプリのデータを永続化することができるものの、アプリのリリース後、手元を離れ、長期にわたって変更が加えられるその実体を正確に把握し続けることは困難です。
また、アプリの成長や新しいローカルDBパッケージの登場に伴い、使用パッケージを変更したくなることもあるかもしれません。
私は個人で開発しているFlutterアプリケーションをおよそ4年半もの間運用しており、その間にパッケージ変更を伴う2度の大規模マイグレーションを経験しました。
さらに、パッケージ変更を伴わない中規模のマイグレーションも1度経験しており、現在は2度目の中規模マイグレーションに直面しています。
ユーザーの持つデータ実体を正確に把握できていない状態でのマイグレーションがどれほど恐ろしいか、ご想像に難くないかと思われます。
しかし、そのような困難を乗り越える中で、私が得た知見は決してゼロではありません。
本LTでは、3度のマイグレーションを終え4度目に取り組む今、私が考えるFlutterにおけるローカルDBの
についてお話しします。
私の所属するチームでは、事業のスケールと共にアプリチームのメンバーも増え、現在10人のメンバーがいます。
そのスケールの中で開発生産性を落とさず、さらに増加させていく取り組みとしてコードレビューを促進する取り組みを行っています。
このセッションでは、以下の内容についてお話しします:
想定視聴者
Flutterは標準でスクリーンリーダーに対応しており、簡単に文字を読み上げることができます。
しかし、Semanticsウィジェットを正しく使わないと、スクリーンリーダーを使用する人にとって使いにくいアプリになってしまうことがあります。
スクリーンリーダーに対応するために重要なSemanticsの要素として下記があります。
上記の内容を踏まえ、本セッションでは、Semanticsの使い分けによるスクリーンリーダー対応の最適化の手法についてお話しします。
具合的には、以下の内容についてお話しします。
弊社ではモバイルアプリのデリバリー効率最大化のために、ネイティブアプリをFlutterにフルリプレイスしました。
そのプロジェクト内では技術的な変更だけでなく、将来的にWebエンジニアがモバイル開発の一部を担えるかどうかの検証も合わせて実施しました。
結果としては個人的、事業的の両面で非常に価値のある取り組みとなりました。
こちらの発表ではまさに実験台となった私の経験を元に
という話を具体的にさせていただきます。
Webエンジニアの方々の「Flutter開発楽しそう」「ここが落とし穴か・・・」という部分を理解する助けや
Flutterエンジニアの方々の「チーム拡大のための1アイデア」「初学者オンボーディングの工夫ポイント」などのつかみになれば幸いです。
環境構築が開発を行う上で最も最難関の準備パートではないでしょうか? flutter doctor コマンドを使っても解決まで時間がかかった経験を持っている初学者の方はいませんか?
Project IDX はこれらの課題を解決し、すぐに関心事である実装に集中することができます。 Project IDX はいわゆるplaygroundの一種で、オンラインで開発環境を提供するツールです。Flutterはこの中に含まれています。オンラインで開発の環境が完結しているため、環境構築の手間をほとんど0にしてコードを書くことができます。
このプロジェクトは発展途上ではありますが、プロトタイピングに非常に優れています。プロトタイプした完成のみならず、コード自体も共有しアイデアをすぐに実装・プロトタイプに反映する、高速な開発を進めることが可能になります。
このLTでは、IDXを用いてプロジェクトを作る方法や、既存のFlutterプロジェクトをIDXにする方法、エミュレータの使用方法など Flutter のための Project IDX の使い方を共有します。
本セッションではFlutter開発経験が0のモバイルエンジニアのみで構成された弊チームが、どのようにしてFlutterを学び、新規アプリをリリースするまでに至ったかを2024年度版と題してご紹介します。
Flutter導入の背景から、効果的だった勉強方法やそうでなかった方法、実際に新規アプリを開発・リリースするまでの道のりについて具体的にお話しします。
現在では、Flutterで開発したアプリを1つリリースし、さらに2つの新規アプリを開発中です。
Flutterの導入を検討しているエンジニアやマネージャーにとって有益な情報を提供し、実際の導入事例を通じてチーム全体で新しい技術を学ぶ際の参考にしていただければと思います。
・ Flutterに興味があるが、どのように学習を進めれば良いか悩んでいるエンジニア
・ 新しい技術を導入する際のチームの学習プロセスやリソース配分について知りたい方
・ チーム全体で新しい技術を学ぶ際の効果的な方法や、実際の導入事例を知りたい方
・ 新しい技術を導入する際のメリットやデメリット、実際の導入事例を通じて、組織全体の技術戦略を考える参考にしたい方
私たちのチームは、約2年間にわたり自動テストの運用を行い、そのシナリオ数は70を超えました。その過程で多くの課題と学びがありました。
カバレッジを維持するためには、自動テストの書き方の統一性、痒いところに手が届く記法の必要性などの数多くの課題が存在します。
以下の内容についてお話しします。
Flutter用のゲームエンジン「Flame」をご存知でしょうか? Flameは、スプライト管理、衝突判定、エフェクトなど、2Dゲームに必要な機能を一通り備えています。FlameのGameWidgetはFlutterのWidgetツリーのどこにでも挿入できるため、ゲームアプリ以外のアプリにもゲーム的な要素を盛り込むことができます。
近年のモバイルアプリでは、LottieやRiveといったツールで作成されたベクターアニメーションが盛んに利用されていますが、これをFlameを使ってゲームライクなインタラクティブコンテンツに置き換えると、またちがった面白さが生まれるかもしれません。
このトークでは、Flameを用いて一般的なモバイルアプリのアニメーション演出をユーザーが操作できるコンテンツに変換した事例を紹介します。Flameを活用した派手な演出の作成方法や、GameWidgetとFlutterアプリ本体との連携方法についてもお話しします。
昨今の Flutter 開発の現場において、build_runner は欠かせない存在になっているかなと思います。
しかし一方で、それなりに大きなコードベースで作業されている方は特に、build_runner の実行時間の長さによって生産性が低下したり、また DX (Developer Experience) が阻害されているという人も多いのではないでしょうか。
本セッションでは build_runner による待ち時間を少しでも短くするための tips についてお話しします。
・開発現場で build_runner を使っている方
・build_runner の実行時間に課題を抱えている方
現在担当しているサービスはモバイルアプリ(Flutter)とWebブラウザ(PC/SP)の複数プラットフォームに提供していますが、各プラットフォームでは一部を除いて共通のデザインコンポーネントを使って実装しています。
Flutterアプリで効率よく実装、管理するためにはどういったコンポーネント定義なら実装しやすいかをFlutterのコードを踏まえながら、デザイン作業も兼任しているエンジニア目線で解説します。
このセッションでは以下の内容を想定しています
本セッションでは、Dart Frogを活用したWebSocket通信の実装方法を詳しく解説します。
WebSocket通信の実装には、接続管理、エラーハンドリング、再接続ロジックなど、考慮すべき点が多岐にわたります。また、Dartの非同期処理と組み合わせる際の適切な実装方法や、パフォーマンスの最適化も重要な課題です。
そこで Dart Frogの特徴や利点を紹介し、WebSocket通信の実装手順を step by step で説明します。さらに、実装上の注意点や最適化テクニックを共有し、効率的で信頼性の高いWebSocket通信を実現しましょう。
・Flutter でゲーム開発する際に Dart で websocket サーバーを実装したい開発者
・Dart Frogを使ったバックエンド開発に興味がある開発者
ここに、野菜のリストがあります。
[にんじん, じゃがいも, たまねぎ, ブロッコリー]
あなたなら、緑色の野菜だけを選ぶにはどうしますか? それぞれの野菜をサラダ用にカットするには? 野菜の重さを合計するには? 空のコンソメスープに各野菜を追加するには?
これらの操作を簡単に実現できるのが、Dartの高階関数です。高階関数は、関数を引数や戻り値にとる関数のことです。Dartでは、map・where・reduce・foldなどが Iterableクラスのメソッドとして定義されています。これらを使うと、for文よりも簡潔で柔軟なコードが書けます。
本セッションでは、野菜を例に、Iterableクラスに定義された高階関数を直感的に理解することを目指します。また、具体的なケースで高階関数を使う場合と使わない場合を比較し、コレクション操作が簡潔で明瞭になることを体感します。さらに、Dart SDKの内部実装を参照して、Iterableクラスのメソッドの動作をより深く理解します。これにより、高階関数へのハードルが下がり、Dartでの開発がさらに楽しくなるでしょう!
Dartの高階関数にハードルを感じている方
Iterableクラスの内部実装に興味がある方
野菜が好きな方
地下鉄や長時間のフライトなど、通信が不安定な状況でもアプリが快適に動作することが求められています。
このニーズに応えるには、オフラインでのデータキャッシュが不可欠です。
特に、大量のデータを扱うアプリでは、データベースの選定がパフォーマンスに大きな影響を与えます。
本セッションでは、学習用APIであるPokeAPIを活用し、sqfliteやobject_boxなどのデータベースを比較します。
それぞれの読み書き速度やリアルタイム検索の実装方法を解説し、オフライン環境でもスムーズに動作するアプリの実装手法を紹介します。
さらに、オフラインからオンラインに復帰した際のデータハンドリングについても触れます。
このセッションで学べること
多くのFlutter開発者が直面する課題の一つは、標準コンポーネントでは対応できない高度なUIニーズです。私たちのプロジェクトでも、動画のスライダーをカスタマイズする必要に迫られ、標準のSliderコンポーネントでは対応できない要件に直面しました。その結果として、CustomPaintを活用して独自のスライダーを実装することにしました。
このセッションでは、CustomPaintの基本から始め、高度なカスタム描画を行うためのベストプラクティスと実際のパフォーマンスについて深掘りしていきます。
このセッションの内容は以下の通りです:
Flutterアプリの国際化(i18n)にはさまざまなアプローチがありますが、プロジェクトの要件に応じた最適なソリューションを選ぶことが重要です。私たちのプロジェクトでは、複数の言語や地域に対応するために、i18nソリューションを慎重に選定しました。その中で、ファイル管理の柔軟性、型安全性、そしてYAML形式のサポート等を重要視し、最終的にslangというパッケージを導入することに決定しました。
このセッションでは、私たちがslangの導入に至った背景や、その具体的な利点についてお話しします。18nのソリューションを検討する際に役立つ情報を提供し、プロジェクトに最適なアプローチを見つける手助けとなることを目指します。
• Flutterアプリの国際化に関心があるエンジニア
• i18nパッケージの選定に関心がある方
• type-safeなコード生成に関心がある方
Dart から Kotlin へコードを移植した際、特定の条件下でアプリがクラッシュする事態に直面しました。このクラッシュは Android 版でのみ発生し、 iOS 版では問題ありませんでした。一見、 Dart、 Kotlin、 Swift で同じ Int 型を扱っているように思えましたが、その内部実装は異なり、型の変換処理を単純に移植することができないことが明らかになりました。このトークでは、クラッシュの原因を掘り下げるとともに、言語ごとの型の違いを考慮した適切な移植方法について解説します。