ざっくりHuman Interface Guideline part3〜ユーザーインタラクション

ユーザーインタラクション

3D Touch

サポートされているデバイスでは、タッチスクリーンにさまざまなレベルの圧力を加えることで、追加の機能にアクセスできます。 ビッてメニューが出ます。 iOS 13以降を実行しているデバイスでは、デバイスが3Dタッチをサポートしているかどうかに関係なく、長押しでメニューが出ます。

アップルペンシル

Apple Pencilは、iPadアプリでメモをメモしたり、スケッチしたり、ペイントしたり、ドキュメントをマークアップしたりするときに、ピクセルレベルの精度を提供する多用途で直感的なツールです。 利き腕の設定もできます。

オーディオ

※開発者向けの部分のみ

ボリュームビューはカスタマイズ可能で、音量レベルのスライダーが含まれ、MPVolumeViewフレームワークで利用可能です。 短い音やバイブレーションには、システムのサウンドサービスを使用してください。 必要がない場合は、他のアプリからの音楽の再生を停止させないでください

認証

追加機能へのアクセス、コンテンツの購入、データの同期など、ユーザにとって価値がある場合にのみ認証を要求します。 アプリで認証が必要な場合は、Appleでのサインインを使用して、簡単で安全なサインイン方法を提供します。 Appleでのサインインをサポートすると、信頼できる一貫したサインインエクスペリエンスと、複数のパスワードを覚えておく必要がないという便利さを実現できます。

Appleでのサインインを使用しない場合は、パスワードオートフィルを使用

パスワードオートフィルを使用することで、 パスワードとセキュリティコードを自動的に生成して入力するため、認証画面に費やす時間を短縮できます。 すべてのアプリがこの機能をサポートする必要があります。 https://developer.apple.com/documentation/security/password_autofill/

サインインを可能な限り直前に行う

ユーザーは、機能を利用する前にサインインを余儀なくされたとき、アプリを放棄することがよくあります。

アプリを使用する前に、アプリに恋する機会を与えましょう。（アプリに恋する機会っておしゃれですな）

認証の利点と、サービスにサインアップする方法を説明する

アプリで認証が必要な場合は、要件の理由とその利点を説明する簡潔でわかりやすい説明をログイン画面に表示します。

適切なキーボードを表示して、データ入力を最小限に抑えます。

たとえば、電子メールアドレスを要求する場合は、電子メールのキーボード画面を表示します。 この画面には、便利なデータ入力ショートカットが含まれています。 UIKeyboardType

パスコードという用語は決して使用しないこと

パスコードは、生体認証が無効になっているときに、ユーザーのiOSデバイスのロックを解除し、Apple Payで認証するために使用されます。

常に認証方法を識別する

たとえば、Face IDを使用してアプリにサインインするためのボタンのタイトルは、「Sign In」ではなく「Sign In with Face ID」にする必要があります。

アイコンを使用してシステム認証機能を識別しないこと

システムのTouch ID（拇印）アイコンとFace IDアイコンのようなアイコンが表示された場合、 ユーザーは認証する必要があると考えています。 認証機能を識別するためにアイコンを使用すると、アイコンの違いや大きさの違いなど不整合が生じ、ユーザーを混乱させる場合があります。

データ入力

ドラムロールのようなインターフェイス要素をタップする場合でも、キーボードを使用する場合でも、 情報の入力は面倒なプロセスになる可能性があります。 多くの入力を要求することでプロセスを遅くすると、ユーザーは面倒に感じ、アプリの利用を中断することさえあります。

可能な場合は、選択肢を提示する

データ入力をできるだけ効率的にします。 たとえば、定義済みのオプションのリストから選択する方が応答を入力するより簡単なので、 テキストフィールドの代わりにピッカーまたはテーブルを使用することを検討してください。

可能な限りシステムから情報を取得する

連絡先やカレンダー情報など、自動的に、またはユーザーの許可を得て収集できる情報利用してください。

適切なデフォルト値を指定する

最も可能性の高い値をフィールドに事前入力します。 適切なデフォルトを提供すると、意思決定が最小限に抑えられ、プロセスが高速化します。

必要な値を収集した後でのみ前進を有効にする

[次へ]または[続行]ボタンを有効にする前に、すべての必須フィールドに値があることを確認してください。 ボタンの有効化を、次に進むときの視覚的な合図として使用します。

フィールド値を動的に検証する

長いフォームに記入した後で戻って間違いを修正しなければならないときはイライラします。 なので、可能な限り、次のステップに進む前に正しい値かユーザーに示してください。

目的を伝えるのに役立つヒントをテキストフィールドに表示

テキストフィールドには、空の場合、「Eメール」や「パスワード」などのプレースホルダーテキストを含めることができます。 プレースホルダーテキストで十分な場合は、テキストフィールドの説明に別のラベルを使用しないでください。

