読者です 読者をやめる 読者になる 読者になる

続・TitaniumからACSを利用する【Statuses/Reviews編】

こんにちは、エンジニアのヨネモトです。

というタイトルで記事を書きましたが、今回もACSについて調べてみました。

少しおさらいすると、Appcelerator Cloud ServicesとはBaaS(Backend as a Service)の一つで、ユーザー管理やソーシャル連携機能、プッシュ通信機能など主にモバイル向けアプリケーションのバックエンドに必要な一般的な機能を備えたクラウドサービスです。

前回の記事では、Titanium.Cloud.UsersTitanium.Cloud.Postsを使いましたが、ドキュメントを読むとTwitter風のタイムラインにはTitanium.Cloud.Statusesを使う方が良さそうなので今回はこちらを使用します。

また、Titanium.Cloud.Reviewsを使うと投稿に対するコメントや評価(rating)を付ける事が出来ます。
評価は数値を入力出来ますが、「1」のように固定の値を登録するようにすれば「いいね!」や「お気に入り」も実現出来ます。

今回はこの機能を使って「お気に入り」つけられるようにしました。

ACS側にアクセスする部分のソースは以下のようにしています。
前回と同様にACSModel.jsというクラスにACS側にアクセスする処理を集約しました。

Statusesの投稿処理
self.post = function(data) {
    Cloud.Statuses.create(data, function(e) {
        if(e.success) {
            var status = e.statuses[0];

            Ti.API.info(status.content);
            
        } else {
            alert('Error:\\n' + ((e.error && e.message) || JSON.stringify(e)));
        }
    });
}

Statusesの取得処理

self.queryStatuses = function(user, reviews, callback) { Cloud.Statuses.query({ page : 1, per_page : 100, order: "-created_at", }, function(e) { if(e.success) { callback(user, reviews, e.statuses); } else { alert('Error:\\n' + ((e.error && e.message) || JSON.stringify(e))); } }); }
事前に取得したReviewのリスト(reviews)をcallback関数の中でStatusのリストとマージしています。

Reviewsの取得処理 
self.queryUserReviews = function(user, callback) {
    Cloud.Reviews.query({
        where: {
            user_id: user.id,
        }
    }, function (e) {
        if (e.success) {
            callback(user, e.reviews);
        }
        else {
            error(e);
        }
    });
}
このケースではuser_idを指定してログインした本人が投稿したReviewを取得していいます。

Reviewsの投稿処理
self.postReview = function(data, callback) {
    Cloud.Reviews.create({
        status_id: data.id,
        rating: 1,
        custom_fields:{
            status_id: data.id,
        }
    }, function (e) {
        if (e.success) {
            callback();
        }
    });
}
以下のドキュメントによると、Reviewを投稿する際は、Reviewの親となるオブジェクトのIDを指定する必要があります。

[object_type]_id
のところは今回はStatusなので"status_id"を指定しました。

また、今回は使用していませんが、同じユーザーで複数のReviewを投稿したい場合は"allow_duplicate : 1"を指定してやればいいようです。

ReviewがつけられたStatusのオブジェクトには
"reviews_count": 2,
"ratings_count": 2,
"ratings_average": 150.0,
"ratings_summary": {
  "100": 1,
  "200": 1
},
のようにレビュー数や評価の平均、評価のサマリーなどがつきますが、StatusオブジェクトからReviewオブジェクトの一覧への参照は持っていないため、Statusに紐づくReviewは自分でAPI経由で取得する必要があります。
(Userへの参照は持っています)
 
任意でJOIN出来るような機能があればいいのですが現在のAPIには見当たりませんでした。
ここは少し面倒なところかもしれません。

また、他の注意点として登録後にReviews.query()でReviewのリストを取得しても、その中に親のStatusのIDは含まれていません。

そのため今回は"custom_fields"に"status_id"を入れてデータの突合せに使用しました。

自分でサーバーサイドの処理を実装する場合は1回の通信で必要なデータをサーバー側で取得してクライアントへ返すように出来ますが、ACSを使う場合はクライアントから何度かクラウドへ問合せしないと必要なデータが揃わない場面がありそうです。

このあたりの仕様は事前にしっかり調査してアプリケーションをACSに合わせて設計する必要があると感じました。


以下は今回のサンプルの動作画面です。

ログイン
01_login



Status一覧
02_statuses



☆をクリックして「お気に入り(Review)」を登録
03_reviews_added


Statusの投稿
05_status_posted



タイムラインの更新

04_reloaded

ACSを使ってみた感想 
非常に手軽に使える反面、必要な機能が足りなかったり、APIの戻り値が予想と異なっていたりするケースが多かったので(当たり前なんですが)ACS側の仕様を理解したうえでアプリケーションを設計する必要があると感じました。

また、ACSの管理画面からデータの登録や編集が可能なのですが、現状は1レコードずつしか操作できないので、 作業効率 を考えると一括でデータの登録や削除を行える機能があった方がよいかと思います。

ただACS自体がまだ6月にリリースされたばかりなので、恐らく時間と共に解決されていくものも多いと思います。

新しいサービスの立ち上げにかかるコストを考えると、 自力でバックエンドの基盤を作る必要が無いというBaaSの思想は 非常に魅力的なので、今後も注目していきたいと思います!

おまけ
アドウェイズ開発部では一緒に頑張れる仲間を募集しています。
当ブログを読んで少しでも興味を持っていただけた方は、ぜひ応募してください!!

アドウェイズ中途エンジニア採用ページ