VK APIを介して場所を共有する方法

最近、私はVK APIを介して友人とほぼリアルタイムモードで場所を共有する方法のアイデアを実装しようとすることにしました。 出力は、iOS / Android向けのクロスプラットフォームQtアプリケーション、VKontakte向けのWebアプリケーション、VK API向けのプルリクエストでした。 この記事では、誰かに興味があるかもしれないいくつかの非自明な実装ポイントを共有したいと思います。 だから、猫を求めて興味を持ってください。

なぜそれが必要なのか

遅かれ早かれ、子供たちは成長します。 卑劣な真実。 それで私の10歳の娘は、「お父さん、もう車で連れて行ってはいけない。自分で学校に行きたい！」と言いました。 それで、私はクレームフェアを見つけ、2週間の遅延を要求し、準備を始めました。



私はアプリケーションを書いた経験があり、娘は常にiPhone SEのポケットに入れて持ち歩いているので、準備として、娘がこの特定の瞬間にどこにいるかを示すアプリケーションをすぐに書くことにしました。 はい、今ではそのようなアプリケーションが非常にたくさんあることを知っています（同様の機能が最近Googleマップに登場しました）、既製のソリューションを使用することは可能でしたが、私は自分のものを書くことに興味がありました。

なぜVKontakteなのか？

これから生じるすべての「魅力」と、他の人（可能性のある見込み）の機器上の個人データの処理と保存に関連付けたくないので、自分のサーバーパーツなしで行う方法を考えました。 そして、それは私に夜明けを告げました-結局のところ、VKontakteのようなモンスターがあります！ ファッショナブルでパワフルで、独自に開発されたAPIを備えており、最も重要なことは、すべての子供たちが長い間座っていてタイトだったことです（好きだったとは言えませんが、現実です） しかし、地獄、ホームズ、位置データをそこに詰め込んで、まず、それが必要でない場所に表示されないように、そして次に、あなたがこのデータへのアクセスを制御して、彼らへの悪いpedobirsそこに着かなかった？



メモが助けになりました。 はい、同じウィキペディアは、かつて（噂によると）人気があり、現在はペンになっていると述べています。ほとんどの部分で、彼らはテープのハイライトを停止し、サイトの別のセクションに移動しました。 任意のテキストデータを配置できますが、主なことは、このメモを表示およびコメントできるユーザーとグループをリストするアクセスリストを割り当てることができることです。



私の目には、アプリケーションの一般的なスキームは次のようになり始めました。

• 位置データを共有したい友人のリストを作成します（「信頼できる友人」と呼びます）。
• 特定の名前でメモを作成し、上記のリストに表示する権限を付与し、そこに位置データを書き留め、定期的に更新します。
• 信頼できる友人のリストを定期的に調べ、この特定の名前のメモがあるかどうかを確認します。メモがある場合は、コンテンツから友人の位置に関するデータを抽出し、成功した場合は地図に表示します。
• ???
• 利益！

だから、アイデアがあります、それは小さな問題です-それを実現するために。

iOS

彼女の娘はiPhoneを使用しているため、iOSバージョンで実装を開始することは論理的でした。 クロスプラットフォームの観点から、Qtはフレームワークとして選択されました。私は長い間これに精通しており、古き良きOpen Street Mapがマップエンジンとして選択されました。QtLocationにはプラグインがあります。 このアプリケーションは元々オープンソースとして作成されたため、Qtのライセンス制限は私を怖がらせませんでした。



GUIはVMLで動作するようにQMLで記述され、通常のVK iOS SDKを接続して使用しました。Objective-Cで記述されているため、統合しても問題は発生しませんでした。 iOSのバックグラウンドでの作業は、Significant Change Location Serviceを通じて実装されます。 エネルギー消費を削減するために、アプリケーションは動きのアクティビティを監視し、人がほぼ1か所に長時間座っていること（たとえば、彼が学校やオフィスに来た）を理解した場合、ジオロケーションを決定するために必要な精度を下げ、OSがそれを決定するエネルギー集約度の低い方法（方法原則として、セルタワーで）。 人が積極的に動き始めたことをアプリケーションが理解すると、精度が再び上がります。



iOSバージョンの完全なソースコードはGitHubで入手できます 。 実装プロセスで出会ったいくつかの非自明なポイントを次に示します。



QtアプリケーションでNSApplicationDelegateメソッドをオーバーライドする



VKontakteのiOS SDKでは、アプリケーションの関数の一部にdidFinishLaunchingWithOptions：およびapplication：openURL：options：メソッドの呼び出しを追加する必要があります。 Qtのいくつかのバージョン（私の意見では、5.11以前）では、QIOSApplicationDelegateのカテゴリを次のように作成するだけで十分でした。

