Slide 1

Slide 1 text

モバイル 開運研修

Slide 2

Slide 2 text

2 この講義について ▌想定受講者 ⚫Webアプリ開発の基礎知識がある方 ⚫モバイルアプリの開発経験のない方 ▌学ぶこと ⚫Webアプリ開発から見たモバイルアプリ開発 ⚫モバイルアプリ開発の特徴

Slide 3

Slide 3 text

3 ネイティブアプリとWebアプリ (1/5) ▌ネイティブアプリはOSの上 OS (Operating System) ネイティブアプリ

Slide 4

Slide 4 text

4 ネイティブアプリとWebアプリ (2/5) ▌ネイティブアプリはOSの上 ▌WebアプリはWebブラウザの上 Webアプリ Webブラウザ OS ネイティブアプリ

Slide 5

Slide 5 text

5 ネイティブアプリとWebアプリ (3/5) ▌ネイティブアプリはOSの上 → 直接OSのAPIを呼び出す ▌WebアプリはWebブラウザの上 → ブラウザのAPIを介してOSのAPIを呼び出す OS Webブラウザ ネイティブアプリ Webアプリ 直接OSのAPIを呼ぶ ブラウザが提供する APIを呼ぶ

Slide 6

Slide 6 text

6 ネイティブアプリとWebアプリ (4/5) ▌ネイティブアプリはOSの上 → 直接OSのAPIを呼び出す ▌WebアプリはWebブラウザの上 → ブラウザのAPIを介してOSのAPIを呼び出す ⚫→ Webブラウザは直接OSのAPIを呼び出す OS Webブラウザ ネイティブアプリ Webアプリ 直接OSのAPIを呼ぶ ブラウザが提供する APIを呼ぶ ブラウザが OSのAPIを呼ぶ

Slide 7

Slide 7 text

7 ネイティブアプリとWebアプリ (5/5) ▌ネイティブアプリはOSの上 → 直接OSのAPIを呼び出す ▌WebアプリはWebブラウザの上 → ブラウザのAPIを介してOSのAPIを呼び出す ⚫→ Webブラウザは直接OSのAPIを呼び出す → Webブラウザはネイティブアプリ OS Webブラウザ ネイティブアプリ Webアプリ Webブラウザはネイティブアプリ

Slide 8

Slide 8 text

8 ネイティブアプリとモバイルアプリ ▌モバイルアプリ → モバイルOS向けのネイティブアプリ モバイル向けOS (iOS, Androidなど) Webブラウザ モバイルアプリ Webアプリ

Slide 9

Slide 9 text

9 ここまでのまとめ ▌ネイティブアプリはOSの上で動作 → OSのAPIを呼び出す ▌WebアプリはWebブラウザの上で動作 → ブラウザのAPIを呼び出す ▌Webブラウザはネイティブアプリ ▌モバイルアプリはモバイル向けOS用のネイティブアプリ

Slide 10

Slide 10 text

10 モバイルアプリとWebアプリの違い

Slide 11

Slide 11 text

11 Webアプリの利用 ▌WebアプリはサーバーからHTMLやJSなどのファイルをロード ▌プログラムもリソースもブラウザが一時的に保持 サーバー HTML CSS JS PNG サーバーからロード 端末 ブラウザ x JS ダウンロードされたファイル群は キャッシュされる

Slide 12

Slide 12 text

12 モバイルアプリの利用 ▌アプリストアからアプリをインストール ▌アプリのプログラムやリソースは本体の永続記憶領域に保存 モバイルアプリ アプリストアから インストール 端末 アプリ アプリストア アプリ パッケージ アンインストールしない限り 消えない

Slide 13

Slide 13 text

13 アプリストアの存在 ▌モバイルアプリはアプリの配布に Google Play Store / AppStore を使用 アプリ開発 ストアの審査 公開 アプリ開発 公開 アプリ開発者 ストア管理者 Webアプリ モバイルアプリ

Slide 14

Slide 14 text

21 動作環境 - Webアプリの開発 ▌複数のブラウザで利用可能 ⚫ブラウザの仕様の違いを考慮して開発 Firefox Chrome Safari x JS x JS x JS x JS 同じアプリを複数ブラウザで動かす

