主な概念

次のユースケースのセクションでは、最も一般的な使用シナリオについて説明し、 HERE SDK for Android を最大限に活用するためのヒントとわかりやすいガイドラインを示します。

このガイドの使用方法

このガイドは、任意の順序で読むことができます。 すべてのセクションが互いに独立しているので、任意のセクションをスキップして、最も関心のあるトピックに直接進むことができます。

• 使用例のセクションでは、このユーザー ガイドに付属するサンプルアプリを見つけることができます。
• HERE マップを表示する最初のアプリの作成に関心がある場合 は、利用開始セクションで最初の簡単な手順を確認してください。
• サポートされているフィーチャーを見つけるに は、フィーチャー・一覧を参照してください。
• この 開発者ガイドでカバーされている利用可能なユースケースを含む ここの Q&A セクションを検索します。
• 3.x レガシーエディションから移行する場合は、移行ガイドを参照 してください。このガイドでは、 4.x のフィーチャーと比較して、主な 3.x のフィーチャーを示すマッピングテーブルと、前述の各フィーチャーの再利用可能なコードスニペットへのリンクを参照できます。

表記規則

このガイドでは 、 コールバックやリスナー名など、すべての種類の情報およびその他の詳細情報を表示するために、ラムダ表記を使用しないことを推奨します。 Android Studio で は匿名クラスと lambdas の間のワンクリック変換がサポートされているため、ご使用用途に合わせてサンプルを簡単に変更できます。

オブジェクトを廃棄

インスタンスが参照されなくなった場合、または null に設定された場合、すべての HERE SDK クラスが Android によってガベージコレクションされます。

アプリの有効期間が終了すると、 SDKNativeEngine.getSharedInstance().dispose()を呼び出してリソースを解放できます。 また、 SDKNativeEngineへのすべての参照をnull に設定する必要が あります ( 存在する場合 ) 。 呼び出し dispose() によって保留中のリクエストが停止され、まだ実行中の開いているファイルおよびデータベースが閉じられます。 関連する HERE SDK フィーチャーdispose() を呼び出した後は、 HERE SDK を再度初期化しない限り、使用しないでください。 既定のコンストラクタSearchEngine()またはRoutingEngine() などのエンジンを作成した場合、または既定のコンストラクタを使用した場合は、これらのインスタンスも再作成する必要があります。 基本的に、 SDKNativeEngineの同じインスタンスを使用したすべてのエンジンは、廃棄後に再作成する必要があります。

コールバックとリスナー

• HERE SDK は 、検索結果などの単一のイベント通知のコールバックを公開します。
• ジェスチャイベントなどの繰り返し発生するイベント通知には、リスナー が使用されます。 複数のリスナを設定できる場合 は、メソッドパターンadd_x()とremove_x()なり、命名規則として使用されます。 一度に設定できるリスナーが 1 つだけの場合は、プロパティパターンが使用されます。 リスナを停止するには、 listener プロパティをnullに設定します。
• 開発者は、コールバック の範囲内のエラーを適切に処理する責任があります。 ガイドラインとして、例外をスロー可能性のあるコードを処理する必要があります。

デバッグログ

このクラスLogControl では、 アプリのリリースビルドであっても、さまざまな定義済み値LogLevel の HERE SDK メッセージをログに記録できます。 HERE SDK を初期化する前に、必ずLogControlを呼び出してください。

// Disable any logs from HERE SDK.
// Make sure to call this before initializing the HERE SDK.
LogControl.disableLoggingToConsole();

上記のコマンドを使用すると、 HERE SDK 関連のすべてのコンソールログを停止することができます。 問題を調査するときに重要なログメッセージが失われる可能性があるため、デバッグビルドではお勧めしません。

LogAppender インターフェイスを使用して、独自のログクラスを LogControl クラスに挿入することもできます。

コードスニペット

