foursquareは、正直なところ割と早い段階で飽きてて、つい最近まで放置しておりました。まあロケタッチはブログとの兼ね合いでかろうじて惰性で続いている私なのですが、なんかよくわからない事にここしばらくfoursquareのその休眠アカウントにフレンド申請が来るようになったので、再び使い始めています。
ただ、二つの併用となると、GPSの測位がうまくいかない所だと「イライラも二倍」な訳でして。どうせなら、一括してタッチなりチェックインしたいなという欲望が出てくる訳で。
どちらも開発者向けのAPIが公開されているし、できない訳では無いとは思うのですが、ロケタッチは基本的に、日本ローカルなサービスな訳だから、そんな特殊仕様は自分で作らなきゃ誰もつくんないだろうなぁ…と、思って腰が上がらないというか、気づかなかった事にしようかと思う今日この頃。
ひとまず、いつものように仕様だけ考えて忘れようかな…と。
一緒にって言っても、方法は一つじゃない訳で、思いつくところでこのへん。
・専用クライアントで、ロケタッチとfoursquareの両方のAPIを同時に叩く。
・twitterタイムラインからどちらかのタッチまたはチェックイン情報を拾ってもう一方に反映させる。
・定期的にどちらかのフィードを覗き、更新されていたら場合に、もう一方の方に反映させる。
この中で、時間差をできるだけ少なくしようと思えば、一番最初のAPIを同時に叩くのとtwitterタイムラインから拾ってくる方法。最後のフィードを覗くパターンもチェック頻度を上げればそんな変に遅くはならないのだろうけども、あまり頻繁にチェックしてると運営からブロックされそうなので却下。となると、可能性があるのは上の二つ。
どちらにしても、二つ以上のサービスのAPIを叩かなきゃいけない訳で、どの組み合わせが楽なのかなというところ。実際につくるとすれば、そこをよく考えなきゃいけない。
で、実際に作るとなると問題になるのがスポット情報が別々に作られているところ。解決策としては次の方法かな…。
・タッチまたはチェックインする時に片方から拾った位置情報と同時にスポット名を渡して検索する。
・検索結果が１つであればそこでチェックイン（タッチ）、無ければ位置情報だけで再検索。複数であればユーザーに選択してもらう。（「１つであればチェックイン」が必ずしも正しいスポットを拾うかどうかは…）
・このときに取得したスポットIDは関連づけして保存しておく。
また同じ場所をチェックイン（タッチ）する時は、その保存したスポットIDを使ってする訳だけど、スポットが統合されていたりする場合があるから、その前にそのスポットが実在しているか実際に叩いて確認してみないといけません。もちろん、無ければその情報を破棄してもう一度最初っからです。
開き直って、「最初から保存しない」という選択肢もあるかもしれないなぁと思ったけども、使い勝手としては最悪かと思います。
まー、以前このブログに書いた、ねとらじ関係の記事の件もなんにも手をつけていない訳で、たぶん作らないと思いますけどね…。
コメント