Slide 15

Slide 15 text

22 動作環境 - モバイルアプリの開発 ▌OSごとにアプリを作成 ⚫世界観やデザイン、設計思想がOSによって異なる ⚫OSごとに開発用SDKが提供 ▌ライフサイクルやスレッド、OS独自の機能への対応 iOS Android iOS アプリ Android アプリ OS専用のアプリ

Slide 16

Slide 16 text

23 MPAとSPA ▌MPA (Multi Page Application) ⚫サーバーはリソースごとに異なるHTMLを返す ⚫複数のHTML (ページ) から構成 ▌SPA (Single Page Application) ⚫HTMLをJSなどで動的に書き換える ⚫単一のHTML (ページ) から構成 サーバー サーバー ブラウザ x JS ブラウザ x JS /usersをくれ /v1/usersをくれ { "users": [] } 返ってきたデータを元に 再描画

Slide 17

Slide 17 text

24 SPAとモバイル (1/2) サーバー ブラウザ x JS /v1/usersをくれ { "users": [] } サーバーとはHTTP APIを介してデータを送受信 サーバー /v1/usersをくれ { "users": [] } モバイルOS アプリ コンポーネントで構成 Users Articles News /users /articles /news https://spa.example.com Users Articles News UsersView ArticlesView NewsView Example App

Slide 18

Slide 18 text

25 SPAとモバイル (2/2) サーバー ブラウザ x JS /v1/usersをくれ { "users": [] } サーバーとはHTTP APIを介してデータを送受信 サーバー /v1/usersをくれ { "users": [] } モバイルOS アプリ コンポーネントで構成 Users Articles News /users /articles /news https://spa.example.com Users Articles News UsersView ArticlesView NewsView Example App モバイルアプリはWebのSPAに相当

Slide 19

Slide 19 text

26 モバイルとWebの違いのまとめ Webアプリ モバイルアプリ • ファイルをサーバーからダウンロード • ファイルはキャッシュされる • デプロイしたら公開 • 同じアプリを複数のブラウザで実行 • アプリストアからインストール • 明示的に削除しなければ消えない • アプリストアの審査が行われる • OSごとにアプリを開発 • OSごとに設計思想や世界観がある • コンポーネントの集まりで構成 • HTTP APIを呼び出す場合が多い SPA

Slide 20

Slide 20 text

iOSとAndroidの違いと共通点 27

Slide 21

Slide 21 text

28 デザインガイドラインとデザインシステム iOS: Human Interface Guidelines Android: Material Design Apple Inc. "Human Interface Guidelines - Human Interface Guidelines - Design - Apple Developer". https://developer.apple.com/design/human-interface-guidelines/guidelines/overview/ (参照: 2023/04/27) Google LLC "Material Design". https://m3.material.io/ (参照: 2023/04/27)

Slide 22

Slide 22 text

29 iOS: Human Interface Guidelines ▌アプリケーションインターフェースをより直感的で、学習しやすく一貫性のあるものにすることで ユーザーの体験を向上させる ▌iOS SDKに含まれるUIフレームワークを利用することで、デザインガイドラインに準拠したイン ターフェースを簡便に作れる Apple Inc. "Buttons - Menus and actions - Components - Human Interface Guidelines - Design - Apple Developer". https://developer.apple.com/design/human-interface-guidelines/components/menus-and-actions/buttons (参照: 2023/04/27) Apple Inc. "Action sheets - Presentation - Components - Human Interface Guidelines - Design - Apple Developer". https://developer.apple.com/design/human-interface-guidelines/components/presentation/action-sheets (参照: 2023/04/27)

Slide 23

Slide 23 text

30 Android: Material Design ▌現実世界に基づいたマテリアル (物質) というメタファーを用いて直感的な操作性と一貫性 を持たせたデザインを提供して、ユーザーの操作を補助 ▌Material ComponentsやJetpack ComposeなどのUIフレームワークを利用することで、 デザインシステムに準拠したインターフェースを簡便に作れる Google LLC "Common buttons – Material Design 3". https://m3.material.io/components/buttons/overview (参照: 2023/04/27) Google LLC "Elevation – Material Design 3". https://m3.material.io/styles/elevation/overview (参照: 2023/04/27)