表示されているコードスニペットは、自分のアプリケーションで使用できるベストプラクティスのサンプルコードをカバーしています。 ただし、簡潔にするため、またこのガイドの教育的アプローチを影にしないために、特にエラー処理や堅牢なスレッドに関しては、すべてのエッジ シナリオが処理されるわけではありません。場合によっては、明白なコードが省略されていますが、付属のサンプル アプリで見つけることができ、一連の有効な HERE 資格情報を使用して、サポートされているデバイスに即座に構築し展開できます。

設計の原則

付属の サンプル アプリは同じ構造に従います。 HERE SDK のサンプルコードは、できるだけ周囲のプラットフォームコードから分離されます。 これにより表示されている API の関連する部分を簡単に確認できるよう願っています。 各例のアプリは、 HERE SDK の初期化元と同じエントリポイントに従います。 各アプリは HERE SDK のさまざまな側面に焦点を当てているため、そのコードは、クラス名に "...example.java" を付けてポストフィックスされた 1 つのクラスに含まれています。 ほとんどの MapView 場合、このクラスは、作業を開始するためにへの参照を取得します。

一般的な POJO (plain-old-java-Object) の原則に従って、サンプルコードはほとんどの Android の依存関係から解放されます。代わりに、ほとんどの場合、 HERE SDK の使用方法を示す純粋な Java コードです。

非推奨およびベータ版

HERE SDKの開発チームは、一貫したインターフェイスとともに、最も柔軟でありながら最も使いやすいAPIを提供するために、利用可能なAPIを常に見直し、改善しようとしています。

同時に、通常隔週で発生するリリース全体で安定したAPIを確保したいと考えています。 したがって、非推奨プロセスに従います。 私たちのポリシーは、 リリースノートで非推奨が発表された後の次のメジャーバージョンから数えて2つのメジャーバージョンまでの非推奨APIを維持することです。つまり、6か月から9か月の間です。 APIリファレンスでは、インターフェイスが非推奨としてマークされたときに、影響を受けるバージョンを常に確認できます。

新しいAPIや最終的には不安定なAPIの一部は 、APIリファレンスで「ベータ」と表示されています。 ベータ版リリースでは、特に明記されていない限り、非推奨プロセスは実行されません。 ベータAPIを使用する場合は、いくつかのバグや予期しない動作が発生する可能性があることに注意してください。

もちろん、改善の可能性についてのフィードバックには常に興味があります。

依存関係管理

現在、たとえば Gradle を使用した依存関係管理はまだサポートされていません。 つまり、 HERE SDK AAR バイナリは 、「利用開始 」の項で説明されているように、ローカルのアプリケーションプロジェクトにコピーする必要があります。

HERE SDK を他のフレームワークと併用

HERE SDK は他のフレームワークと併用可能 たとえば、開いている道路マップをSearchEngineと結合することもできます ( 結合する場合 ) 。

• Xamarin ： HERE SDK は Xamarin をサポートしていませんが、 HERE SDK が提供するパブリック API の上に Xamarin のラッパーを実装できます。 Xamarin の関連するテストツールをサポートするために、 HERE SDK に変更を加えることはありません。

• React Native: React Nativeはサポートされていません。 ただし、お客様ご自身でラッパーを実装することはできますが、このようなタスクに対するサポートは提供していません。

HERE SDK はスレッドセーフですか ?

HERE SDK がスレッドセーフであることは保証されていません。また、メインスレッドから SDK を呼び出す必要があります。 内部的には、 HERE SDK はほとんどの作業をバックグラウンドスレッドにオフロードしますが、コードへのコールバックは常にメインスレッドで発生します。 一般に、呼び出し元はスレッドセーフであることに注意してください。 たとえば、コードが同期されていない限り、異なるスレッドでエンジンを再利用することは安全ではありません。

TaskHandles を使用して非同期操作をキャンセル

ほとんどの非同期メソッドは 、即時の戻り値としてTaskHandleを提供しますが、操作の最終結果は完了ハンドラで遅延して返されます。 TaskHandle はステータス情報を提供し、進行中の操作を中止できます。

ユニットテスト

