モバイルアプリケーションのディープリンク

WWDC 2015で、Appleのエンジニアはディープリンクへのアプローチを修正したと発表しました。昨年GoogleはApp Indexを発表しました。 これはどのようなツールであり、iOSとの関連でどのように作業するか-この記事で説明します。

これは何ですか

IT製品を宣伝しながらコンバージョンを増やす方法の1つは、ユーザーが目的の目標を達成するための障壁を減らすことです。 モバイル開発では、この問題はさらに重要です。 プロモーションに関する情報を含む電子メール、プッシュ、またはSMSメールを使用する場合、アプリケーション機能へのアクセスの簡素化が必要です。 そのような状況では、プロモーションは特定のセクションの特定の特別オファーであるため、外部ソースからアプリケーションを起動するだけでは解決策にはなりません。 アプリケーションを起動した後、ユーザーが歩き回ったり、検索したり、いらいらしたりする必要がないように、ナビゲーションを事前に決定する追加のツールが必要です。 そして、そのようなツールがあります。

ディープリンクは、ユーザーがアプリケーション間を事前定義されたセクションに移動できるようにする技術です。

どのように機能しますか？

ピッツェリアが広告キャンペーンを実施することを決めたと想像してください。このキャンペーンの枠内で、50％の割引でマルガリータピザを購入できます。 ピッツェリアにはWebサイトとモバイルアプリケーションがあります（もちろん、マーケティング上の理由からクライアントとの作業には後者が適しています。アプリケーションでの銀行カードの操作は、ブラウザーよりもはるかに便利です）。 同社は、顧客ベースで特別オファーに関する情報をSMSメールで送信し、サイトの目的のセクションへのリンクを提供します。 ピッツェリアアプリケーションがクライアントのスマートフォンにインストールされている場合、リンクをクリックすると、サイトサーバーはすぐにクライアントを注文するための適切なアプリセクションに送信します（これはディープリンクメカニズムです）。 SMSのリンク経由（またはWebバージョンの使用を継続）。



World Wide Webの概念では、ルートページだけでなくネットワーク上のドキュメント間を移動する機能として、ディープリンクメカニズムがHTTPおよびURLに組み込まれました。 モバイルオペレーティングシステムでは、このメカニズムはさまざまな方法で実装されます。

iOSで行う方法

ディープリンクの動作原理は次のとおりです。ユーザーがURLへの移行を開始し、このURLにあるリソースがオペレーティングシステムを決定し、それに応じて所定のセクションでアプリケーションに切り替えます。



URL-リソースの場所を示すリンク。 主にネットワークのアドレス指定に使用されますが、ファイルシステム内の場所を示すために使用できます。



このテクノロジーには、いくつかの実装方法があります。

• 古典的なアプローチ
• サードパーティのソリューション
• IT分野の新しいトレンド

iOSでの従来の実装

一般的に受け入れられている実装は、次の手順で構成されています。



1.要求のURLスキームへの変換、スキームの不在を処理する可能性を伴うその実行。

2.アプリケーション内のスキームおよびナビゲーションを処理して、特定のセクション/画面に移動します。



URLスキームは、次のURLまでの一部です。//これは、リンク自体が導くリソースとの相互作用のスキームを担当します。ほとんどの場合、プロトコルが意図されています。



http, ftp, tel, mailto



など、多くの登録されたスキームがあります。

URLスキームの実行結果の作成、実行、および処理

HTTP要求をURLスキームに正しく変換するには、サーバーに通信テーブルおよび/または指定された変換ルールを保存する必要があります。