Slide 24

Slide 24 text

31 デザインガイドライン / デザインシステム Apple Inc. SF Symbols. version 4.0 (参照: 2023/04/27) Google LLC "Material Symbols and Icons - Google Fonts" https://fonts.google.com/icons (参照: 2023/04/27) iOS: SF Symbols Android: Material Symbols

Slide 25

Slide 25 text

32 アクセシビリティ ▌iOSとAndroidはWebと同様に読み上げ機能を提供可能 送信 // Android (Jetpack Compose) Button(onClick = {}) { Icon( painter = ..., contentDescription = "送信" ) } // iOS (SwiftUI) Button(action: {}) { Image( "...", label: Text("送信") ) }

Slide 26

Slide 26 text

33 サイボウズのアプリリリースまでの流れ (1/2) 開発 Dev ビルド CI 自動テスト CI アーカイブ CI 社内配信 CD 審査 PF 機能試験 QA リリース PF/Dev フェーズ 担当者

Slide 27

Slide 27 text

34 サイボウズのアプリリリースまでの流れ (2/2) 主導権はCybozu (開発側) 主導権はプラットフォーマー (Apple / Google) 開発 Dev ビルド CI 自動テスト CI アーカイブ CI 社内配信 CD 審査 PF 機能試験 QA リリース PF/Dev フェーズ 担当者 審査には ガイドラインやポリシーが存在

Slide 28

Slide 28 text

35 ストアレビューのガイドライン / ポリシー Apple Inc. "App Store Reviewガイドライン - Apple Developer" https://developer.apple.com/jp/app-store/review/guidelines/ (参照: 2023/04/28) Google LLC "デベロッパー ポリシー センター" https://play.google.com/intl/ja/about/developer-content-policy/ (参照: 2023/04/28) iOS: App Store Reviewガイドライン Android: Google Play Policies

Slide 29

Slide 29 text

36 iOS: App Store Reviewガイドライン 4.2 最低限の機能 Appを作成する際は、Webサイトを単に再パッケージしたよ うなものではなく、優れた機能、コンテンツ、UIを作成するよう にしてください。特に便利でも、ユニークでも、「Appらしく」も ない場合、そのAppをApp Storeで提供することはできませ ん。Appが継続的に楽しめる何らかの価値、または十分な 有用性を備えていない場合は、承認されない可能性があり ます。Appが単に曲または映画の場合は、iTunes Storeに 提出してください。Appが単に書籍またはゲームの攻略本の 場合は、Apple Books Storeに提出してください。 Apple Inc. "App Store Reviewガイドライン - Apple Developer" https://developer.apple.com/jp/app-store/review/guidelines/#minimum-functionality (参照: 2023/04/28) • App Storeで提供できないもの • Webサイトを単に再パッケージしただけのもの • 便利でもユニークでもないもの • Appらしくないもの • 必要なもの • 優れた機能やコンテンツ、UI • 継続的に楽しめる何らかの価値 • 十分な有用性

Slide 30

Slide 30 text

37 Android: Google Play Policies 最低限の機能 ユーザーの興味を引き、操作に反応し、安定して動作するアプリにし てください。 違反の例 • 何もしない、または何の機能も提供しないアプリ 不完全な機能 クラッシュ、強制終了、フリーズ、その他正常でない動作をするアプリ は認められません。 違反の例 • インストールできないアプリ • インストールできるが読み込まれないアプリ • 読み込まれるが応答しないアプリ Google LLC "最低限の機能 - Play Console ヘルプ" https://support.google.com/googleplay/android-developer/answer/9898783 (参照: 2023/04/28) • Google Play Storeで提供できないもの • 何もしないアプリ • 何の機能も提供しないアプリ • 正常でない動作をするアプリ • 必要なもの • ユーザーの興味を引く • 操作に反応をする • 安定した動作

Slide 31

Slide 31 text