すべてのクラスが完全にモックアップ可能であるため、 HERE SDK を使用するアプリロジックのユニットテストを簡単に記述できます。 リリースパッケージに heresdk-mock は、すべての HERE SDK クラスのモックを有効にする JAR ファイル が含まれています。 以下に、 Mockito を使用した例を示します。 これは、分岐されたオブジェクトを作成できる他のほとんどのフレームワークとも連携します。

@RunWith(MockitoJUnitRunner.class)
public class TestExample {

    @Test
    public void testNonStaticMethod() {
        Angle angleMock = mock(Angle.class);

        when(angleMock.getDegrees()).thenReturn(10.0);

        assertEquals(10.0, angleMock.getDegrees());
        verify(angleMock, times(1)).getDegrees();
        verifyNoMoreInteractions(angleMock);
    }

    ...
}

アプリ build.gradle の設定で次の依存関係を使用します。

def getHereSdkArtefactName() {
    def aarFile = fileTree(dir: 'libs', include: ['heresdk-*.aar']).first()
    // Filename without extension is necessary.
    return org.apache.commons.io.FilenameUtils.getBaseName(aarFile.name)
}

// Exclude HERE SDK's aar from unit test's dependencies.
configurations.testImplementation {
    exclude module: getHereSdkArtefactName()
}

dependencies {
    implementation(name: getHereSdkArtefactName(), ext:'aar')

    implementation 'com.android.support:appcompat-v7:28.0.0'
    implementation 'com.android.support.constraint:constraint-layout:1.1.3'

    // Keep in mind that the original HERE SDK aar must be excluded from
    // the test dependency, see above.
    testImplementation fileTree(dir: 'libs', include: ['*mock*.jar'])
    testImplementation 'junit:junit:4.12'
    testImplementation 'org.mockito:mockito-core:3.1.0'
}

この設定では、 HERE SDK はユニットテストの実行時に模擬 JAR を使用し、アプリの構築時に実際のアプリ AAR を使用します。heresdk-edition-mock-version.jarを heresdk-edition-version.aarと同じapp/libsフォルダに配置 します。

カバレッジ

サポート対象の国および言語の詳細については、[カバレッジページ]を参照してください。

エンジン

HERE SDK には、 複数のモジュール（またはエンジン）が含まれています。これらのモジュールは、RoutingEngineを使用してルートを計算する、またはSearchEngineを使用して検索結果を要求するなどの特定のタスクを実行するために呼び出されます。 HERE SDK で使用できるエンジンは他にも数多くあります。詳細については、以下の専用の章を参照してください。 ただし、ほとんどのエンジンで共通の概念が採用されているため、使いやすくなっています。 例 :

• すべてのエンジンが非同期でタスクを実行し、メインスレッドで結果を受け取ります。
• すべてのエンジンは、同様のインターフェイス、コールバック、およびエラー処理を共有します。
• 1 つのエンジンの複数のインスタンスを並行して開始できます。
• オンライン接続が必要です。

SDKNativeEngineを除くすべての HERE SDK エンジン は、相互に独立して動作でき、データを要求するには HERE Credentials が必要です。

パラメータレスのコンストラクタを使用して、任意のエンジンを作成できます。 例 :

try {
    searchEngine = new SearchEngine();
} catch (InstantiationErrorException e) {
    throw new RuntimeException("Initialization of SearchEngine failed: " + e.error.name());
}

この既定のコンストラクタを使用するには、 HERE SDK が既に初期化されており、SDKNativeEngineの共有インスタンスがSDKNativeEngine.setSharedInstance(sdkNativeEngine)を直接呼び出して設定されているか、またはSDKNativeEngine.makeSharedInstance(context, options)を呼び出して暗黙的に設定されている必要があります。

まれなユースケース シナリオでは、次のセクションに示すように、SDKNativeEngine の個々に作成されたインスタンスを受け取るオーバーロードされたコンストラクタを使用できます。

初期化

HERE SDK 4.12.1.0 以降では、 HERE SDK を手動で初期化する必要があります。 利用開始 ガイドに従って、この方法を確認してください。