ドラッグアンドドロップのサポート

可能な限り、ドラッグアンドドロップを元に戻せるようにしてください。

ユーザーが誤って間違った場所にコンテンツをドロップした場合、ドロップされたコンテンツを削除し、 アプリ内の別の場所から移動した場合は、元の場所に復元する必要があります。

必要に応じて、ドラッグアイテムのプレビューをカスタマイズ

基本的にドラッグされているコンテンツのバックのビューは半透明の表現である必要があります。 この外観はドラッグが進行中であることを示します。

アプリのコンテンツの転送に時間がかかるか、リソースを集中的に使用する場合は、ファイルプロバイダー拡張機能を実装する

ファイルプロバイダー拡張機能が転送プロセスを管理し、アプリが実行されていなくても転送プロセスが完了することを保証します。 転送プロセスは、ユーザーがコンテンツをドロップするまで開始されないことに注意してください。 開発者向けガイダンスについては、NSFileProviderExtensionを参照してください。

アプリのコンテンツの転送に時間が必要な場合は、進捗情報を提供する

コンテンツをダウンロードする必要がある場合や、大きなファイルをコピーするのに時間がかかる場合は、進捗情報を提供します。 少なくとも、コンテンツの合計サイズを指定して、残り時間を計算し、適切な進行状況インジケーターを表示できるようにします。 開発者向けガイダンスについては、NSProgressを参照してください。

強調表示

コンテンツがドラッグされると、ビューが微妙に点滅して色が変化したり、 ドラッグされた画像のためのスペースを空けるために段落が離れたりすることがあります。 逆にコンテンツがドロップされたときは強調表示が削除されていることを確認してください。

フィードバック

フィードバックは、アプリが何をしているかを理解し、次に何ができるかを発見し、アクションの結果を理解するのに役立ちます。

ステータスや他のタイプのフィードバックを控えめに

ユーザーはアクションを実行したり中断したりすることなく、重要な情報を取得できるのが理想です。 たとえば、OS表中のメールアプリは、メッセージのメールボックスをアップデートし最新にしている間、 ステータス情報をツールバーに下部に表示します。 この情報は画面上の主要なコンテンツと競合しませんが、いつでも一目で確認できます。

不要なアラートを減らす

アラートは強力なフィードバックメカニズムですが、ユーザーが不利益になる、もしくはアプリが続行できなくなるような場合にのみ表示するのが理想です。 重要な情報が含まれていないアラートが多すぎると、アラートを無視するようになります。

ファイルの取り扱い

キャンセルまたは削除しない限り、作業は常に保持されるという確信を植え付けると良い

基本的にはファイルを明示的に保存しないでください。 代わりに、ファイルを開いたり閉じたりするとき、および別のアプリに切り替えるときに変更を自動的に保存します。 既存のファイルの編集中など、場合によっては、編集内容が実際にいつキャプチャされたかを確認するために、 保存とキャンセルボタンを明示することが良い場合もあります。

ユーザーがアプリを離れることなくファイルをプレビューできるようにする

クイックルックを使用すると、Keynote、Numbers、Pagesのドキュメント、PDF、画像、およびその他の特定の種類のファイルのコンテンツを アプリで実際に開かなくても表示できます。

ゲームコントローラー

割愛します

ジェスチャー

原則として、標準のジェスチャーを使用

ゲームなど独自の世界観をもち、没入感をもたらすためのカスタムジェスチャーは推奨されますが、 一般的なアプリでユーザーが意図しているものと違う挙動は行わない方が得策です。

システム全体の画面端のジェスチャーを妨げないこと

面の端のジェスチャーでホーム画面、アプリスイッチャー、通知センター、コントロールセンターにアクセスできます。 ゲームなどで画面端のジェスチャーを使う場合は、最初のスワイプでアプリ固有のジェスチャーが呼び出され、2回目のスワイプでシステムジェスチャーが呼び出されます。 UIViewControllerのpreferredScreenEdgesDeferringSystemGesturesプロパティを参照してください。

標準ジェスチャー

標準ジェスチャー一覧

おそらく大体は知っているジェスチャーでしたが「3本指でつまむ」「3本指でスワイプします。」「シェイク」などあまり親しみのないものもあります。

ハプティクス

ハプティクスは、画面上のインターフェイスとの対話体験を強化するために、人々の触覚に働きかけます。 視覚的、聴覚的なものはもちろん触覚に働きかけることでよりユーザー体験は向上します。

システムハプティクス

スイッチ、スライダー、ピッカーなどの標準のUI要素を使用して、デフォルトでAppleが設計したシステムハプティクスを再生します。

例えば、ピッカーで選択肢を動かしている時。 スクロールするときに軽くたたく感じがします。 このフィードバックは、選択を行ったり確認したりするのではなく、一連の離散値を通じて動きを伝えることを目的としています。 他のものについてはハプティクスのページ、UIFeedback Generatorなどを参照してください。