URLスキームを正しく実行して結果を処理するには、いくつかの方法があります。 URLスキームが実行されている環境によって異なります。 これがiOSアプリケーションで発生した場合、URLスキームがシステムに登録されているかどうかを確認する標準的な方法があります。

 [[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@”myapp://”]];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スキームがWeb環境から実行される場合、アプリケーションを起動するか、目的のリソースに送信するJSスクリプトを使用することが最適です。



例：

 $(function(){ window.location = 'myapp://'; setTimeout(function(){ window.location = 'fallback.html'; }, 500); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

500ミリ秒後に「myapp：//」スキーム（以前に生成されたスキーム）による移行が失敗した場合、「fallback.html」への移行が実行されます。



このスクリプトは、移行を担当するリソースに埋め込む必要があります。

GitHubには、こうしたソリューションの実装が多少成功しています。

結果のURLスキームとアプリケーション内のナビゲーションの処理

ディープリンクメカニズムの実装のこの部分は、ユーザーの要求を処理し、それを目的のセクションに転送するアプリケーションのみに関連しています。



これを行うには、まず、アプリケーションに関連付けられる独自のURLスキームを登録する必要があります。

[情報]セクションのプロジェクトのメインターゲットの設定で、URLタイプ-URLアイテムにスキームのタイプを追加する必要があります（図2）。







「識別子」フィールドでは、アプリケーションのbundleIDを指定する必要があり、「URLスキーム」フィールドでは、アプリケーションが関連付けられるスキームを指定する必要があります。 次に、アプリケーションにナビゲーションメカニズムを実装する必要があります。 これを行うには、アプリケーションへのURLの可能な転送を処理する必要があります。 あなたは多くの方法でそれを転送することができます、私たちはシステムの回路の直接実行を考慮します。



URLを介してアプリケーションの起動を処理するには、メソッド内のアプリケーションのAppDelegateで次が必要です。

 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

lauchOptions



ディクショナリから、キーUIApplicationLaunchOptionsURLKey



を使用してオブジェクトを取得します。 オブジェクトが存在する場合、これはアプリケーションがURLスキームを介して起動され、このスキームを処理できることを意味します。 スキームの実行時にアプリケーションが起動される場合、URLはメソッド内の同じAppDelegateで取得する必要があります。

 - (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、さらにナビゲートするにはurlパラメーターを使用する必要があります。 アプリケーション内のナビゲーションは完全に個人的な選択ですが、ルーターテンプレートを使用することをお勧めします。 第一に、これは単一責任の原則に違反しません。第二に、将来の任意の場所からこのナビゲーションをカプセル化して使用できるようになります。 ルーターはURLを（キーとして）取得し、ViewControllerを発行するか、このナビゲーションを実装する必要があります。

サードパーティのソリューション

サードパーティのソリューションのうち、 モバイルディープリンク（AppURL、AppLinks、UrbanAirShipなど）を検討できます。これらのフレームワークは、ディープリンクテクノロジーのすべてのコンポーネントを実装するための完全なソリューションです。 これらには、独自の外部URLハンドラーとアプリケーションのナビゲーションメカニズムを備えた個別のライブラリが含まれています。 したがって、このようなソリューションでは、プロジェクトにSDKを統合する必要があります。



個別に、統合を必要としないソリューションを検討する価値があります。特定のリンクでアプリケーションを実行し、アプリケーションがインストールされていない場合はストアにリダイレクトする機能を提供するDeep Link Meサービス。 すべての設定は、可能なオプションからサイトで直接行われます。

• 「HTTPリクエスト-URLスキーマ」コンプライアンスルールの追加。
• アプリケーションストアを含む代替リソースへの切り替え。
• iOS / Androidをサポートします。

このソリューションの唯一の不便は、すべての転送がdeeplink.meを介して行われることであり、ユーザーには間違いなく表示されます。 このツールを使用するには、アプリケーションでURLスキームとナビゲーションのサポートを自分で実装する必要があります。

ディープリンクの新しい外観

Googleが提供するディープバインディングテクノロジー。



最近、GoogleはApp Indexingの新しい方向性を開始しました。 もちろん、大部分はAndroid開発を目的としており、可能な限り便利に実装されていますが、限定ベータ版ではありますが、iOSは忘れられていません。



だから：

実行可能なディープリンクに加えて、Google検索エンジンのアプリケーションのインデックスもあります。 世界中で検索した結果、アプリケーションのセクションへのリンクが表示されます。



実装には以下が必要です。



1.別のURLスキームをプロジェクトに次の形式で登録します。

gsd-{scheme}







ここで、「スキーム」は上記で登録した回線です。

2. GoogleAppIndexingフレームワークを接続します（CocoaPods経由）

3.アプリケーションの上記のメソッドで、次のように移行を処理します。

  NSURL *sanitizedURL = [GSDDeepLink handleDeepLink:url];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、アプリケーションをGoogle App Indexingとリンクし、検索に戻るためのパネルを作成するのに役立ちます。

4.移行先のサイトをセットアップする必要があります。 これを行うには、サイトのヘッダーに追加します。

 <html> <head> ... <link rel="alternate" href="ios-app://{itunes_id}/{scheme}/{host_path}" /> ... </head> <body> … </body>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GoogleBotにサイトへのアクセスを許可して、完全なインデックス作成を行うこともできます。



これらの方法はすべて、URLスキームの操作に基づいています。 彼女は長い間知られ、実践されてきました。 それらで発生する可能性のある問題も知られています。 たとえば、2つの異なるアプリケーションが同じスキームを登録した場合の動作は完全に未定義です。 アプリケーションがインストールされていない場合は、代替動作も処理する必要があります。 このような状況では、すべての責任は開発者にあり、残念ながら実装エラーが一般的な慣行になります。



そのような状況を避ける方法は？



繰り返しになりますが、Appleは私たちを失望させません。iOS9から、アプリケーションへの直接的な移行を伴うHTTPおよびHTTPSサポートが追加されました。

2015年6月、WWDCで、「クペルティーノの男たち」は、モバイルアプリケーションを促進するためのこのような便利なメカニズムを実装するための新しいアプローチについて語りました。



彼らはそれをシームレスリンクと呼び、「シームレスリンク」として翻訳することができます。 このメカニズムにより、サイトのセクションをナビゲートするときと同じWeb URLを使用できます。さらに、アプリケーションとWebリソース間の接続は、アプリケーションのバンドルIDを介して行われ、この接続を一意にします。また、表示されるサイトのセクションを指定することもできますあなたのモバイルアプリケーションで、そしてディープリンクは彼らのためにのみ動作します。 まあ、クール!!!

どのように機能しますか？

リンクはシステムで処理され、ドメイン（またはホスト）がそこから抽出され、アプリケーションのナビゲーションを制御できるパスが直接抽出されます。



https://n-pizza.com/margarita_new







この場合、n-pizzaがドメインです。 ドメインは、サイトサーバーに格納されているSSL証明書で保護された特別なファイルを介してアプリケーションに関連付けられている必要があります。 apple-app-site-association



と呼ばれ、特別なJSON構造を含む必要があります。

 { "applinks": { "apps" :[], "details":{ “123456.npizza.com” :{ "paths": ["*"] } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どこ123456.npizza.com - app_bundle_id





“path” : [“*”]



-アプリケーションがWebリソースのすべてのセクションをサポートすることを示します。それ以外の場合は、特定のパスを指定できます。

 { "applinks": { "apps" :[], "details":{ “123456.npizza.com" :{ "paths": ["/margarita_new", "/old/greate_pizza/*"] } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、作成したJSONをWebリソースで使用される証明書で署名するか、新しい証明書を生成し（WildCard証明書を使用することは許可されます）、JSONで署名してサーバーに追加する必要があります。 この場合、アプリケーションの署名に使用される証明書は使用されません。



ドメインごとに一意のapple-app-site-association



ファイルが必要であることを理解することが重要です



n-pizza.com/apple-app-site-association



アプリケーションでは、プロジェクト設定の「関連付けられたドメイン」項目でサポートするドメインとの関連付けを確立する必要があります。 また、ユニバーサルリンクはAppDelegateメソッドで処理する必要があります。

 - (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray *))restorationHandler
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、ユニバーサルリンクのアクティビティのタイプは次のとおりです。

 NSUserActivityTypeBrowsingWeb
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のようなネイティブツールを使用してURLを分解できます。

 NSURLComponents
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

またはFacebook Boltsのようなサードパーティのフレームワーク。 上記の既知のスキームに従って、さらにナビゲーションを行う必要があります。



その結果、リンクをたどるユーザーは、このリンクがつながったリソース上またはアプリケーション内で自分自身を見つけます。 このソリューションの大きな利点は、URLスキームが使用されないことです。 しかし、このソリューションはiOS専用であり、バージョン9のみであるというマイナスもありません。

コンテキストディープリンク

上記のすべてが正常に機能し、アプリケーションが既にインストールされている場合にのみ、アプリケーションに侵入する必要な効果が得られます。 考えてみると、本当のメリットは、ほとんどのスマートフォンユーザーにアプリケーションがインストールされている大企業であり、そのうちの40〜50しかありません。



アプリケーションがインストールされておらず、それらのほとんどがAppStoreまたはGoogle Playにある場合、ユーザーはサイトのページまたはアプリケーションストアにいることになります。 アプリケーションをインストールして起動すると、メイン画面が表示されます。 いずれのシナリオも、破損したディープリンクに相当します。



ディープリンクの完全な効果を達成するために、コンテキストディープリンクがあります。 彼らの仕事の本質は、アプリケーションへの切り替えの条件（URLスキームのパラメーター）に応じて、さらにナビゲーションが構築され、デバイス識別子がサーバー側に保存されることです。 アプリケーションをインストールして起動した後、この条件が要求され、ナビゲーションが構築されます。 ユーザーにとっては、すべてがきちんとシームレスに見えます。



上記の方法のいずれかと組み合わせて、このアプローチを実装できます。 または、SDKを組み込んで既製のソリューションを使用します。