• アプリ がアプリ の開始後すぐにマップ ビュー を表示する場合は、ほとんどの使用例で利用開始 ガイドに従うだけで十分です。 ただし、
• アプリで後からマップ ビュー を表示する必要がある場合、または初期化を遅延する場合は、後で HERE SDK を初期化することもできます。

HERE SDK を初期化する手順は、次のとおりです。

1. 廃止されたInitProviderを非アクティブ化します ( このステップは HERE SDK 4.15.0 で廃止されます ) 。
2. HERE SDK で SDKOptions を作成して初期化 し、新しいSDKNativeEngineを作成するために使用します。

SDKNativeEngine およびSearchEngine などの他のエンジンの作成は、無視できる短時間で同期的に行われます。

HERE SDK は、次の 2 つの方法で初期化できます。

• SDKNativeEngine との共有インスタンス SDKNativeEngine.makeSharedInstance(context, options)を作成します。
• SDKNativeEngine​(context, options) を介して SDKNativeEngine の個別のインスタンスを作成します。

SDKNativeEngine.makeSharedInstance(context, options) を呼び出すと、HERE SDK で使用できる SDKNativeEngine の共有インスタンスが作成されます。 このシングルトンアプローチでは、パラメータを必要としない既定のコンストラクタ (SearchEngine()) を使用できるため、 SearchEngineなどのエンジンを簡単に作成できます。 内部的に、SearchEngineは初期化時に作成したSDKNativeEngineの共有インスタンスを使用します。 したがって、 HERE SDK を再初期化する場合、パラメータレスコンストラクタを使用して作成されたすべてのエンジンも再度作成する必要があります。

また、まれな使用例で SDKNativeEngine は、各フィーチャーエンジンに個別のインスタンスを設定できます。

SearchEngine searchEngine = new SearchEngine(sdkNativeEngine);

一般に、SDKNativeEngineを複数回初期化する必要はありません。 一度に設定できる共有インスタンスは 1 つだけです。この設定は、SDKNativeEngine.makeSharedInstance(context, options)を呼び出したときに暗黙的に行われます。 または、 使用可能なコンストラクタを使用して、 SDKNativeEngine のインスタンスを直接作成することもできます。 複数のインスタンスを個別に作成する場合、共有インスタンスは設定されず、上に示したように、コンストラクター パラメーターとして SDKNativeEngineのインスタンスを使用して各機能エンジンを作成する必要があります。この方法では、SearchEngineやRoutingEngineなどのフィーチャーエンジンを、異なるSDKOptionsを持つ SDKNativeEngineの異なるインスタンスと一緒に使用できます。

個々のインスタンスは、SDKNativeEngine.setSharedInstance(sdkNativeEngine)を呼び出して明示的に共有インスタンスとして設定できます。 注意 : この場合 dispose() は、SDKNativeEngine.getSharedInstance().dispose()を呼び出し て、前のインスタンスがあることを確認してください。 SDKNativeEngine.makeSharedInstance(context, options)を呼び出してグローバルインスタンスを作成する場合、この呼び出しは不要です 。便宜上、この呼び出しによって、以前に共有されたインスタンスは内部的に破棄されます。

複数のインスタンスSDKNativeEngine が同じ アクセスキー ID を持つことはできません 。また、キャッシュパスは アクセスキー ID ごとに一意であることが保証されますすでに使用されているアクセスキー ID を使用して 2 番目のインスタンスが作成された場合 、InstantiationExceptionはスローされます。 経験則として、複数のインスタンスが必要な場合は、それぞれに異なる資格情報 のセットも必要です。

キャッシュの詳細については、 ここを 参照してください。

ヒント : 資格情報の保護

資格情報は、使用を意図していない第三者による悪用を防ぐために保護される必要があります。

資格情報 を安全に保つ 1 つのオプションは、 SSL 接続を使用して、それらを安全なサーバーに保存し、要求によって取得することです。