カスタムハプティクスパターンの作成

iOS 13以降では、Core Hapticsはカスタムハプティックパターンを生成する2つの基本的なビルディングブロックを提供します。

• ホーム画面の懐中電灯ボタンをタップするなど、タップや衝動のように感じられる簡潔でコンパクトなエクスペリエンスです。
• メッセージ内のレーザー効果の経験など、持続的な振動のように感じる連続イベント

カスタムハプティックの生成に選択したビルディングブロックに関係なく、そのシャープネスと強度を制御することもできます。 詳しくはコアハプティクスを参照してください。

NFC(近距離無線通信)

たとえば、ユーザーがおもちゃをスキャンしてビデオゲームに接続したり、 買い物客が店内の看板をスキャンしてクーポンにアクセスしたり。 近距離無線通信（NFC）を使用すると、互いに数センチ以内のデバイスがワイヤレスで情報を交換できます。 タップアンドタッチではなく、スキャンアンドホールドのような用語を使用します。

近距離無線通信は、一部の人には不慣れな場合があります。 親しみやすいものにするために、NFC、コアNFC、近距離無線通信、タグなどの 技術的で開発者向けの用語を参照することは避けてください。 見た目でわかりやすいオブジェクト名にしてください。（WiFiパスワードを共有するためiPhone同士を近づけてくださいなど）

ポインター(iPadOS)

割愛

Undo and Redo

多くのアプリでは、デバイスをシェイクして、入力や削除などの特定の操作を元に戻したりやり直したりできます。 この方法で開始すると、アラートは、元に戻す操作またはやり直し操作を確認またはキャンセルするようにユーザーに要求します。

disneych.work

disneych.work

ざっくりHuman Interface Guideline part2〜アプリアーキテクチャ〜

アプリのアーキテクチャ

起動

起動体験はユーザーの心理に大きく影響します。 デバイスの性能や使用頻度によらず、起動は早くなくてはいけないです。

楽しく、違和感のない起動体験の設計をするには以下の要素が重要です。

起動画面の提供

いわゆるスプラッシュ画面。 スプラッシュ画面を表示する意図は、最初のコンテンツの読み込みを可能にしながら、アプリが高速で応答性が高いという印象をユーザーに与えるためです。

適切な方向で起動

アプリの縦向き横向きを判定して適切に表示する必要があります。 SplitViewなども出てきたのでそちらの対応も必要です。

起動後に必要な権限要求をする

ユーザーがアプリを開いたときに情報を提供するように求め、後でアプリの設定で変更できるようにします。 アプリ起動時もですが、位置情報などは必要な画面でダイアログを出すなども検討が必要だと思います。

アプリ内にライセンス契約や免責事項を表示しない

基本はApp Storeに同意書と免責事項はダウンロードする前にユーザーが確認できるようにする必要があります。 アプリに含める必要がある場合はUXを損なわないような設計をします。

アプリの再起動時に以前の状態を復元

アプリキル、バックグラウンド移行からの起動は適切な画面を表示させる必要があります。

再起動を勧めない

再起動には時間がかかり、アプリの信頼性が低く、使いにくいように見えてしまいます。

リリース後すぐに、もしくは頻繁にアプリの評価を依頼しないこと

当たり前ですが、最初のリリース後すぐに、またはユーザーがアプリを使用している間に頻繁に評価を求めるのは煩わしく、正しいフィードバックがさない可能性があります。 決して人々にあなたのアプリを評価することを強制しないでください。

オンボーディング

※いわゆるウォークスルーやコーチマークなどです。

• ライセンスの詳細やセットアップの仕方を載せない
• スキップできる機能をつける
• ヘルプが必要な適切なタイミングを予測する
• 多くのチュートリアルが必要な場合アプリのUIを見直す必要がある
• 指示をするよりも実行して学んでもらうことが1番

ローディング

アプリがフリーズしたように見えるとユーザーがアプリを離れる可能性が高くなるので、ローディングを適切に入れる必要があります。

ロード時間を明確に示す

少なくとも、何かが起こっていることを伝えるアクティビティスピナーを表示します。

できるだけ早くコンテンツを表示する

プレースホルダーテキスト、グラフィックなどを使用して、コンテンツがまだ利用できない場所を特定します。

読み込み時間を楽しませるよう工夫する

ゲームプレイ、面白いビデオシーケンスなどで読み込み時間を有効に活用させます。

ロードのカスタマイズ

アプリやゲームのスタイルに合わせてより世界観に没入できる体験を提供できないか検討必要です。

※別の記事でネイティブアプリに関わらず、6秒未満の待ち時間がある場合はローディングダイアログ（スクリーン）を、7秒以上の場合はプログレスバーを表示させると良いとありました。もちろんケースバイケースです。

