開発中に、この知識は今後も活かしていけると思った内容を今回は紹介したいと思います。
関数定義これまで関数を作成する際は基本アロー関数にしていました。
簡潔に書くことができるからです。
そして開発中に新しく覚えた関数定義の方法とは、クラスを使用するものです。
class authMagnetarModule {
async signinWithPhoneNr({ phoneNumberRaw = '', smsCode = '' }) {
if (!!smsCode) {
return await _phoneAuth.signin(smsCode).catch((e) => throwAuthError(e, 'signin'))
}
if (!!phoneNumberRaw) {
return await _phoneAuth.sendSigninSms(phoneNumberRaw).catch((e) => throwAuthError(e, 'signin'))
}
return
}
}
const authModule = new authMagnetarModule()
export { authModule }
・クラスによる関数定義のメリット
再利用性 ・メソッドやプロパティを一つ単位でカプセル化
・必要に応じてインスタンスを生成することができる
・同じ機能を複数の場所で再利用することができる
維持管理 ・クラス内にコードをまとめることで機能が1箇所に集中し、
コードの修正や拡張が容易になる
テスト
・クラスによるモジュール化は、個々の機能を独立してテストしやすい
型安全性 ・静的型付けをサポートする環境では、クラスを使用することで型安全性が向上
また、クラスを使用せずともアロー関数のまま似た設計で書くこともできますので、この辺は個人の好みでしょう。
例
const useAuthModule = () => {
async function signinWithPhoneNr({ phoneNumberRaw = '', smsCode = '' }) {
if (!!smsCode) {
return await _phoneAuth.signin(smsCode).catch((e) => throwAuthError(e, 'signin'))
}
if (!!phoneNumberRaw) {
return await _phoneAuth.sendSigninSms(phoneNumberRaw).catch((e) => throwAuthError(e, 'signin'))
}
return
}
return {
singinWithPhoneNr
}
}
export const authModule = useAuthModule()
また、JavaScript、TypeScriptだけではなく他言語を使用するにあたってもクラスの使用は役に立つものということで、これからの開発でもうまく使用していきたいと思います。
ネイティブアプリ開発で気をつけることcapacitorを使用し、ネイティブアプリの開発に励んでいます。
iosではXcodeを、androidではAndroid studioを使用して開発しています。
すべてを書くとなるととても長くなるので割愛し、詳しくはまた別の記事で紹介します。
今回は要点を簡潔に紹介します。
今回の開発ではSMS認証、deeplink、プッシュ通知を実装しました。
SMS認証iosでは1日に10回という制限以外は、特に大きな障害はありませんでした。
androidはiosと違い苦戦しました。
問題点①:認証コードが届かない
問題点②:2回連続で認証コードの送信をするとタイムアウトエラー発生
問題点③:iosではエラーが出ていないのにandroidでは出てしまうエラー
問題点④:認証コードは届いているが、アプリ起動中にバナーが出ない(android)
deeplink問題点①:リンクを踏んでもアプリに復帰ではなく、ブラウザで展開してしまう
問題点②:アプリ設定にてリンクの設定が必要(androidのみ)
問題点③:ドメインの所有権の証明とDNS設定
プッシュ通知問題点①:プッシュ通知が届かない
問題点②:通知バナーがアプリ起動中に表示されない(android)
▫️プッシュ通知が届かない場合
Firebase → プロジェクトの設定 → マイアプリに
SHA-1、SHA-256のフィンガープリントが設定されているかを確認してください。
デバックキーの設定も必要になります。
Linux または macOS の場合のコマンド
keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android
Windows の場合のコマンド
keytool -list -v -keystore "%USERPROFILE%\.android\debug.keystore" -alias androiddebugkey -storepass android -keypass android
▫️通知バナーがアプリ起動中に表示されない(android)
iosでは設定などせずともプッシュ通知は問題なく表示されますが、androidはそうはいきませんでした。
アプリがフォアグラウンドの際には表示するように設定する必要があるのです。
下記のように送信されたプッシュ通知をAndroid studio内で取得し、表示させてやる処理を記述し作動させてやることでアプリがフォアグラウンド状態であってもプッシュ通知が表示されるようにできました。
private void showNotification(String title, String body) {
Intent intent = new Intent(this, MainActivity.class);
intent.setAction("news_intent"); // clickActionと一致させる
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, intent, Build.VERSION.SDK_INT >= Build.VERSION_CODES.S ? PendingIntent.FLAG_MUTABLE : PendingIntent.FLAG_ONE_SHOT);
// NotificationManagerのインスタンスを取得
NotificationManager notificationManager = (NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
// Android Oreo以上での通知チャネル設定
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
NotificationChannel channel = new NotificationChannel(
"Notifications",
"Notifications",
NotificationManager.IMPORTANCE_HIGH);
channel.setDescription("MyChannelDescription");
notificationManager.createNotificationChannel(channel);
}
// 通知の構築
NotificationCompat.Builder builder = new NotificationCompat.Builder(this, "Notifications")
.setSmallIcon(R.mipmap.ic_launcher) // 通知アイコンの設定
.setContentTitle(title) // 通知タイトルの設定
.setContentText(body) // 通知内容の設定
.setPriority(NotificationCompat.PRIORITY_HIGH) // 通知の優先度設定
.setVibrate(new long[]{500,500,500}) // バイブレーションの設定
.setLights(Color.BLUE,3000,3000)
//.setAutoCancel(true) // 通知をタップしたら自動的に通知を消す
.setContentIntent(pendingIntent);
// 通知の表示(各通知には異なるIDを割り当てる必要がある)
notificationManager.notify(1, builder.build());
}
iosとandroidで使用する言語が異なるのはもちろんですが、設定の有無も異なります。
どちらかで不具合が起きた場合、対応する言語で機能を追加したり、ドキュメントを読み込んで対応するしかありませんでした。
以前JavaもSwiftも触ったことがあったのでスムーズに対応できました。
日頃から他言語のことを多少なりとも勉強しておくと急な案件にも対応できるので基本的な処理の書き方だけでも覚えておくといいでしょう。
関数定義とプッシュ通知について書きましたが、deeplinkとSMS認証については次回の記事で紹介します。
時と場合によって定義の方法を変えると保守管理しやすくなったり、ドキュメントにはそれ以上のことが記載されておらず、つまづくこともあるかと思います。
ですがめげずにドキュメントの一言一句見逃さず読んでみてください。
必ず突破口になりうるヒントがあります。
開発中に私はそう思いました。
また次回の記事でお会いしましょう。