ベストプラクティスについては、次の点を考慮してください。

• 機密データがプレーンテキストで保持されないようにするため。
• 安全な通信チャネルを使用して資格情報を転送します。
• デバイスのセキュリティメカニズムと強力な暗号化を使用して資格情報を保存します。
• 改ざん防止およびデバッグ防止のコードを追加して、動的なランタイム実行中に潜在的な攻撃者がデータを傍受できないようにします。
• アプリケーションの使用状況を追跡して異常を検出します。

マップ ビューの有無にかかわらない、エンジンの使用

エンジンの動作にマップ ビュー は必要ありません。 したがって、マップ ビュー をアプリケーションに追加せずに、エンジンをスタンドアロンで実行できます。 このようにして、特定のエンジンのみを中心にアプリ を作成できます。 マップ ビュー を使用する場合と使用しない場合 - 新しいエンジンを作成する手順はまったく同じです。 HERE SDK を事前に初期化してください。

HERE SDK オプション

HERE SDK は、SDKNativeEngineに直接設定するか、SDKOptionsでエンジンを初期化するときに設定できるさまざまなオプションを使用して初期化できます。

API リファレンス に特にメモがない限り、どのオプションも永続化されません。 つまり、 HERE SDK を再度初期化する場合は、保持する場合に前のオプションを再度設定する必要があります。

同じことは、さまざまな機能エンジンまたは RoutingEngine などの機能を使用して Route を計算するときに CarOptionsに設定できるオプションにも当てはまります。

オフラインスイッチ

HERE SDK は、 HERE SDK 無線をサイレントにするためのグローバルオフラインスイッチを提供します。 このオフライン モード は、 HERE SDK がオンライン接続を開始できないようにします。

SDKNativeEngine.getSharedInstance().setOfflineMode(false);

たとえば、このモードでは、新しいマップタイルがキャッシュにロードされません。 Navigate Edition を使用している場合でも、オフライン検索 ( 専用エンジン経由 ) 、オフラインルーティング ( 専用エンジン経由 ) 、オフラインガイダンスなどのフィーチャーを使用できます。

デバイス自体がフライトモードに設定されているかどうかは問題ではありません。 スイッチがアクティブの場合、 HERE SDK からの要求の発信がすべてブロックされます。 そのため、オフライン モード を再度無効にするまで、オンラインデータは使用されません。

ただし、HERE SDKを初期化するときに、いくつかの要求が行われることがあります。 HERE SDKを初期化する前にアプリケーションをオフラインで起動したい場合は 、SDKOptionsでフラグofflineModeをtrueに設定 します。 実行時にこれを変更する予定がない場合は、このフラグだけで完全にオフラインで動作できます。

HERE SDK がオフラインになると、進行中およびキューに入っているすべてのリクエストが停止します。

バックエンドサービス

オフラインで動作しないフィーチャーの場合、 HERE SDK はさまざまなバックエンドサービスから内部的にコンテンツを要求します。 すべてのバックエンドサービスは、次のドメインから要求されます。

• here.com
• hereapi.com

たとえば、search.hereapi.comのようなサブドメインはここに一覧表示されません。 多数の URL を使用して いますが、これらの URL はすべてhere.comドメインおよびhereapi.comドメインの下にあります。 これらの各ホスト名は、 GeoIP 経由で検出された地理的条件に応じて、複数の IP アドレスのセットに部分的に解決されます。 また、 IP アドレスは変更される可能性があります。 必要に応じて、ドメインのみを有効化 / ホワイトリスト化し、ワイルドカードを使用して、すべてのサブドメインで同じことを行うことをお勧めします。

外部 REST API で使用するアクセストークンを取得

HERE SDK が初期化されるたびに、新しいアクセス トークン が内部的に生成されます。 複数 SDKNativeEngine のインスタンスがある場合、各インスタンスは独自のトークン を保持します。 コールバック がAuthentication.authenticate(SDKNativeEngine.getSharedInstance(), callback)経由でトークン を提供する経由でトークン authenticationData.token を更新および取得することもできます。このトークン を使用して、外部 HERE REST API にアクセスできます。