モーダリティ

アラートビューやモーダルビューがこれに相当します。

同じコンテキストで一時的に別の操作を終了するために明示的なアクションを必要とする設計手法です。

iOS13以降ではシートと全画面表示の2種類があります。

シート

シートプレゼンテーションスタイルは、メインのコンテンツの上に表示し、カバーされていない領域をすべて淡色表示して、それらとの相互作用を防ぐカードとして表示されます。

親ビューまたは前のカードの上端は、現在のカードの後ろに表示され、 カードを開いたときに中断したタスクを覚えやすくします。

画面を閉じるアクションとして - 画面の上端から下にスワイプ - コンテンツがMaxYの状態で画面を下にスワイプ - ボタンをタップする 複雑なタスクを有効にしない非没入型のモーダルコンテンツのシートを使用します。

全画面表示（Full Screen）

全画面表示スタイルは画面全体をカバーします。 前のビューは完全に覆われ、視覚的な散漫が最小限に抑えられます。 人々はボタンをタップして全画面のモーダルビューを閉じます。

ビデオ、写真、カメラビューなどの没入型コンテンツ、 または写真の編集などのフルスクリーンプレゼンテーションのメリットを活用する複雑なタスクには、フルスクリーンのモーダルビューを使用します。

モダリティの必要性

異なるタスクを選択または実行することに人々の注意を集中させることが重要である場合に使用する。 モーダルは、メインコンテンツから外し、中断アクションを求めるので、 明確な利点を提供する場合にのみ使用することが不可欠です。

モーダルに閉じるボタンを常に含める

たとえば、「完了」または「キャンセル」を使用できます。

閉じる前に確認をとる

何かしらのアクションによってユーザー生成コンテンツが失われる可能性がある場合は、状況を説明し、解決方法を示すアクションシートを提示します。

基本的に、モーダル識別するタイトルを表示

モーダルタスクに入ると、以前のコンテキストから切り替わるので、 新しいコンテキストを明確にすることがお勧めされています。

モーダルビューの外観をアプリと調整する

たとえば、モーダルビューにナビゲーションバーが含まれている場合、アプリのナビゲーションバーと同じ外観を使用する必要があります。

ナビゲーション

ユーザーは自分の期待している機能や画面にアクセスできない状態にならないとナビゲーションに気づかない傾向にあります。 ナビゲーションは自然で親しみやすくアプリの構造と目的をサポートする役割に徹するべきです。

iOSには、3つの主要なナビゲーションスタイルがあります。

• 階層的ナビゲーション

目的地に到着するまで、画面ごとに1つの選択を行います。 別の目的地に移動するには、手順をたどるか、最初からやり直して別の選択をする必要があります。 設定とメールはこのナビゲーションスタイルを使用します。

• フラットナビゲーション

複数のコンテンツカテゴリを切り替えます。 音楽とApp Storeはこのナビゲーションスタイルを使用します。

• コンテンツ主導またはエクスペリエンス主導のナビゲーション

コンテンツ内を自由に移動するか、コンテンツ自体がナビゲーションを定義します。ゲーム、書籍、その他の没入型アプリは通常、このナビゲーションスタイルを使用します。

常に明確なパスを提供

アプリ内のどこにいるか、次の目的地への行き方を常に知っておく必要があります。 ナビゲーションスタイルに関係なく、簡単にたどることが不可欠です。 一般に、各画面へのパスは1つにしてください。 複数のコンテキストで特定の画面を表示したい場合は、 - アクションシート - アラート - ポップオーバー、またはモーダルビュー の使用を検討してください。

すばやく簡単にコンテンツにアクセスできる情報構造を設計すること

最小数のタップ、スワイプ、および画面を必要とする方法で情報構造を整理するべきです

タッチジェスチャーを活用する

スワイプを利用すれば簡単に移動できます。

たとえば、画面の横からスワイプして前の画面に戻ることができます。

標準のナビゲーションコンポーネントを使用する

可能な限り、ページコントロール、タブバー、セグメント化されたコントロール、テーブルビュー、コレクションビュー、分割ビューなど標準のナビゲーションコントロールを使用してください。 ユーザーはこれらのコントロールに慣れており、アプリの操作方法を直感的に理解できます。

ナビゲーションバーを使用して、データの階層を移動する

ナビゲーションバーのタイトルには、階層内の現在の位置を表示できます。 [戻る]ボタンを使用すると、前の場所に簡単に戻ることができます。

タブバーを使用して、コンテンツまたは機能のピアカテゴリを表示します。

タブバーを使用すると、現在の場所に関係なく、カテゴリをすばやく簡単に切り替えることができます。

iPadでは、タブバーの代わりに分割ビューを使用する

分割ビューは、タブバーと同じクイックナビゲーションを提供すると同時に、大きなディスプレイをより有効に活用することができます。

ページコントロール

