ほぼすべてのサービスを地球社会的サービスにすることができます。 つまり 通常のインターネットを超えてその機能を拡張し、サービスのユーザーに実生活での対話の機会を提供します。
発生する最初の質問は、ユーザーが必要かどうかです。 答えは、それがどのようなサービスであるかに大きく依存します。 たとえば、出会い系サービスは多くの問題を解決するため非常に人気があります。 彼らはお互いを知りたい人がパートナーを探す時間を節約できるようにします。 彼らは謙虚さを克服し、多くの紛争状況を回避するのに役立ちます。
さて、あなたが何か面白いことを考えたら、ハブラハブルの地社会サービスは提供できますか？
プライバシー設定オプション：
1）すべての人に見える-最大限のコミュニケーションが必要な人向け
2）私といくつかの共有ハブに加入しているhabrasocietyのメンバーにのみ表示-中程度のオプション
3）私が購読している人、同時に私をフォローしている人にのみ表示されます-相互利益が最大の最小限の連絡先。
このスキームでは、ほぼ全員が適切なオプションを見つけると思います。 ところで、私は、いくつかのサービスがそうであるように、地図上のユーザーの集まりに反対しています。 さらに興味深いのは、ユーザーにランダムな出会いが通知されるだけです。 そして、真の効果を達成するために、場所はオンデマンドではなく（チェキンの原則により）、オンラインで実行する必要があります。
技術的な実装
サービスを地理的ソーシャルにするには、モバイルデバイス用のクライアントアプリケーションを開発し、サーバー側でジオロケーションサービスを実装する必要があります。
位置情報サービスの機能：
1）デバイスからのデータの検証
2）会議の検索（デバイスの近接）
3）満たされたユーザーのプライバシー設定の分析
4）サービスおよび関心のあるユーザーに会議について通知する。
5）ユーザーインタラクションに必要な追加機能。たとえば、チャット用のモジュールなど。
モバイルクライアントアプリケーションの機能
1）ジオロケーション
2）現在の座標のサーバーへの転送
3）会議やその他のイベントに関するユーザーへの通知
4）チャットなど、ユーザーとの対話に必要な追加機能
ニュアンス
本格的なクライアントアプリケーションの実装はかなり時間がかかることを理解する必要があります。 また、異なるプラットフォーム向けのクライアントアプリケーションの実装について話すと、コストはさらに増加します。 たとえば、アプリケーションのユーザーインターフェイスのレイアウトにHTML 5を使用すると、タスクを簡素化できますが、ロケーションモジュールはネイティブにする必要があります。
場所はエネルギー効率が良いはずです。 この問題は、Androidで最も簡単に解決されます。 スマートロケーションアルゴリズムを記述することにより、消費電力を調整できます。 つまり 特定のケースでは、正確であるがエネルギーコストの観点からコストがかかるGPS座標を取得します。 可視性ゾーンにWiFiがある場合は、もちろん、位置情報に使用します（50〜100メートルの誤差、ほとんどエネルギー消費なし）。 セル座標を決定するために時々使用されます。 十分に大きな（ただし場合によっては許容できる）エラーが発生しますが、エネルギー消費はありません。
また、現在地を提供する電話がスリープしないことを考慮する必要があります。 また、プロセッサもエネルギーを消費します。 ロケーションを取得するために目覚めた場合、常に必要な速度で実行できるとは限りません。 衛星に関する情報を受信したGPSモジュールは非常に迅速に座標を提供しますが、初期化するには数分かかる場合があります。
別の問題は、デバイスのネイティブの位置情報サービスが時々大きなエラーを与える可能性があることです。 つまり 大きな誤差のある座標ではなく、単に間違った座標であり、実際の座標から1キロメートルになることが容易に判明します。 サーバー側では、このような「ブラックホール」の記録を保持して、トラックの信頼性を高めると便利です。
ケースのさまざまなロケーションモードを含む、大幅なエネルギー節約を実現できます。
-デバイスが静止している
-デバイスは低速で移動します
-デバイスは高速で移動します
この場合、2つの主なアイデアがあります。 デバイスが静止している場合、イベントは生成されません。 デバイスが高速で移動する場合（車内の人）、多くのイベントがありますが、ユーザーはとにかくそれらに応答できません。
それでも、デバイスによる座標の送信を同期するとよいでしょう。 つまり クライアントの時刻とサーバーの時刻を同期する必要があります。 これは、オブジェクトを移動するために重要です。 例-2人が隣接する座席で路面電車に乗りますが、デバイスによる座標の送信が同期していません。 その後、サーバーはいずれかのデバイスの痙攣性のオフセットを受信し、会議を記録しません...
すべてのデバイスの一括送信も間違っています。 したがって、サーバーのピーク負荷を作成します。 つまり 座標を送信する時間を現在の座標に結び付けるアルゴリズムを検討する必要があります。
それでも、GPSだけでなく座標を取得して、トラックデバイスを見ると、不満を感じるでしょう。 動きは、いくつかの前方への跳躍のように見えます。 エラーが絶えず変化している場合、デバイスからの座標をどのように処理するかを考えるのは良いことです。 興味がある人は、次の記事のいずれかでアルゴリズムを説明できます。
iOSでの位置情報はさらに悪いです。 一定の精度で座標を要求する機会があるだけで、どのような意味（どのくらいの時間、どのエネルギー消費）を受け取るかを管理する方法はありません。 さらに、電話機をスリープモードから復帰させる簡単な方法はありません。 そして、このモードに入らない場合、プロセッサーは多くのエネルギーを消費します（最新のAndroidよりもはるかに多く）。 エネルギー効率の高いロケーションタスクを解決するための特定の機会がありますが、実装は非常に複雑です。 多くの場合十分である唯一の簡単なオプションは、ジオフェンスを使用することです。
Symbian 完全な場所は、少なくともS60のオペレーティングシステムを搭載したデバイスでのみ可能です。 さらに、デバイスにはWiFiとGPSが必要です（そのようなモデルはほとんどありません）。そうしないと、場所のエラーが非常に大きくなります。 自動起動アプリケーションに問題が発生します。 Symbian用のアプリケーションを開発する労力は、たとえばiOSの何倍にもなります。
Windows Phone このシステムの第7バージョンは、明らかにモバイルデバイスにとって非常に重いことが判明し、本格的なバックグラウンドロケーションの可能性はそこで実現しませんでした。 8番目のバージョンは大きく前進しました。 広範なジオロケーションAPIが登場しました。これは、AndroidとiOSのクロスです。 ただし、次の式を忘れないでください。
「新しいオペレーティングシステム」+「異なるメーカーのデバイス」=「避けられないバグ」。
そして、これは開発の複雑さに最良の効果をもたらさないかもしれません。
もちろん、Google Glassのクライアントを開発する
通知
場合によっては、会議やその他のイベントをユーザーに通知する必要があります。 プラットフォームごとに、個別のネイティブ実装を行う必要があります。 ただし、この場合、ベンダーのサービスではなく、独自のフィードバックを通じて通知を整理するユニークな機会があります。
デバイスがTCPを介してサーバーに接続する場合、セッション中いつでも彼に連絡できます。 デバイスがUDPパケットを送信したとしても（負荷について考えると合理的です）、応答パケットを送信する時間があります。 この時間はインターネットプロバイダーによって異なりますが、いずれにしても少なくとも10秒です。
アグリゲーター
労力とお金を節約し、アグリゲーターのサービスを使用できます。アグリゲーターは、サードパーティのサービスを統合し、モバイルデバイスの場所に関する問題を個別に解決するためのAPIを提供します。 ユーザーが通信するための機能が既に実装されているさまざまなプラットフォーム用の既製のテンプレートネイティブアプリケーションを提供し、マップ（必要に応じて）などに表示し、Webビューを介して各サービスに固有の機能を埋め込む機能も提供します。
PSこの記事では、地球社会サービスの技術的な実装に関する一般的なアイデアと原則のみを説明します。 もちろん、Habrahabrに関しては、さらに多くの興味深い便利な機能を思い付くことができます。 親愛なるハブラビテス、あなたの意見を知りたい。