目次
はじめに
本記事はクラウド構築編の続きになります。
本記事はモバイル開発初心者がSQLiteで管理しているデータをクラウド化MBaaSを導入してバックエンド周りをクラウド化するまでの記録になります。
ベストプラクティスを指南する記事ではない旨ご承知の上読んで頂けると幸いです。
前回はMobile BackendというMBaasを利用してサーバーを構築しました。
今回はアプリケーションでクラウド構築を実践する回になります。
チャプター
1.チュートリアル実践_ログイン機能実装
2.データストアとアクセス制限の設定
3.オブジェクト操作
チュートリアル実践_ログイン機能実装
実践用のサンプルアプリケーションから作成しようと思いましたが、mobile backendの公式ドキュメントに
ちょうど良さそうなチュートリアルがあったので、そちらを実践してみることにします。
開発環境
- OS : Windows10 64bit
- IDE : Android Studio
- 言語 : Kotlin
- デバック仮想端末 : Pixel 5 API 30 (Android 11.0)
SDKのインストール
Mobile Backendから提供されているNCMBをインストールします。
リンクから最新版をダウンロードしライブラリにインポート。
Android studioのデフォルトのディレクトリ構成の場合、appのディレクトリ下のlibsに格納します。
SDK適用に必要な設定を記述
app/build.gradleにライブラリの依存関係を追記します。
dependencies {
implementation 'com.squareup.okhttp3:okhttp:4.8.1'
implementation 'com.google.code.gson:gson:2.3.1'
api files('libs/NCMB.jar')
implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.9'
}
androidManifestに以下の項目を追加します。
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
これでSDKのセットアップは完了です。
APIキーの設定
Main ActivateにOncliateメソッドにAPI情報を記載します。
API情報はコンソール右上の[アプリ設定]から確認できます。
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
NCMB.initialize(this, "APIキー", "クライアントキー");
}
onCreateはアクティビティの開始時に呼び出され、初期化処理を行います。
ログイン・登録処理の作成
ユーザー名とパスワードによるログイン処理を作成します。
アカウントがない場合はサインアップの画面に遷移し、ユーザー登録を行います。
登録処理
import com.nifcloud.mbaas.core.NCMBException
import com.nifcloud.mbaas.core.NCMBUser
fun signup() {
// Userインスタンスの生成
var user = NCMBUser()
// ユーザー名・パスワードを設定
user.userName = "takanokun"
user.password = "openGoma"
//新規会員登録
user.signUpInBackground(NCMBCallback { e, signUpUser ->
if (e != null) {
//エラー時の処理
println("新規登録に失敗しました。エラー : " + e.message)
} else {
//成功時の処理
println("ユーザー情報登録に成功しました場合 : " + (signUpUser as NCMBUser).getObjectId())
}
})
}
ログイン
画面遷移等の処理は省略させて頂きます。
import com.nifcloud.mbaas.core.NCMBException
import com.nifcloud.mbaas.core.NCMBUser
fun login() {
// Userインスタンスの生成
var user = NCMBUser()
//ユーザー名・パスワードを設定
user.userName = "takanokun" /* ユーザー名 */
user.password = "openGoma" /* パスワード */
try{
// ユーザー名とパスワードでログイン
user.login()
// ログインに成功した場合の処理
Log.d("success","ログインに成功しました")
}
catch(e:NCMBException){
// ログインに失敗した場合の処理
Log.d("failure","ログインに失敗しました : " + e.message)
}
NCMBUserクラスのsignUpメソッドでユーザー操作を行います。signUpInBackground()を使うと非同期処理で登録が行われます。
ユーザー登録を行うとそのままトークンが発行されセッションが開始
ログインしているカレントユーザーの情報が通信時に利用されるセッショントークンに設定されます。
セッショントークンはデフォルトで発行から24時間有効で、管理画面から任意の時間に変更することが出来ます。
ログイン後はCurrentUserクラスに情報が保持され、ローカルのCurrentUserの情報を利用して、トークンの再取得・自動ログイン等も実装できます。
ユーザー情報はコンソールの会員管理から確認することが出来ます。
登録後はloginメソッドでログインすることが出来ます。
ログイン後はgetCurrentUser メソッドを用いることで、現在カレントユーザーに設定されているユーザ情報を取得することができます。
また、画面遷移などによって保持していた セッショントークン情報 が失われた場合にも、
getCurrentUser を実行することで、ローカルに保存されているカレントユーザー情報から
セッショントークン を設定をし直すことができます。
// カレントユーザー情報の取得
val currentUser: NCMBUser = NCMBUser().getCurrentUser()
if (currentUser.getObjectId() != null) {
Log.d("Debug","ログイン中のユーザー: " + currentUser.userName)
} else {
Log.d("Debug","未ログインまたは取得に失敗")
}
データストアとアクセス制限の設定
ログイン後はカレントユーザーの権限(ACL)で該当ユーザーがアクセス許可されたオブジェクトやクラスにアクセスできるようになります。
オブジェクトに対してACLを設定する
// カレントユーザー情報の取得
//データの読み込み・検索のみ許可したNCMBAclを作成
val acl = NCMBAcl()
acl.publicReadAccess = true
//オブジェクトにACLを設定
val obj = NCMBObject("TestClass")
obj.setAcl(acl)
// オブジェクトの値を設定
obj.put("key", "value")
obj.save()
ACLの記載例
会員にオブジェクトのACLを指定する
{ "acl" : { "4suSlFT5xx" : { "read" : true , "write": true } } }
ロールにACLを指定する
{ "acl" : { "role:admin" : { "read" : true , "write": true } } }
ある会員にのみ、書き込み権限を指定する
{ "acl" : { "*" : { "read" : true } , "4suSlFT5xx" : { "read" : true , "write" : true } } }
ある会員に、読み込みのみの権限を指定する
{ "acl" : { "*" : { "read" : true , "write" : true } , "4suSlFT5xx" : { "read" : true } } }
管理画面からもACLの権限を変更することが出来ます。
クラスの単位でのACLの変更はコンソール上でしか行なえません。
オブジェクト操作
NCMBObject
データストア機能はNCMBObjectを通じて利用します。
NCMBObjectはスキーマレスなJSON互換のkey-value形式のオブジェクトを扱うことができます。
オブジェクトの保存先はNCMBObjectの初期化時に指定したクラスで識別されます。
Mobile BackendのデータストアはNoSQL(Not Only SQL)で操作します。
NoSQLはキーバリュー形式で管理が行われるため、データ構造を後から変更することが容易です。
RDBと比較した場合における、NoSQLの最も大きなメリットは処理速度が優れている点です。RDBはデータの一貫性を保つ目的で交通整理を行う必要があることから、データ量が増えれば増える程、処理速度が低下するという面があります。
一方のNoSQLは、RDBのような厳密な交通整理を行いません。その結果としてデータの一貫性を担保しない代わりに、膨大なデータでも素早く処理できるわけです。
「構造化データ」以外のデータを扱える点も、RDBにないNoSQLの特徴と言えます。構造化データとは、文字通り構造を整形されたデータのことです。構造化データの代表例として、ExcelやCSVファイルがあげられます。
一方「構造化データ」以外のデータとは画像・動画・PDFなど、決まった構造を持たないデータのことです。構造化データ以外のデータは、非構造化データ・半構造化データと呼ばれます。
RDBは表形式でデータを管理するデータベースであることから、構造化データ以外は格納できません。一方のNoSQLはRDBのような制約がないため、非構造化データ・半構造化データも格納できます。
NoSQLとは?注目される背景や種類をわかりやすく解説より:引用元
基本の操作はobjectIdを指定してクエリを発行せずにデータを操作することが出来ます。
またNot Only SQLはSQLのように複雑な条件での検索も可能です。
mobile backendではqueryインスタンスに条件やオペレーターを追加して検索条件を絞ることが出来ます。
こちらは詳細にふれると長くなってしまうので詳しくは公式ドキュメントをご参照ください。
最後に
ご精読ありがとうございました。
今回、日記形式で記事を書かせていただき、DBのクラウド化という目的からMBaaS導入という趣旨に落ち着きました。
MBaaSを利用して、しみじみ感じたのは仕組みづくりの大変さでした。
本記事のチュートリアル実施後、早速個人開発のアプリケーションにGoogleアカウントでの認証を実装しました。
カプセル化されブラックボックス的に扱える技術により自分の技術領域が広がると、先人たちが作った道を踏みしめていることを感じます。
裏側の仕組みやインフラを気にせず開発できることは、工数の削減も大きいですが開発に対する精神的な敷居を払えることが
大きく感じます。
近年ではローコード・ノーコードの領域やAIプログラミングが発展し、エンジニアがコード書かない未来が囁かれています。
いつかエンジニアが開発スキルより、アイデアが重要視されるクリエイター性の強い仕事になる日が来るのでしょうか。