同じタイプのコンテンツの複数のページがある場合は、ページコントロールを使用します。 ページコントロールは、使用可能なページ数と現在アクティブなページを明確に伝えます。

※個人的にはページコントロールは不要だと思っています。（チュートリアルなど慣れている部分で使うのは良いと思う） 後ろのViewの色などによって目立たない、というかそもそも小さくて目立たないので、 スクロールができることを示すのに十分ではないです。 代替として、画面端に矢印をおいたりセグメントを置くなどがあります。

守ってはいけないiOSデザインとしてこちらにまとめられています。 https://u-site.jp/alertbox/4-ios-rules-break

許可の要求

ユーザーは、アプリが現在の場所、カレンダー、連絡先情報、リマインダー、写真などの 個人情報にアクセスすることを許可する必要があります。 個人情報の利用はユーザーにとって利便性のある機能の提供に限り、基本的に企業側の営利目的で使用することはできません。

※利用の仕方によってはリジェクト対象になるので気をつける必要があります。（実際に位置情報の利用などでありました。）

アプリに情報が必要な理由を説明してください。

システムの権限要求アラートに情報が必要な理由を載せます。 テキストは短く具体的なものにし、文の大文字小文字を使用し、礼儀正しくして、 人々がプレッシャーを感じないようにします。アプリ名を含める必要はありません。

例） 【OK】アプリは、いびき音を検出するために夜間にあなたを記録します。 【NG】より良い体験のためにマイクへのアクセスが必要です。 【NG】マイクへのアクセスをオンにします。

アプリが機能するために必要な場合にのみ、起動時に権限をリクエスト

アプリの操作が個人情報に依存していることが明らかな場合、ユーザーはこのリクエストに悩まされることはありません。

不必要に位置情報を要求しない

位置情報にアクセスする前に、システムをチェックして、位置情報サービスが有効になっているかどうかを確認してください。 この知識があれば、機能で本当に必要になるまでアラートを遅らせたり、アラートを完全に回避したりできます。

設定

一部のアプリは設定機能を提供する必要があります。 ただ、ほとんどのユーザーにとって想定どおりの動きになるようアプリを設計すれば 設定の必要性を減らす事ができます。

可能な限りシステムへ問い合わせる

例えばユーザーに直接住所を入力させるのではなく、現在地情報を取得する許可をシステム側に問い合わせることで 余計な設定の手間を省くことができます。 もし、ユーザーがシステムからの許可を拒否した場合は手入力させます。

優先順位をつける

一次階層にはメインとなる設定を、あまり利用しないものは二次改装にするなど工夫をします。

頻繁に変更されない構成オプションを[設定]で公開

OSの設定アプリは、システム全体で構成を変更するための中心的な場所ですが、 そこに到達するにはアプリを離れる必要があります。 なので、できるだけアプリ内で直接設定を調整する方がはるかに便利です。 もしくはその画面へのショートカットスキーマがあれば、利用し誘導することも可能です。

ざっくりHuman Interface Guideline part1〜デザインテーマ、設計原則〜

はじめに

項目は英語の直訳だったりするので少しわかりにくいかも。ごめんて。

逆に内容は他で参考になったものを入れつつ自分なりに意訳したりしています。

デザインテーマと設計原則はできるだけ一行くらいで説明するように努力してます。

デザインテーマ

明快さ

デザインの重点は機能性。スペース、色、フォント、グラフィックスをシンプルに。

尊敬

コンテンツが引き立つようにベゼル、グラデーション、ドロップシャドウの使用を最小限に。

奥行き

モーダルやプッシュの使い分けによって機能へのアクセスや探索の補助を行う。

設計原則

6つの設計原則が設定されています。 他のUIについての本でも書かれているような、特に重要なものに星を振りました。

美的整合性

アプリに準じたUI/UXを意識する。 基本は機能を分かりやすくする装飾にするべきであり、ゲームは没入感をますように世界観を提示する。

★一貫性

統一された色分け、規則性のある遷移、馴染みのあるアイコンなどを利用しユーザーが想定しているものを影響するべき。

直接操作

スワイプやタップによるジェスチャーを取り入れることによって、直感的な操作をユーザーに体験させる。

★メタファー

現実世界のオブジェクトや出っ張って見えるものは押せそうなど認識し慣れているものを利用する。 （ただ現実のものをそのまま使うより、想像現実を利用することでUXが上がることもある）

★フィードバック

アニメーションとサウンド、実行時のハイライトなどアクションに対してのフィードバックを起こすことで何をしているか認識させる。

★ユーザーコントロール

アプリが処理を実行するのではなく、ユーザーのアクションによって自由に使えるような設計が好ましい。

インターフェース概要

ほとんどのiOSアプリ開発ではUIkitフレームワークを利用します。 カスタマイズして使用されますが、根源的な外観・処理に一貫性があることでどのiOSデバイスでも単一の良いアプリが設計できます。 UIKitが提供するインターフェースには大きく3つカテゴリがあります。

