ENECHANGE Developer Blog

ENECHANGE開発者ブログ

ネイティブアプリ開発をスムーズにするためにサーバーサイドエンジニアとして取り組んだ4つのこと

EV充電サービス事業部の@yuyasatです。暑い時期ですが、日々EVライフを満喫しています。1kmあたりの移動で考えたときにガソリンよりも電気の方が安いのでガソリン車時代よりも距離を乗っている気がします(環境に良いのか悪いのか・・)。

今回は、EV充電サービスのアプリ開発にあたって、ネイティブアプリ開発をスムーズに行える様にするために、サーバーサイドエンジニアとして取り組んだことを書いてみようと思います。

認証の簡略化

EV充電サービスアプリでは、電話番号を入力すると6桁のワンタイムパスワードが記載されたショートメッセージ(SMS)が送られ、その番号を入力することで認証をします(図1)。アプリの仕組み上、電話番号に基づいてユーザーが作成されますから、開発時やQA時は異なる電話番号で認証する必要があります。このとき、電話番号を用意し、毎回ショートメッセージを確認して入力するというのは非常に大変です。そこで、開発環境やQA環境では、どの6桁の番号でも認証を通す様にしました。このときSMSは送られない様にしておきます。こうすることで開発者やQAの方がどの電話番号でもログインできます。また、SMSを送るコストも削減できます。6桁の番号が間違っていて認証エラーとなる場合も、例えば電話番号の下4桁が9999の場合は認証エラーとなる様に返すとすることで、開発や動作の確認ができます。
また、このようにダミーではなく、実際にSMSでワンタイムパスワードを送ってテストする必要もあります。この場合は、特定の電話番号であればSMSを送る様な仕組みを導入してテストしました。
この挙動にはログイン認証をしやすくするということに加えてQA時にも有効に働きました。QAの方が報告した不具合に対してエンジニアは挙動を確認するのですが、QAの方がログインしたときと同じ電話番号を使えばエンジニアもログインできるわけですから、不具合となっている挙動をすぐに確認できます。これは当初想定していなかったメリットでした。

図1. 認証画面

レコードの事前生成

アプリには充電履歴を表示するという機能があります(図2)。その名の通り、過去に充電した履歴を閲覧できる機能です。一画面に表示できるレコード数以上の場合の挙動も実装・確認する必要がありますから、特定の日に1回だけ充電した程度のレコード数では開発がしにくいです。そこで、開発時にはユーザーの作成と同時に充電履歴のレコードを生成する様にしました。日毎の充電件数はランダムで生成する様にすることでできる限り現実に近い形でレコードを生成する様にします。こうすることで開発者はログインしたと同時に充電履歴の開発ができます。もちろんこの動作は一度開発が終わったあとは解除します。

図2. 充電履歴画面

実際の充電器をエミュレート

これはエネチェンジEVチャージアプリの固有の特徴ですが、実際の充電器と連携する以上、充電器がないと充電開始や停止ができません。しかし、実際の充電器がないと充電開始や停止が試せないというのでは、開発効率が激減してしまいます。そこで、実際の充電器からのレスポンスを模擬し、充電器がなくても充電開始・停止や料金計算ができる挙動となる様にしました。

SwaggerでのAPI記載し同時に実装も完了させつつデザインの整合性も確認

ネイティブアプリ開発をするにあたって避けて通れないのがサーバーサイドのAPIです。ネイティブアプリからは頻繁にAPIが呼ばれます。今回、APIの定義はすべてSwaggerを用いて記述しました。今はSwaggerを使うのは標準だと思いますが、今回の開発の場合、SwaggerでAPI定義をするとともに実装も行いました。多くの場合、APIを定義したのち、実装に取り掛かりSwaggerを使うことでサーバーサイド側の開発が終わっていなくてもネイティブアプリ側の開発ができます。しかし、机上でAPI定義をしたとしても実際に実装をしていくうちに不十分な箇所がどうしてもでてきてしまいます。API定義と実装を行き来して開発することで考慮漏れをできる限り減らすことができました。
実際にはAPIを使用する箇所のデザインと並行してAPI定義や実装を行うことで画面描画に必要なデータを漏れなく定義できているか、逆にデザイン側で要件上実現が不可能なことが描かれていないかをチェックできます。API定義・実装・デザインチェックを同時並行で行うことで開発速度が高まると思います。

最後に

開発のためにproductionでは実行されないコードを書くのは一見すると開発効率を落とすものに見えるかもしれません。しかし、ネイティブアプリ開発やQAの効率を考えると実装は取るに足りないコストでした。過去にも少しの手間を惜しんだ結果開発に時間がかかるということを経験したことがあるので何が開発効率の向上に効く活動なのかというのを意識しながら開発を進めていきたいなと思いました。

エンジニア募集中!!

EV充電サービス事業部では日本の電気自動車の未来を一緒に築いていく仲間(Railsエンジニア、Flutterエンジニア)を募集中です!ぜひご応募お願いします! enechange.co.jp enechange.co.jp

Team Blog HubのAtomフィード配信はじめました

CTO室の岩本 (@iwamot) です。同僚エンジニアの情報発信を活性化するのが、ぼくのミッションのひとつです。