HERE SDK 自体を使用する場合 は、トークン を把握する必要はありません。これは内部のみに必要で、 HERE SDK がトークン 生成を自動的に処理します。

不正使用からバックエンドを保護 するために、生成されたトークン数が多すぎる場合、またはアクセスされたサービス数が多すぎる時間帯にレート制限が適用されることがあります。 このような場合、エンジンが requestLimitReached エラーまたは類似のもので応答します。 アプリ の使用率が非常に高いと思われる場合は、事前に HERE の担当者に連絡して、必要に応じて上限を調整してください。

トランザクションおよび使用状況の統計情報

このUsageStatsクラスを使用すると 、 HERE SDK ネットワーク使用状況の統計情報を収集して、アップロードおよびダウンロードされたすべてのデータをカウントできます。 SDKNativeEngine.getSdkUsageStats() およびSDKNativeEngine.enableUsageStats() を使用して、ネットワークの統計情報を取得します。 SDKNativeEngine.clearPersistentUsageStats()とSDKNativeEngine.clearUsageStatsCache()を使用して、カウンタをリセットします。

enableUsageStats()の呼び出しは HERE SDK によって保持されないことに注意してください - 他の設定の場合と同様です。したがって、UsageStats　は、実行時に以前に有効にしていた場合、およびネットワーク統計の追跡を継続したい場合には、HERE SDK の初期化前に毎回有効にする必要があります。

また、外部 REST API を使用して 、 HERE SDK で行われたトランザクションを追跡することもできます。 HERE Usage API を使用すると、このようなデータを要求できます。 組織 ID org123456789 と開始日と終了日の例 :

https://usage.bam.api.here.com/v2/usage/realms/org123456789?startDate=2022-07-01T10:39:51&endDate=2022-08-30T10:39:51

詳細については 、コスト管理のドキュメントを参照してください。

トランザクションおよび使用状況の統計情報では、同じ資格情報セットを使用する複数のアプリを区別するようにスコープを設定する必要があります。 これには、 MAU のカウントも含まれます。 アプリ単位ではなくアカウント単位で請求されますが、このようなデータはアプリ単位で分離することが妥当です。1 つのアプリのみを計画している場合は 、この設定は該当しません。 それ以外の場合は 、以下の範囲のセクションで詳細を参照してください。

複数のアプリを区別する範囲を設定

• HERE SDK で開発しているアプリが 1 つだけの場合は 、 HERE platform にあるプロジェクトマネージャーで作業する必要はありません。次のセクションは省略できます。

• 複数のアプリを開発している場合は、同じ資格情報のセットを再利用する必要があります。 各アプリの統計情報を個別に表示できるようにするには、スコープを設定する必要があります。 次のセクションを参照してください。

このセクションでは、 アプリ 資格情報 とプロジェクト範囲の相関関係について説明します。 プロジェクト範囲は、特定の開発プロジェクトの特定のサービスを決定するために使用されます。 スコープを設定すると、特に定義されていない他のすべての HERE サービスへのアクセスが無効になります。 通常、 HERE SDK を使用してアプリを開発する場合 は、 1 つのアプリに 1 つの資格情報セットを使用するだけで十分です。 この場合、プロジェクト範囲の設定も必要ありません。 この場合、このセクションは あなたには該当しません。

HERE SDK で複数の異なるアプリを開発するために資格情報のセットを使用する場合は、以下を参照してください。

HERE platform では 、プロジェクトをサポートしています。このプロジェクトを使用すると、開発者はアプリを管理でき、アプリアクセスおよびそのエンタイトルメントをさらに制限およびカスタマイズできます。 これは、 HERE platform にログインしたときに見つけることができるプロジェクトマネージャーで行います。 プロジェクトの設定方法の詳細については、『 IAM ガイド』を参照してください。

