たまたま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設計のセンスがいい（けっこう直感的）ので、今後に期待できそう。