たまたまnifty cloud mobile backend というサービスがあることを知ったので、Parseとかとくらべてどのくらいイケてるのかなぁと、お試しで触ってみました。

アプリを登録する

APIキー・クライアントキーをApplicationクラスに入れる

HogeHogeApplication

public class HogeHogeApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();

        NCMB.initialize(this,
                "90bdda4..............59bbf", //APP KEY
                "cf0276...............0143"); //CLIENT KEY
    }
}

AndroidManifest.xml

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="jp.co.crowdworks.hogehogeworks">

    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

    <application
        android:name=".HogeHogeApplication"
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"

ビューを作る

すごい適当に、以下の様な感じでつくります。

とりあえずXMLでレイアウトファイルを追加。

Activityの細々とした動きは後ほど。

会員登録・ログイン・ログアウトなど

ようやくmobile backendの恩恵を少しだけ受けられます。

こんなかんじの画面遷移をつくります。
とりあえず結果だけ。

データストアのIOを実装

クラスを作成して、「message」というクラスを作っておきます。
（リファレンスを読む限りだと、これはやらなくてもOKかも）

で、

ログインができたら、messageをロード
Sendボタンをおしたらmessageオブジェクトを作成

という至極シンプルなロジックを追加します。

とりあえずこんな感じになりました。

Going Reactive

これが、mobile backendでなんでやってくれないの？！と非常に不満な点。
（Meteorみたいにデータをリアルタイムで反映してくれたら素敵なのに… と）

「サーバ側でmessageが追加されたらクライアントにPUSH通知」みたいなことができません。
よって、現状だと、定期的にfetchするしかなさそう。

と、ここで、心が折れて、続きをやるのをやめました・・・ｗ
＃AlarmManagerで定期的にloadMessage() 呼ぶだけなんですけどね...。

まとめ

現状の nifty cloud mobile backendだと、

良かった点

ログイン周りが超かんたんに実装できる
データストアがSharedPreferenceに毛が生えた程度のコードで実装できる

イケてない点

データストアの変化通知をPUSH受信できないので、定期的にデータストアを監視しないといけない
PUSH通知にはGCMのIDが必須（Parseだと、GCMなしでもある程度のPushはできる）
- プロトタイプでとりあえず〜　にはGCM登録は面倒
- そもそもGoogle開発者サービスが入ってないスマホには、PUSHを届けられない

というかんじですね。

ログインまわりはかなり省力化できるけど、ログイン周り以外はほとんど省力化できた気はしませんでした。
とはいえ、わりとAPI設計のセンスがいい（けっこう直感的）ので、今後に期待できそう。