さらに、 プロジェクト管理者 を介してプロジェクトでアプリを設定すると、ダウンロードした 使用状況レポートでアプリを参照できます。 これにより appId、に加えて、プロジェクトの HERE リソースネーム 値に基づいて、アプリの背後にある使用状況の統計情報を区別できます。 HERE リソースネーム （HERE リソースネーム ）がアプリ / プロジェクトを一意に識別します。

その他の使用例としては、 ステージングアプリをテストするためのデバッグ範囲と、 最終的なアプリの本番範囲を定義する場合があります。

HERE アカウントには 、モバイルアプリケーションを参照しないアプリセクションもあります。 この アプリ セクションは ここでは無視できます。以下のように、 開発する予定のモバイルアプリに属するプロジェクトをプロジェクト管理者が構成するだけでかまいません。

必要な HERE サービスの設定方法

1. platform.here.com アカウントにログインします。
2. プロジェクトを作成し、後で使用できるようにプロジェクトの HERE リソースネーム 文字列をコピーします。 プロジェクトマネージャーでは、複数のプロジェクト / アプリを定義できます。 各プロジェクト / アプリは、次のように一意の HERE リソースネーム によって識別されます。"hrn: here:authorization::olp-here-sdk-navigate: project/abcd123" 実際の値は、プロジェクト / アプリで一意です。
3. プロジェクト設定で、 HERE SDK で必要なバックエンドサービスを指定します (リソース -> サービス -> 「サービスをリンク」 ) 。

必要なサービス

• HERE Isoline Routing
• HERE Network Positioning
• HERE Route Matching
• HERE Raster Tile
• HERE Routing
• HERE Routing - Intermodal
• HERE Routing - Transit
• HERE Search - Autocomplete
• HERE Search - Autosuggest
• HERE Search - Browse
• HERE Search - Forward Geocoder
• HERE Search - One Box Search
• HERE Search - Place ID Lookup
• HERE Search - Reverse Geocoder
• HERE Search - Traffic API
• HERE Vector Tile
• HERE Vector Tile - Traffic

アプリでスコープを設定

次の手順では、アプリでプロジェクトのスコープをプログラムで設定します。この手順では 、 上でコピーしたプロジェクトの HERE リソースネーム 文字列を使用します。 例 : "hrn: here:authorization::olp-here-sdk-navigate: project/abcd123" 実際の値は、プロジェクト / アプリで一意です。

HERE SDK を初期化する前に、プロジェクトの一意の HERE リソースネーム 値をスコープとして設定します。

sdkOptions.scope = "YOUR_PROJECT_HRN";

以下のスクリーンショットは、 プロジェクト ID と結果の HERE リソースネーム 値を持つプロジェクトの例を示しています。

プロジェクト ID は 一意である必要があり、組織のアカウントの有効期間中は変更できません。 スクリーンショットで確認できるように、 HERE リソースネーム 値にも影響があります。 スコープまたは HERE リソースネーム がアプリケーションによって設定されている場合、そのスコープは認証およびアプリケーションの内部トークン作成に使用されます。

不明なスコープが設定されている場合、認証の試行は失敗し、アプリケーションログにそのことが示されます。

詳細については、 IAM ガイドを参照してください。 また 、プロジェクトの管理についての情報も含まれています。

HERE SDK では、月間アクティブユーザーをどのように計算しますか ?

「月間アクティブユーザー」または「 MAU 」とは、 HERE レコードによって決定された、 HERE SDK を介して HERE API を呼び出すか、または 1 か月以内に HERE SDK を使用する一意のデバイスを意味します。

利用可能な MAU プランの詳細については、 商用利用規約を参照してください。

バグが発生したときにサポートを受ける

クラッシュや予期しない動作が発生した場合は、 問題 の再現方法の詳細をお知らせください。

HERE SDKのネイティブC++スタックでクラッシュが発生した場合、クラッシュログにはクラッシュが発生したアドレスのみが表示されます。 クラッシュが発生したスタックトレースを確認するには、これらのアドレスを記号化する必要があります。

統合したリリースに付属している記号のみを使用してください。 他のリリースのシンボルは動作しません。