Bar

いわゆるナビゲーションバー。 画面の階層を知らせるのに役にたったり、共通で操作させたいアクションなどを含めることができます。

View

実際に操作する画面。 テキストや画像、アニメーションのようなアプリのコンテンツを提供します。

Control

ボタンやスイッチ、テキストフィールドのようなインタラクティブな操作を提供します。

Swiftのオブジェクト間の通知※他言語の意見も求ム

はじめに

現場で通信処理をModelに切り分ける際に、通信結果取得後にViewへ通知させUI更新させるために、DelegateとColosure Calbackなどパッと思いつく選択肢があって じゃあどれを使おうか悩んだので調べてメリットとデメリットまとめました。

まずはそれぞれのパターンの説明から。

Delegateパターン

swiftではView->ViewControllerやModel->View(ViewController)でよく見かけるパターンです。

抽象的なインターフェースを介して通知、というか処理を行うものです。

swiftではprotocolという実装規則を追加する機能があり（もう一つ役割がありますが）これを利用します。

Model

protocol hogeDelegate: class {
    func updateUI()
}

class Usecase {

  weak var delegate: hogeDelegate?

  func requestUrl(token: String) {
        
        provider.request(.confirmAst(token: token)) { result in
            
            switch result {
            case let .success(response):
                if response.statusCode == 401 {
                    print("Unauthorized")
                }
                
                if response.statusCode == 403 {
                    print("User is not authorized to access this resource with an explicit deny")
                }
                let jsonDecoder = JSONDecoder()
                do {
                    let hogeEntity = try jsonDecoder.decode(HogeEntity.self, from: response.data)
                    self.setAstTel(ast: hogehoge.phone)

                    **delegate.updateUI() <-ココ**

                } catch {
                    **delegate.updateUI() <-ココ**
                }
                
            case let .failure(error):
                **delegate.updateUI() <-ココ**
            }
        }
    }
}

呼び出し側

class ViewController: UIViewController, HogeDelegate {
    let usecase  = Usecase()

    func updateUI() {
        // UI更新処理
       // 引数にデータを持たせて更新なども
    }

    override func viewDidload() {
        usecase.delegate = self
    }

    ~略~
}

Calbackパターン

Callbackパターンでは、完了後の処理をクロージャーで受け取り、そのコールバック用のクロージャーを実行することで通知します。

Model

class Usecase {
~略~

func requestUrl(token: String) {
provider.request(.confirmAst(token: token, completion: @escaping (_ response: AstConfirmation?, _ error: Error?) -> Void)) { result in
            
            switch result {
            case let .success(response):
                if response.statusCode == 401 {
                    print("Unauthorized")
                }
                
                if response.statusCode == 403 {
                    print("User is not authorized to access this resource with an explicit deny")
                }
                let jsonDecoder = JSONDecoder()
                do {
                    let hogeEntity = try jsonDecoder.decode(HogeEntity.self, from: response.data)
                    self.setAstTel(ast: hogehoge.phone)
                    **completion(astConfirmation, nil) <- ココ**
                } catch {
                    **completion(nil, error) <- ココ**
                }
                
            case let .failure(error):
                **completion(nil, error) <- ココ**
            }
        }
    }
}

呼び出し側

 class ViewController: UIViewController {
    let usecase  = Usecase()
    let token = "xxxx"
    override func viewDidload() {
       requestUrl(token: token)  {  response, error in
              // UI更新処理
              // 引数にデータを持たせて更新なども
       }
    }

    ~略~
}

メリデメ表

通知のパターン	通知元と通知先の数	メリット	デメリット
Delegate	1:1	プロトコルにより実装すべき通知インタフェースが明確。 通知先で複数の処理をさせたい場合にもその分通知を送ることができる。	通知するメソッドが1つの場合は、記述量に見合わない。
Calback	1:1	処理の依頼部分と完了後の処理を近くに書くことができ、可読性が高い。 コード量少なくシンプルに書くことができる。	呼び出す箇所を増やすたびに処理が増えていく。 クロージャーのネストが増えすぎると逆に可読性が落ちる。

最後に

ケースバイケースだと思いますが、指摘はもちろん 何か今までの経験だったりメリットデメリットがあれば教えてクレメンス（白目）

※共同編集可能です。

参考:Qita Apple 公式ドキュメント：Delegateについて

App Storeのレビューで表示するスクリーンショットの作成

はじめに

今回はApp Storeのレビューで表示するスクリーンショットについて

勉強していたのでそちらの備忘録&まとめです。

以前、勉強がてら冷蔵庫の中身を管理するアプリを作成しました。

「Rakko」

Rakko

• yusuke watanabe
• フード／ドリンク
• 無料
• 