38 リリースタイミングの調整 ▌審査が終わるまでの時間は不確定 ⚫通常は半日から3日ほどで完了 ▌審査で問題が起きた場合 → 追加対応と再審査が必要 ▌任意のリリース日を指定するにはテクニックが必要 ⚫リリース予定日の十分前に審査を通す ⚫審査が通ったバージョンを手動リリースまたは公開日時指定を行いリリース

Slide 32

Slide 32 text

39 リジェクトされることがある ▌審査に通るためにはプラットフォーマーの要件を満たす必要がある ⚫ストア審査のガイドラインやポリシーへの準拠 ⚫デザインガイドラインへの準拠 ⚫プライバシーポリシーの提供 ⚫データポリシーの提供 ▌リジェクトされた場合 ⚫要件を満たして審査に再提出 ⚫審査員に事情を説明して交渉 ⚫場合によっては手詰まりでストアでの公開ができないことも

Slide 33

Slide 33 text

40 iOSとAndroidの違いと共通点のまとめ ▌デザインや操作性についての規定がある ⚫iOS: Human Interface Guidelines ⚫Android: Material Design ▌ガイドラインやポリシーに従いストアの審査が行われる ⚫iOS: App Store Reviewガイドライン ⚫Android: Google Play Policies ▌審査にかかる時間は予想できない ⚫審査自体、リジェクト、再提出などはかかる時間が予想できない ⚫リジェクトされ公開できない場合もある

Slide 34

Slide 34 text

他のモバイルアプリの形態 41

Slide 35

Slide 35 text

42 マルチプラットフォーム ▌複数の異なるOSや環境で動かすことができること ⚫同じコードでAndroid用、iOS用アプリが作れるという感じ ⚫クロスプラットフォームとも ▌モバイル向けの代表的なマルチプラットフォームフレームワーク React Native Kotlin Multiplatform Flutter

Slide 36

Slide 36 text

43 マルチプラットフォームアプリの構成 (1/3) iOS Android Web 共通 コード Web専用 コード Android 専用 コード iOS専用 コード iOS用の アプリ Android用の アプリ Web用の アプリ

Slide 37

Slide 37 text

44 マルチプラットフォームアプリの構成 (2/3) iOS Android Web 共通 コード Web専用 コード Android 専用 コード iOS専用 コード iOS用の アプリ Android用の アプリ Web用の アプリ プラットフォーム固有の部分 • 位置情報の取得 • ネットワーク状態の取得 etc... プラットフォーム独立の部分 • ビジネスロジック • UI etc...

Slide 38

Slide 38 text

45 マルチプラットフォームアプリの構成 (3/3) iOS Android Web 共通 コード Web専用 コード Android 専用 コード iOS専用 コード iOS用の アプリ Android用の アプリ Web用の アプリ プラットフォーム固有の部分 • 位置情報の取得 • ネットワーク状態の取得 etc... プラットフォーム独立の部分 • ビジネスロジック • UI etc... ビジネスロジックなどアプリの機能を 複数のプラットフォームで共通して提供可能 OSのAPIを直接呼ぶのが苦手 UIに違和感が残る可能性がある

Slide 39

Slide 39 text

46 PWA (Progressive Web Apps) ▌新しいウェブ API と伝統的なプログレッシブな拡張戦略を使用して、クロスプラットフォームの ウェブアプリケーションにネイティブアプリと同様の使い勝手をもたらすウェブアプリのことです。[1] ▌PWAはネイティブアプリのように ⚫ホーム画面に追加可能 ⚫オフラインでも使える ⚫通知を受け取れる [1] "プログレッシブウェブアプリ (PWA) | MDN" https://developer.mozilla.org/ja/docs/Web/Progressive_web_apps

Slide 40

Slide 40 text

47 まとめ ▌モバイルアプリはネイティブアプリの一種 ▌モバイルアプリとWebアプリは使用する環境が異なるため 使用する技術も関心事も異なる ▌プラットフォームごとに世界観が存在 ⚫デザインガイドライン / デザインシステムが存在 ⚫リリース前に審査が行われガイドラインやポリシーなどのチェックが行われる ⚫要件を満たさない場合はリジェクトされることもある ▌モバイルアプリの形態は複数存在 ⚫ネイティブSDKやマルチプラットフォームフレームワーク、PWA