ENECHANGEでは、Team Blog Hubを使って、所属エンジニアのブログ記事や発表スライドを集約・公開しています。経緯は「Team Blog Hub を用いた ENECHANGE エンジニア記事まとめサイトの公開」に書きました。

そして先日から、集約結果のAtomフィード配信も始めています。Team Blog Hubにはフィード配信機能がないため、forkしたソースコードに手を入れた形です。

今回の記事では、具体的にどう実装したかをご紹介します。

続きを読む

作る前に知っておきたかった、アプリデザイン時のチェックポイント4選

EV充電サービス事業部デザイナーの @hoshility と申します。

2022年5月に電気自動車 ( EV )・プラグインハイブリット車 ( PHEV ) 向けの充電サービスのアプリをリリースしました。こちら大変便利なアプリになっているので、ぜひ使ってみていただけると嬉しいです。

ENECHANGE EV CHARGE

iOSアプリはこちら

Androidアプリはこちら

続きを読む

Flutter採用理由とFlutterで開発してみて

引き続き、EV充電サービス事業部の@yuyasatです。

前回は、EV充電サービスアプリ開発経緯についてご紹介いたしました。今回は、ネイティブアプリ開発にあたってなぜFlutterを採用したのか、Flutterを採用してみてどうだったのかというのを紹介したいと思います。

なぜFlutterを採用したのか

私はこれまでRailsを軸としながらフロントエンドはVue.js、開発のディレクション、AWSのインフラ周りをさわるなどしながら仕事をしてきました。Webの一連の技術に関しては詳細とまではいかないまでも大まかな概要はつかんできたなという実感があったので、2018年ごろ、プライベートで少しだけAndroidアプリの開発をKotlinで行っていました。その当時はプライベートで知見を広げるため程度での開発でしたが、Webと比べたらビルドにかかる時間も長いですし、iOSとAndroidをそれぞれ対応しないといいけないとなると、iOSアプリはSwiftで、AndroidアプリはKotlinで開発という形となり、スピード感をもって開発するのが難しいという印象を持ちました。クロスプラットフォーム開発では、当時はReactNativeやXamarinなどがありましたが、周りに話を聞くと結局はiOS、Androidそれぞれ開発しているという現場もあり、決定打に欠ける印象をもっていました。加えて仕事ではネイティブアプリ開発の機会はありませんでしたので、ネイティブアプリの開発に関してはあまり深く関わることはなくしばらく過ごしていました。

続きを読む

エネチェンジEV充電アプリリリース🎉

EV充電サービス事業部の@yuyasatです。

今年1月に昨年まで在籍していたエネルギークラウド事業部からEV充電サービス事業部に異動し、開発責任者としてエネチェンジEV充電のアプリを開発してきました。先月19日にアプリをリリースすることができ、エネチェンジでのネイティブアプリ開発をいかに立ち上げてリリースに至ったかを簡単にご紹介したいと思います。

エネチェンジEV充電アプリでできること

まず、エネチェンジEV充電のアプリでできることは、全国に設置されている充電器を検索することができ、エネチェンジEV充電サービスで提供している充電器に関してはアプリから充電の開始や停止、課金ができます。従来なら充電するためのカードをクレカ登録等と共に申し込んで充電器に併設されている認証システムにタッチして充電するという形でしたが、エネチェンジEV充電アプリを使えば、アプリをインストールし、クレジットカード情報を登録するだけで充電できます。

エネチェンジEV充電アプリ

続きを読む

Lambda関数URLを実戦投入してシンプルなリダイレクト処理を構築する(コスト編)

ENECHANGE所属のエンジニア id:tetsushi_fukabori こと深堀です。
東京の我が家で飼っているバーニーズマウンテンドッグは暑さでバターのように溶けて伏しています。
涼しい土地に広い庭付き一戸建てで健やかに過ごさせてあげたいですね。

今回は前回に引き続きLambda関数URLを実戦投入したときのコストについて考えます。

この記事の概略

  • AWS Lambdaの2022年4月の新機能「関数URL」を実戦投入しました
  • Route53 + CloudFront + Lambda関数URLでシンプルなリダイレクト処理を構成しました(前回実践編で紹介)
  • CloudFront functionやLambda@Edgeを使う場合と比較して小さいながらコストメリットがあることを整理しました
続きを読む

CloudFront Functions 関数でクエリ文字列を復元する

CTO室の岩本 (iwamot) です。「小ネタでも積極的に投稿する」をモットーとしております。

先日、Amazon CloudFront の CloudFront Functions を使って、HTTP リクエストのリダイレクト処理を実装しました。https://example.com/foo?key1=A&key2=B&key2=C へのリクエストを https://other.example.com/bar?key1=A&key2=B&key2=C にリダイレクトするだけの内容です。

しかし、実装の際、CloudFront Functions の関数にはクエリ文字列そのものが渡らないことを知りました。かわりに、解析後のオブジェクト ({key1:{value:'A'},key2:{value:'B',multiValue:[{value:'B'},{value:'C'}]}}) が渡ってきます。

今回の記事では、リダイレクトを実現するために採用した、クエリ文字列の復元方法をご紹介します。

続きを読む