Google Play コンソールを使用したクラッシュログのシンボル化

Google Play ストアに展開されているアプリについては 、アプリの各バージョンのシンボルファイルをアップロードして、次のようにクラッシュレポートを取得する必要があります。

1. Google Play コンソールを 開き、アプリを開きます。
2. 左側のメニューで、 [ リリース ]>[ アプリバンドルエクスプローラ ] を選択します。
3. 右上隅のピッカーを使用して、デバッグシンボルが含まれている ZIP アーカイブを選択します。
4. 「ダウンロード」タブを選択し、「アセット」セクションまでスクロールダウンします。
5. 該当するデバッグシンボルのアップロード矢印をクリックして、アプリのバージョンのシンボルファイルをアップロードします。詳細について は、 ここを 参照してください。
6. その後、クラッシュおよび ABR が難読化解除されます。 アプリで個々のクラッシュおよび ECR の難読化解除されたスタックトレースを表示するには 、 Google Play コンソールの [ クラッシュおよび ECR ] ページに移動します。

クラッシュログのシンボル化もローカルで行うことができます

ローカルでネイティブクラッシュを表すには、次の手順を実行します。

1. Logcat または ADB を使用してクラッシュログを収集し、 .txt ファイルに保存します。

adb logcat -d > your_crashlog_filename.txt

1. .so リリースパッケージに同梱されているシンボルファイルを取得します。 これらの .so ファイルは debug-symbols ZIP ファイル内にあります。
2. ビルドアーキテクチャに応じて、 arm64-v8a またはのいずれかのファイルパスをコピーし armeabi-v7aます。
3. ndk-stack 次のツールコマンドを実行します。

path-to-Andorid-sdk/Android/sdk/ndk/24.0.8215888/ndk-stack -sym path-to-directory-with-binary-of-desired-architecture -dump path-to-crash.txt

このリリースでは、 NDK 24.0.8215888 を使用してください。

お問い合わせください

弊社にご連絡していただく際は、少なくともHERE SDKのバージョン、プラットフォーム、エディション、ログを必ず含めてください。 以下に、迅速な対応に役立つバグレポートのチェックリストを示します。

• 問題の種類： たとえば、クラッシュや予期しない動作などです。
  • クラッシュが発生した場合は、スタックトレースを含むクラッシュログを提供します。
  • 予期しない動作が発生した場合は、予想される動作と実際の動作を説明します。
• 問題は回帰であり、「はい」の場合はいつから発生していますか？
• 問題の説明と再現手順の詳細： 問題は、サンプルアプリケーションのいずれかで再現可能ですか？または、問題を切り分けるコードを提供できますか？
• どのようなAPIが呼ばれていますか（該当する場合）。 すべてのパラメータとオプションをリストしてみてください。
• 再現率は？
• OS、IDE、デバイス/シミュレータ（OS、名前）などの環境に関する情報を提供します。
• マップデータバージョン/使用済みカタログ（該当する場合）。
• 使用されている他のフレームワークまたはプラグインを、バージョン情報を含めて列挙します（該当する場合）。
• スクリーンショットまたはビデオを追加します（該当する場合）。
• 検索またはルーティングの問題が発生した場合は、問題が発生した地理座標またはGPXトレースを提供します。

既知の問題が一覧表示されているリリース ノートを確認してください。 また、この 開発者ガイドの関連セクションに記載されている最新の手順およびコード例に従って 、実装の問題を回避してください。

わかりやすいログを生成します

多くの問題では、 IDE のコンソールに表示されるログには、すでに最も関連性の高い情報が含まれています。 クラッシュおよび ECR については、詳細を調べて、デバイスログを確認することができます。 を使用する場合 logcatは、タイムスタンプを使用して、最新のログのみを記録します。

例 :

adb logcat -t '06-30 16:30:00.820' > /Users/name/Desktop/log.txt

問題 adb logcat -c の再現を開始する前に、を使用してすべてのログを消去することをお勧めします。