@interface QIOSApplicationDelegate : UIResponder <UIApplicationDelegate> @end @interface QIOSApplicationDelegate (QIOSApplicationDelegateVKGeoCategory) @end @implementation QIOSApplicationDelegate (QIOSApplicationDelegateVKGeoCategory) - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { [...] } - (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options { [...] } @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、Qtの最近のバージョンでは、QIOSApplicationDelegateには既にapplication：openURL：options：の実装があります。そのため、カテゴリのオプションはロールバックしません。 QIOSApplicationDelegateから相続人を作成し、setDelegateを介してデリゲートを割り当てる必要がありました。

 @interface VKGeoApplicationDelegate : QIOSApplicationDelegate @end @implementation VKGeoApplicationDelegate - (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options { [...] } @end void InitializeVKGeoApplicationDelegate() { [[UIApplication sharedApplication] setDelegate:[[VKGeoApplicationDelegate alloc] init]]; } int main(int argc, char *argv[]) { [...] InitializeVKGeoApplicationDelegate(); [...] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

VKRequestからのエラー処理



エラー時にVKRequestが空の（空の）NSErrorを返すことに直面しました。 誰かの以前のパッチとこのパッチのプルリクエストにパッチを当てるパッチを作成しましたが、まだレビューされていないパッチではハングします。

Android

以下はAndroid用のバージョンです。 GUIコードはiOSからほぼ完全に再利用され、VKとやり取りし、通常のVK Android SDKが再び使用されました。JNIを介して行われるやり取りは、バックグラウンドでの作業は、そのようなアプリケーションに対するGoogleの規約に従って、つまりフォアグラウンドサービスを通じて実装されます。 もちろん、iOSで使用されているのと同様に、電力消費を削減するロジックも実装されています。



Androidバージョンのソースコードの完全なセットはGitHubで再度入手できます。このバージョンを実装する過程で出会ったいくつかの非自明なポイントを以下に示します。



QtでAndroidサービスを作成する方法



Qt 5.10でサービスを作成するために、QGuiApplicationの代わりに使用する必要があるQAndroidServiceクラスが表示されました。 アクティビティとサービス用に別々の.soをコンパイルするか、すべてに1つの.soを使用し、コードが動作するモードを理解するために、コマンドラインスイッチでこのモードを指定できます。

 <service android:name=".VKGeoService"> <meta-data android:name="android.app.arguments" android:value="-service"/> </service>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 int main(int argc, char *argv[]) { if (argc == 1) { QGuiApplication app(argc, argv); [...] } else if (argc == 2 && QString(argv[1]) == "-service") { QAndroidService app(argc, argv); [...] } else { return 0; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

onDestroyの奇妙な「ハング」アクティビティ（）



サービスを実装する過程で、おもしろい問題が明らかになりました。QtActivityは、onDestroy（）の腸のどこかに「ハング」しました。 どうやら、Qtは、アクティビティが完了した後、アプリケーションから何か他のものが残ることを期待していません。 この問題は、マニフェストのandroid：プロセスを使用して、さまざまなプロセスにアクティビティとサービスを配置することで解決しました。

 <service android:name=".VKGeoService" android:process=":VKGeoService"> [...] </service>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オーバーライドされたonDestroy（）で、アクティビティが実行されているプロセスを釘付けします。

 @Override public void onDestroy() { [...] /* * This call hangs when foreground service is running, * so we just kill activity process instead (service * is running in a different process). * * super.onDestroy(); */ Process.killProcess(Process.myPid()); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はい、糸くずは常にこれを誓いますが、どう対処するかは私にはまだ明らかではありませんが、このトピックについてはPoCでQTBUGにまだ触れていません。



更新 ：Qt 5.12.3（少し前かもしれません-私はチェックしませんでした）ハングしたQtActivity.onDestroy（）のバグはサービスの開始時に修復されたため、この回避策は必要ありません。



VKBatchRequestをキャンセルするときにerrorBlock呼び出しがありません



VKontakteサーバーの負荷を軽減するためにバッチリクエストを広く使用していますが、VKBatchRequest errorBlocksをキャンセルした場合やリクエストをキャンセルした場合に問題が発生したのはAndroid（すべてiOSで正常に動作します）です。 ライブラリのローカルバージョンでこの問題を修正し、このパッチに対応するパッチとプルリクエストを作成しましたが、未確認のものでもハングします。

おわりに

AppleのiOSバージョンはApp Storeに簡単に配置でき、引き続き利用できます。Androidバージョンは、Google Playポリシーが厳格化されるまでしばらくの間Google Playに存在していました（ジオロケーションを追跡するアプリケーションは明示的に家族または企業での使用を目的としています）、その後、アプリケーションはそこで安全にブロックされました。 私の訴えに、責任あるGoogleの従業員（またはボットだったかもしれませんが、誰があなたの質問に正確に答えているかは今では明らかではありません）が断固として「このアプリケーションは家族や企業の追跡にのみ使用できます」 、私は議論するものを見つけることができませんでした-実際、ハンマーで釘を打つだけでなく、あなたの頭を打つこともできます... AndroidバージョンをYandex.StoreとAmazon Appstoreに、APKとしてプロジェクトのウェブサイトに配置しました。



このアプリケーションが、iOS / Android用のQtアプリケーションを書く際のいくつかの明白でない瞬間、特にQtでのAndroidサービスの実装に関連する瞬間を明らかにする視覚的な助けとして誰かに役立つなら嬉しいです（この機能は比較的新しく、実装例、どれくらいあまり知らない）。 また、もしあれば、コメント欄で質問にお答えします。