範囲を明確にしたネイティブ開発
新しいアカウント画面、タブレット向けレイアウト、画面状態に関する難しい不具合だけで、アプリ全体を書き直す必要があるとは限りません。
機能が担当する範囲、データの取得元、変えてはいけない既存動作を最初に確認します。作業とテストの境界が明確になります。
フレームワークに特化した作業ではなく製品全体の開発なら、Androidアプリの受託開発をご覧ください。
KotlinとComposeの使いどころ
Jetpack ComposeはKotlinのAPIを基盤とする、Android向けの現代的なUIツールキットです。新しいネイティブ画面に使え、既存アプリのViewベースの画面とも共存できます。
Composeを導入するだけでアプリの構成が良くなるわけではありません。画面状態、非同期処理、エラー、ナビゲーションには設計が必要です。ツールよりアプリの理解を先に置きます。
対応範囲を定められる開発作業
新機能と画面
定義された利用手順を実装し、既存のデータ源と接続します。入力エラー、処理中、応答失敗など、操作の前後に利用者が遭遇する状態も扱います。
既存アプリへのCompose導入
移行に適した画面や部品を選び、動いている機能を維持しながら、Composeと既存Viewの境界を決めます。段階的な変更は全面置換より検証しやすい場合があります。
JavaからKotlinへの移行
移行の利点があるモジュールと、安定したまま残せるモジュールを確認します。目的は構文だけの置換ではなく、動作を守り、必要に応じて保守性を改善することです。
パフォーマンスとライフサイクルの問題
画面の遅さ、過剰な処理、状態の消失、バックグラウンド移行後の動作を調べます。最適化を決める前に、対象のビルドと端末で問題を再現します。
画面サイズへの適応とアクセシビリティ
大きな文字、キーボード操作、支援技術などを含め、利用者に必要な端末サイズのレイアウトを定めます。単に引き伸ばした画面が使いやすいタブレット体験とは限りません。
実装後の引き継ぎに必要なもの
合意した変更には、何をなぜ変えたか、ビルド方法、テスト内容を次の開発者が理解できる情報を添えます。
範囲に応じて、ソースの変更、対象を絞った自動テスト、テスト用ビルド、移行メモ、既知の制約を納品物にできます。お客様のリポジトリでは、別途合意がない限り既存の規約に従います。
秘密の署名情報や本番の認証情報はソースツリーに置かず、最初の問い合わせフォームでも共有しないでください。
不要な作り直しを避けるには
問題そのものと開発ツールの古さを分けて考えます。安定したJavaモジュールより、新しいKotlin画面の不安定な状態管理を先に直すべき場合もあります。ビルドの更新が必要でも、UI移行まで必要とは限りません。
調査では、必要な変更を妨げるもの、現状のまま残せるもの、既存の利用者への影響を確かめるテストを明らかにします。
計画中の機能ではなく、クラッシュやビルド失敗が差し迫った課題ならAndroidアプリの不具合調査から始めてください。
Kotlin、Flutter、既存コードの関係
Android中心の案件にはKotlinが自然な候補です。AndroidとiOSでコードを共有することが重要なら、Flutter開発も選択肢になります。
FlutterアプリでもOS固有の連携にKotlinが必要な場合があります。アプリ全体をネイティブへ移す前提を置かず、その境界を検討できます。
よくある質問
ComposeではなくXMLレイアウトにも対応できますか？
はい。現行アプリと依頼内容に合わせて選びます。保守や新機能のためにComposeへの移行が必須というわけではありません。
アプリの一部だけをComposeに移せますか？
はい。ComposeとViewは共存できます。移行範囲を決め、ナビゲーション、状態、共通部品を確認します。
ライブラリは常に最新版へ更新しますか？
いいえ。互換性、安定性、セキュリティ、現在のビルドを踏まえて選びます。最新版という理由だけで無関係な移行は行いません。
未完成のKotlinアプリも改善できますか？
はい。コードの調査と適切なアクセスが前提です。ビルドできるか、既に何が動くか、次の目標に何が必要かを確認します。
Flutter向けのKotlin連携も含められますか？
はい。対象のAndroid APIやメーカーSDKを教えてください。Flutterの共通部分とAndroidネイティブ実装を一緒に見積もれます。
機能、移行、難しい画面についてご相談ください
必要な結果と現行アプリの概要をお知らせください。リポジトリへのアクセスは範囲と方法を決めてから調整できます。