apps.apple.com

disneych.work

この時はぶっちゃけ仕事と並行してゆっくり2ヶ月以内に

作成しようと思い、画像の作成やスクリーンショットについては

ほぼ勉強していませんでした。

なので、今回はもう少し勉強しようと。。笑

必要な画像のサイズ

必要なのスクリーンショットのサイズは5.5インチと6.5インチです。（2020年8月現在）

アプリのスクリーンショットのサイズを間違えて一度リジェクトをされたことがありました。

なのでここら辺はしっかり調べてやりました。

枠付きのスクショを撮る方法

アプリのレビュー用の画像にどのようなアプリかを載せるために

シミュレータを利用して枠付きのスクショを撮って利用しました。

やり方は

「cmd」+「shift」+「4」+「space」→ 対象のウィンドウをクリック

でできます。

スクリーンショットを作る時に参考にした物

まずは、同じような冷蔵庫管理アプリがどのような画像をやっているか

参考にしました。

次に、ダイアログとかのサービスをしている「Reporo」さんの

スクリーンショット作成術のデザインなどを参考にしました。

他にもいろいろネットで探しましたが、ここら辺は自分で調べた方が

頭に残りやすいと思うのであえて載せませんがたくさんありました。

アプリストア用スクリーンショット作成ガイド | CE（カスタマーエンゲージメント）プラットフォームRepro（リプロ）

最終的なレビュー用画像

こんな感じになりました。

んーなんだか安っぽい感じがまだ抜け出ないですが、

コレは単に自分のセンスとデザインの勉強不足ですね。(/ _ ; )

一個前のやつはこんな感じです。

typo多い自分にとって過去一レベルで便利だった

はじめに

※この記事はXcode使う方向けです。

レビューでtypo指摘されるとすごく恥ずかしいですよね。。 完璧だぜ！って思って指摘がtypoってもう。。。

そんなこんなでチェックツール探してたんですが、 なんとそもそもXcode11からチェック機能ついてたやつ〜！

使い方

至ってシンプルです。 動作も遅くなるとかナッシング。

Edit > Format > Spelling and Grammar > Check Spelling While Typingでタイピングごとにファイルにチェックが。

例えばそのプロジェクトでしか使わない「hogehoge」とか造語も引っかかるんですけど

Ignore Spelling（スペルを無視）かLearn Spelling（スペルを学習）で頻出単語は警告を消します。

最後に

いや、英語力を上げるのが良いってのは分かるんですが誰にでもあるじゃないですか、typo。

そんな時にこれで精神衛生的にも楽だし、レビューも手間省けるしで良いと思いました。 感謝。

CLIでのBitrise導入（Github EnterPriseを利用している時など）

どうもおはようございます、こんにちは、こんばんは。

はじめに

BitriseにはWebのGUIでプロジェクトを追加して設定していく方法とCLIで追加する方法がありますが、 今回GithubがEnterPriseだったので、CLI一択でした。

GUIについても色々ネットで調べると出てきますので今回はCLIの流れを載せていきます。

Bitriseにアプリの追加

1. Bitriseにログインする。（アカウントはこちらに記載→　01.共通アカウント）
2. Add new App をタップして from CLIで続行。
3. ページ下部の bashコマンドをコピーする。
4. Specify how Bitrise will be able to access the source code: Automaticを選択し、Do you need to use an additional private repository?は I need toを選択する

5. What bitrise.yml do you want to upload? は 既に使っているbitrise.ymlがなければ、Run the scanner to generate a new bitrise.yml を選択。

6. 5を行うと現在ローカルで参照しているブランチをscanするので、そのブランチでよければそのまま続行する。

7. ipaファイルのExportの仕方を聞いてくるので、用途によって選択する。（develop,enterpriseなど）
8. どの証明書を使用するか聞かれるのでExportの種類によって合ったものを選択する。
9. bitrise.ymlを自動作成される設定の場合はアーカイブが行われて成功の表示が出る。

Bitriseワークフローの実行

実行にはpushやPRなどのトリガーを設定して自動的に実行する場合と

Bitriseに追加したアプリの詳細画面から実行する場合がある。

githubのイベントを受信するにはbitriseのSetting画面から取得できるwebhookを対象プロジェクトに設定するのと

Workflowの設定画面のTriggerタブで設定が必要。

また、Secretsに設定している変数を使う場合はプルリクからの参照も許可する。

Slackへの通知設定

通知用のチャンネル作成とwebhookurlを取得をして、

Bitriseのワークフローにslack send messageを追加して、作成したURLを設定する。

参考：https://qiita.com/powerispower/items/f8b9e358649df2e4b905

Deploygateとの連携

workflowのステップでdeploygateを追加。 deploygateのAPIキー、グループ（もしくはアカウントユーザー）情報をアカウント画面から確認し設定する。 App file path　を$BITRISE_IPA_PATHにする。 必ずXcode Archiveのステップの後にdeploygateのステップを追加する。 ※リリースノートなども書けるが、追加ではなく自動配信時に設定が必要。

