株式会社ストロボライトのエンジニア開発ブログです。株式会社ストロボライトのエンジニア開発ブログです。LOVEGREEN、botapii、MIDOLASを支えるエンジニアの日々の生活を綴っていきますこの広告は、90日以上更新していないブログに表示しています。トップ画は私が育てている亀甲竜(冬型)です。使ってアプリ開発をしましたが、やはり色々とハマりました。そのなかでもこれは辛かった!と思ったものを共有致します。FacebookのCordovaプラグインを入れるとビルド出来ない。input要素へのタップが無視される(iOS)事象input要素のtype=“text”へのタップ時にフォーカスがあたらず、キーボードが表示されない、という現象が起きました。聞いたところ、iOSのWebビューコンポーネントであるUIWebViewのバグでした。UIWebViewはApple社としては既に非推奨になっているようですが、Cordovaでは未だデフォルトでUIWebViewが使われています。そこで下記のプラグインを導入し、WKWebViewにすることで解決されました!https://github.com/oracle/cordova-plugin-wkwebview-file-xhrhttps://github.com/onderceylan/cordova-plugin-wkwebview-inputfocusfixiPhoneXからのノッチ対応もWKWebViewのほうが楽なので、Cordova開発する時にはWKWebViewプラグインは必須と考えてよいと思います。問題に注意が必要です。IDEでビルドしたアプリを動かした際、Cordovaプラグインが全く読み込まれない、という現象が起きました。アプリは起動するがプラグインのAPIはまったく呼び出せない、という状況です。問題は、monacaが生成するwebpack設定ファイル(webpack.config.js)に対して変更した箇所でした。monacaが生成するwebpack設定ファイルにはproductionモードとdevelopmentモードがあります。productionモードでは、ソースファイルのminifyやconcatといった一般的に製品版で必要となる処理が行われるように設定されています。一方でdevelopmentモードではこれらの処理は行われません。実装中はデバッグ効率化のために、developmentモードでビルドするように設定ファイルを変更してました。実は、monacaのwebpack設定ファイルでは、developmentモードにするとプラグインを読み込まないようになっていました。IDEでビルドする際は常にproductionモードでビルドすることでプラグインが使用出来るようになりました。自社APIサーバとXHR通信出来ない事象それまでは通信出来ていたのに、ある日突然XHR通信出来なくなりました。iOSのATS対応のためのWhitelistプラグイン設定のミスや2.のプラグインが読み込まれない問題と同時期に発生しため、切り分けに苦労しました。解決方法この問題は1.でWKWebViewを導入したことに起因する問題でした。Cordovaではローカルのソースコードを動かすためfile://プロトコルとして動作します。そのため、APIサーバとのHTTPS通信はクロスドメイン通信となります。UIWebViewでは問題が生じませんが、WKWebViewではサーバ側でCORSを有効化しないと通信してくれません。よって、APIサーバ側でCORSを有効化してもらうことで解決しました。下記のエラーが出力されて取得失敗しました。backend.解決方法config.xmlへ下記を入れることで、取得出来るようになりました。通信をインタラプトした際に、どうやらFirestoreとの通信を阻害しているようです。使うべきだったかもしれません。アシアルの方に解析して頂きました!本当に感謝です。FacebookのCordovaプラグインを入れるとビルド出来ない。package.jsonへ以下を追記します。導入してmonacaでビルドすると、ビルドに失敗します。phonegap-plugin-pushの最新2.2.x系では「7.1.0」が必須となっています。これによりビルド出来ません。そこで、phonegap-plugin-pushの2.1.x系までversionを落とす必要がありました。最後にCordovaアプリ開発では有志によるプラグインの力をお借りすることで、ネイティブと同じ機能を実現出来ます。その一方で、有志が提供するものであるがゆえにバージョンや相性問題が起きやすいです。いった情報もみんなで共有、解決することで盛り上げて行きたいですね!あと、monacaのビルドサーバも問題が生じていることがあります。なにかおかしいなぁと思ったら以下を見ると良いです。ja.monaca.io以上です。エンジニア、小河原です。今回は既に動いているアプリケーションに後からFirebaseを導入する、という業務で多々ある、しかしWebにはあまり詳しく情報がない「カスタム認証」について書きたいと思います。同じように実装する人の少しでもお役に立てればいいなと。Let'sスタートです!!やったことカスタム認証とは証明書の取得IAMロールの設定カスタムトークン(IDトークン)発行処理private-key.pemファイルの作成カスタムトークンの作成まとめカスタム認証とはFirebaseはGoogleが提供するBaaSです。AuthenticationというSNSやSMS認証機能も提供されているため、サーバーレスで新規アプリケーションを作る際にはとても便利です。提供されている認証方法のうち、既にユーザー認証機能は自社システムで持っていて後からFirebaseの認証のみを追加するケースのために、提供されているのがカスタム認証です。新しい秘密鍵の生成から秘密鍵をダウンロードすべてのサービスアカウントを管理へ移動IAMロールの設定admin-sdkアカウントのIAMロールにサービスアカウントトークン作成者権限を付与します。カスタムトークン(IDトークン)発行処理private-key.pemファイルの作成ダウンロードした秘密鍵からprivate-key.pemを作成します。秘密鍵をテキストエディタで開くとprivate-keyやpublic-key等pemファイル作成に必要な情報が記載されています。pemファイルはpemファイルとして読み込まれるためのフォーマットがありますので、フォーマットに沿って作成しましょう。作成が終わったら、既存の認証サーバーに配置しましょう。参考記事qiita.comカスタムトークンの作成こちらはPHPのLaravelフレームワークを使用して書いたサンプルコードです。FirebaseのカスタムトークンはJWTフォーマットなので、JWT変換するためにライブラリを使用しています。}}ユーザー認証後に、ここで作成したカスタムトークンも付与して、フロントに返却します。フロントはこのカスタムトークンを使用し、FirebaseのsignInWithCustomToken(token)を呼び出す事で認証が行えます。まとめカスタム認証便利!!そして新規のモバイルアプリケーションを作成する際はユーザー認証もFIrebaseに寄せてmBaaSとして最大限活用できれば開発スピードが上がる事は間違いないと思います。高速化Tweetどうも、ストロボライトでエンジニアをやっている荒木です。弊社でもエンジニアブログを始める、ということで、初めてのエントリを拝命しました。全ての事業を見ておりネタとしても色々とあるのですが、今回は「LOVEGREEN」にて実施した「nginx+WordPressでサイト高速化」について触れてみようかと思います。「fastcgi_cacheの設定」で、結果は?WordPressのみのチューニングの限界この辺りは昔から色々と誰もが試行錯誤して情報は世の中に沢山溢れていますが、高トラフィックなサイトでのチューニングとなると、WordPress単体でのチューニングには限界が出てきます。そもそも、トラフィックが多いのでサーバーも含めた総合的な高速化を行わないと限界があるということです。WordPressという構成に変更しました(この辺りのお話しは、また別の機会に)で、そこからnginxのキャッシュを使って、そもそもWordPressに処理をさせないようにします。Cache」の導入です。この辺りは、沢山ドキュメントが出ていますので、特に迷うこともないかと思います。「nginx.conf(もしくはvhostのconf)」に必要な設定を追加していきます。Cacheの設定周りだけ記載してみました。そんなに特殊なことはしていません。「fastcgi_cache_pathの設定」ここは基本マニュアル通りに設定します。現状ではinactiveを1日にして、全くアクセスされなかったページは1日で削除されるように設定しています。maz_sizeは10Gにして多めにキャッシュできるようにしています。Onlyにしているのでキャッシュ時のkey(fastcgi_cache_key)に含めるHTTPスキーマも「https」固定にしてあります。「変数定義」この辺りは動的に設定する変数の定義です。$cache_enableという変数を定義して、動的にキャッシュする、しないを切り替えられるようにしています。「リクエストメソッドでのキャッシュON/OFF」ここではGETメソッド以外はキャッシュしないように制御しています。「リクエストURLでのキャッシュON/OFF」キャッシュしたくないページのURLを列挙していきます。WordPressの場合、管理画面のURL、sitemapのURL、WordPressのフォーム画面などのURLになります。特定のCookieを持っている場合、キャッシュしない設定をここで定義します。WordPressの場合だとwordpress_logged_inwp-postpasswordpress_[a-f0-9]+ぐらいですね。コメント機能があるのであれば、comment_authorも入れておけばよいかと思います。「UA判定でキャッシュKeyをPC/SPで分ける」PCとSPでURLが同じ場合、キャッシュのKey(fastcgi_cache_key)を同じにしてしまうと、PCの時にSPの画面が表示されたり、SPの時にPCの画面が表示されたりしてしまいます。レスポンシブサイトであれば問題なさそうですが、LOVEGREENはそうではないので、キャッシュKeyをデバイスごとに判定して、PC/SPそれぞれデバイスにあったキャッシュを作成、保持して上げる必要があるので、このようにUA判定を入れています。「fastcgi_cacheの設定」ここでfastcgi_cacheの設定を定義しています。主な項目について説明していきます。fastcgi_no_cacheキャッシュする、しないを$cache_enableによって設定しています。fastcgi_cache_bypassキャッシュでの応答有無をを$cache_enableによって設定しています。(キャッシュが存在してもWordPressからレスポンスを返却するかどうか)fastcgi_cache_keyここで、実際のキャッシュする際のキャッシュKeyを生成しています。基本、ページURL+デバイスでユニークになるように、プレフィックスで$is_spを設定するようにしています。Insightsで計測すると、キャッシュ導入前、導入後で以下のような結果となりました。3.3sまぁ、元々が遅かったので、キャッシュの恩恵は出ているのかな?と思います。何より、Frontの描画処理でのCPU利用率が下がったので、管理画面側のレスポンスが異常に良くなりました。(これまでは更新に3分待つとか、地獄のような状態だったので)これによって、編集部メンバーから称賛されるという、予期しない効果も出ています。濃い内容ではないですが、これから開発事業部のメンバーが定期的に技術的なエントリ、たまに趣味の話など、色々綴っていきますので、よろしくお願い致します。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。