飴屋

mixiアプリ/日記5

アプリがカテゴリ掲載されました

先日、自分の作ったmixiアプリが初めてカテゴリに登録されました。mixiアプリには、「開発中」と「公開中」というステータスがあるらしく、いきなりmixiユーザにアプリが公式に公開されるわけではないそうです。両者の大きな違いは「開発中」のアプリは制作者の承認なしにユーザがアプリ登録できない点と、「公開中」のアプリはmixiのアプリ一覧画面に掲載してもらえるという点でしょう。

たくさんの人に使ってもらうには、どうしてもステータスを「公開中」にする必要があります。アプリの公開はmixiの運営さんに申請を出し、それが受諾されて初めてお披露目となります。しかし、mixiユーザ10人がアプリを登録することが申請の必須条件となっているので、開発中にテストユーザ的な人を探す必要があります。私の場合、幸いなことにマイミクさんにお願いしてこちらの条件をクリアできました。アプリの登録が無料でよかったです。

10人のユーザを集めたら、アプリの掲載基準やmixi Platformの利用規約をよく読んで、カテゴリ掲載(公開)の申請を所定のフォームから行います。続いて、mixiアプリの標準機能である「掲載者へのお問い合わせ」機能を使って、mixiの運営さんが連絡をくれます。これはお問い合わせ機能のチェックの意味も含んでいるそうですので、自分のメールアドレスの登録情報に間違いがないか事前に自分で確認しておかないとメールがいつまでたっても届きません。私は念には念をいれて、自分から自分へお問い合わせしました。

mixiの運営さんからは、翌日にはお返事をいただきました。ここで「アプリの説明文」にアプリの動作推奨環境的なものを書いてくださいとご指摘を受けました。掲載基準などはちゃんと読んだつもりだったのですが、確認が不十分だったようです。反省。
確かに、他のアプリの説明文を眺めてみると、推奨動作環境に関する文章が書いてありました。私はとりあえず自分で確認できる範囲の動作環境と、システムに必要な環境要件をわかる範囲で書いておきました。
環境については、OSについても言及した方がよいそうです。OSに依存するような機能はあまりないんじゃないかと思うのですが、WindowsとMacのIEとかは挙動が全然違いそうですが、モダンなブラウザでもOSによる差って結構あったりするのでしょうか。

指摘された部分を修正後、mixiの運営さんにその旨返信をしたところ、その日のうちに無事にカテゴリに掲載してもらえました。申請したアプリはあんまり凝った機能を持っていなかったので、審査を通らないかもしれないと思っていましたが、これで一安心です。掲載後はなかなかのペースで登録者が増えていきました。でも、内容的にすぐに飽きられちゃいそうです。次のアプリは、もう少しコミュニケーションを考慮して設計してみたいです。

マイミクのプロフィールを表示させたい

var req = opensocial.newDataRequest();
var ip = {};
ip[opensocial.IdSpec.Field.USER_ID] = opensocial.IdSpec.PersonId.VIEWER;
ip[opensocial.IdSpec.Field.GROUP_ID] = "FRIENDS";
var idSpec = opensocial.newIdSpec(ip);
var dp = {};
dp[opensocial.DataRequest.PeopleRequestFields.PROFILE_DETAILS] = [
opensocial.Person.Field.PROFILE_URL
];
req.add(req.newFetchPeopleRequest(idSpec,dp),"friends");

req.send(function(data) {
if (data.hadError()) {
//読み込み不全エラー処理
} else {
var friends = data.get("friends").getData();
friends.each(function(friend) {
var id = friend.getId();
var nickname = friend.getDisplayName();
if (!nickname) return true;
var thumbnailUrl = friend.getField(opensocial.Person.Field.THUMBNAIL_URL);
//マイミク個別処理
});
}
});

前回は、VIEWER(アプリ閲覧者)の情報の扱い方について書いてみましたので、今回はVIEWERのマイミクさんの情報を取得してみたいと思います。基本はVIEWERのときと同じですが、VIEWERが単数なのに対して、マイミクさんは複数(もしくは0や1)である部分に少しだけ処理の違いが現れるようです。
以下に解説してみたいと思います。

newFetchPeopleRequestメソッド

前回、mixiサーバと情報の伝達を行ってくれるDataRequest君(伝達係)に持たせた荷物(要求)はnewFetchPersonRequestでしたが、今回はnewFetchPeopleRequestというものを持たせることになりました。Person(個人)がPeople(人々)になって複数人のデータを要求している感じが伝わってきます。
newFetchPeopleRequestの引数には第一引数に「誰の情報が欲しいのか」、第二引数に「どれくらい情報が欲しいのか」を指定することになります。

「誰の」を指定するためにオブジェクト(ip)を作成し、ip[opensocial.IdSpec.Field.USER_ID]にはVIEWERのID(opensocial.IdSpec.PersonId.VIEWER)を、ip[opensocial.IdSpec.Field.GROUP_ID]には「マイミク」という関係性(FRIENDS)を指定しています。これをopensocial.newIdSpecメソッドに渡してやると、「誰の情報が欲しいのか」を表すオブジェクトができます。(idSpec)「VIEWERのFRIENDS」がここでは対象になっています。

続いて、「どのくらい」を指定するためのオブジェクト(dp)を作成します。dp[opensocial.DataRequest.PeopleRequestFields.PROFILE_DETAILS]にマイミクのプロフィールのうち、必要な情報の配列を指定するとその情報が返ってきます。ここでは、プロフィール画像が欲しいのでopensocial.Person.Field.PROFILE_URLを指定しています。
一々、指定しなくても全部情報をくれればいいのにとも思いますが、必要なだけ要求するのがマナーなようです。mixiのサーバリソースを圧迫しないように個々人が気をつけましょう、ということですね。

eachメソッド

要求する情報がそろったら、前回と同様の作法でreqにaddしてsendします。すると伝達係がマイミクさんの情報を持って帰ってきます。サンプルでは「friends」という名前のついたデータをfriendsという変数に格納しています。このデータには「each」というメソッドがあり、複数人のマイミクさんのデータを一つずつ処理できるようになっています。サンプルではeachメソッドに対して無名の関数を渡しています。この関数の引数に前回のVIEWERのときと同じような個人のプロフィールデータ(friend)が渡されます。中身はIDとニックネームと上で指定したプロフィール画像が入っています。
nicknameが空のときにreturnで次の情報に移るように処理をしていますが、確かこれはマイミクさんにmixi公認アカウントがいたときのためにつけた処理だったと思います。私のマイミクに高橋名人を追加させてもらっているのですが、公認アカウントの方のデータは取得できないようなので、その人は飛ばすような処理になっています。

さて、これでマイミクさんのデータもがっつり活用できると思っていたところ、マイミク一覧を作成してもなぜか20人しか情報を取得できていないという現象が発生しました。この件については次回、また解説することにします。

日記一覧

Last-Modified