参考： https://devcenter.bitrise.io/jp/deploy/deploy-apps-to-deploygate-from-bitrise/

https://qiita.com/kyoro353/items/200d5b34b9f5805dd43a

課題と対応内容一覧

• Bitriseのデフォルトのstackがxcode10.2だったため、マルチモーダルアプリのSceenDelegateに対応しておらずビルドが失敗した。

  • 対応

デフォルトのstackをXcode11以降にする。（今回は導入時が11.4だったためそれに合わせた。）

• 案件特有のログインライブラリがシミュレータ 用と実機用とあるため、現状テストをするにはシミュ用でdeploygateで配信するには実機用にする必要あり。

  • 対応

開発環境ごとに証明書の切り替えが必要だと思われるが、現状そこまでの動作確認、調査は未完了。 　また、アーキテクチャごとに設定して、ファイルのあるフォルダのパスを設定する。

証明書のようなセキュアな情報をどのように扱うか検討が必要。（fastlaneの利用？）

ブログの投稿は基本毎日19時頃する予定です。

なんとなく気になったdYSM調べた【2020年】

はじめに

なんとなくdYCMという言葉を見つけて

そういえば、コレってなんなのかなーと思ったので調べました。

dYCMとは

dSYMはクラッシュレポートのメモリアドレスに

対応するシンボル(クラス名やメソッド名)を持っているとの事なので

バイナリファイルにシンボル情報が入っているそうです。

どういう時に使うの？

結論から言うと

「iOSのクラッシュログをSymbolicate（復元）するため」

です。

生のクラッシュログはアドレスで表記されているため

そのままだと分かりません。（制約の警告とはちょっと違うけどあんな感じ）

アプリのdSYMファイルを用いてシンボル化（Symbolicate）することで

どこで落ちてるか見ることができるようになります。

詳しいやり方は、以下の参考サイトに書かれていました。

参考サイト

iOSのクラッシュログをSymbolicate（復元）して解析する - Qiita

SwiftUIやってて出てきたGeometryReaderって【2020年】

はじめに

SwiftUIでサイドメニューを実装しようと

SwiftUIでSwiftUIでサイドメニュー（ハンバーガーメニュー）を表示する - すいすいSwift

こちらのサイトをみていたら GeometryReader という記述がありました。

SwiftUIのおそらくグラフとかアニメーションのTutorialで出てきたと思うのですが、自分は最初はそこは必要ないと思い飛ばしていました。

なので今回は自分が調べた内容を備忘録としてまとめます。

公式の定義

GeometryReaderの説明は独自のサイズと座標空間の関数としてコンテンツを定義するコンテナービュー。

親レイアウトに柔軟な優先サイズを返します。

とあります。

親のViewのサイズや座標空間を取得して子のViewで使えるって感じですかね。

サイドメニューの参考サイトの場合は画面のサイズを取得するため body下で利用したのでBodyのサイズ、つまり画面サイズが取得できたと。

画面サイズの取得の仕方としては

UIScreen.main.boundsでも取得はできそうです。

逆に親Viewを指定というか選ぶ場合は

.background(指定したい親View)をすればいけるみたい。

他にも参考サイト先で面白い内容があるのでもう少し勉強しようと思います。

参考サイト

SwiftUIの肝となるGeometryReaderについて理解を深める - Qiita

Apple公式Doc

[SwiftUI] GeometryReaderでViewのサイズを知る

Zeplinのちょっとしたチームルール

はじめに

現場ではZeplinを元にアプリのUI実装を進めているのですが、

その時に色や画像はもちろん、デザイナーの方とコメントでやりとりするのですが

今の現場でのルールを備忘録的に載せようと思います。

こんなルール使ってるよとか、こういう使い方良いよとかあれば教えていただけると嬉しいです！٩( 'ω' )و

コメントルール

基本的にデザイナーさんへの細かい質問（pxの違いや端末差分の時の制約についてなど）はZeplin上で行います。

質問時は黄色のタグでコメントし、回答をもらって解決したらタグを青色に変更します。

それ以外の仕様に関わるデザインについてはPO（アジャイル開発なので）に確認を行いPO経由でデザイナーさんに修正依頼を行います。

色ルール

色の名前はそのままコードの命名で使いたいのでキャメルケースで設定して

もらってカラーコード見たいのを作ってもらいます。（Swiftなのでこの命名規則）

プロジェクトを対応OS、言語にしてもらって（SwiftやKotlinなど）

px, dp, 画像ダウンロード時のサイズなどを統一してもらうようにします。

なので、例えばiOSならhoge.png, hoge@2x.png, hoge@3x.pngがワンタップでダウンロードできて便利です。