修正
- 2021/04/22
- タイトル修正
- 元タイトル: WebViewを実装してアプリとするのはもうやめにしませんか。
- タイトル修正
（元タイトルから）なぜそう思ったのか
Android、IOSのアプリの多くの案件がWebサービスのスマホ版としてWebViewを実装してHTMLを表示させたいという要望が多い気がします。
確かにAndroid、IOSのWebViewは便利です。
Javascriptやカスタムスキーム を駆使してWeb版よりもユーザビリティに優れた機能を実装することもできるでしょう。
しかしながら、それらのユーザビリティに優れた機能は詰まるところアプリ側に実装する機能であり、
HTTPプロトコルをアプリ側がスパゲティな実装で監視したり、アプリ側がリクエストを処理している間にWebViewが画面遷移しないようにブラウザバックなどを制御したり、Javascriptがうまく動かなかったり、HTMLデザインチームとうまく連携できなかったり、画面サイズの問題でHTMLが崩れたり、アプリ申請時に本番に穴を開けれなくてリジェクトされたり。。。
ということになって結局言葉で説明することが非常に難しい自体に陥りやすいと思います。
私たちは十分に経験しました。。
WebViewは万能ではないと。。
じゃどうするかって？
決まってます。
HTMLでやりたかったことをきちんとアプリの画面で実装しましょう。
サーバではAPIを実装して、
アプリでそれを叩きましょう。
お金がないからWebViewなんだ？
ちゃんと見積もって話しましょう。結局あれこれ問題が出て、おんなじくらいお金と時間がかかることになると思います。
それでも WebView じゃなきゃダメなんだ
WebView実装で気をつけなければならないところリスト
- Javascript を実行してアプリに処理を戻す時
- Jsを実行できたとしてもサーバ側の都合で画面遷移したりするのでレスポンスを返す処理の場合は念入りに設計した方がいいですよ。
- WebViewからJSを利用する場合はセキュリティリスクがあります。
- 詳しくはこちら →
- [WebView でのウェブアプリの作成]（https://developer.android.com/guide/webapps/webview?hl=ja#BindingJavaScript)
- IFを複雑にするとサーバ側とアプリ側の両方の管理が非常に厄介になりがちです。シーケンシャルに実行しなければならない時などデバッグも大変です。留意しておきましょう。
- iframe は鬼門です。全く制御できないと思っていた方がいいでしょう。
- HTMLで再生している外部サービスの動画は鬼門です。全く制御できないと思っていた方がいいでしょう。
- 複雑な業務系の場合はWebViewは全く向いていないことを理解してもらった上で、覚悟して実装しましょう。
おわりに
WebViewはせいぜい利用規約の表示や頻繁にデザイン更新が必要な起動時の広告などに利用する程度のものだと思います。
アプリとしてWebViewのみに頼った実装は最初は楽かもしれませんが、最後の最後でアプリの申請につまづき、その頃には機能の追加修正を行う時間はなくなり、設計もままならぬままえいやで実装する。。そこはもう後戻りできない砂地獄のように、全てを巻き込んでぐちゃぐちゃになったカオスしか残らないと思っています。
簡単なものなら、、まぁ、、アリかとも思う。。