  |
はてなキーワード: Cordovaとは
FlutterもXamarinもRNもCordovaも基本クセが強いし（特にiOS側が）ガワネイティブでWebview貼るだけならネイティブでいいよ
最近のAndroid WebViewは基本的にAndroid ChromeだしWKWebViewはMobile Safariなので検証もそんなに大変じゃない
Cordovaはhtmlを使ってローカルで動くアプリのビューを組み立てるelectronみたいなやつだからユースケースが別
Androidでガワネイティブアプリ(Webとしてアプリを実装してWebViewで表示するだけスマホアプリ)を作りたい場合ってどういう技術使うのが良いの？
具体的には広告関係だけネイティブっぽい機能かライブラリ使って表示できるようにして、
機能的なアプリ側の部分は基本ほとんどガワネイティブで実装したいと思ってる、なるだけ手間がかからない方法で。
一番ラクなPWAとかTWAはAdmobみたいな広告が載せられないっていう問題があるんよね。広告載せたいためだけのガワネイティブ化。
ちなみにWeb屋だからガワネイティブの中身側はわかるけどアプリ開発自体は初心者
モバイルアプリの実装と言えば主力はKotlin、Swift(Objective-C)だけど、簡単な作りであればcordovaをベースにフロントエンド開発ライクに進められる。
そもそものライブラリ選定には関わっていなかったものの、便利と思って使った結果後悔した思い出のお話。
Angular, Vueで実装していたけどレンダリング系に属するイベント盛りだくさんの場合、
結果的にネイティブ実装したほうが楽だしレンダリングの面で有利。
そもそもcordovaだからと言ってネイティブの知識がいらないわけじゃない。
標準サポートしているプラグイン群でできることは限られてくるし、そのまま突き進むならネイティブ実装の知識は必要になる。
これは当たり前だけど…
JSのパッケージングだったりCSSビルドが組めないとなると逆にコスト高。
そもそもNode.jsのビルドを根本的に理解してない奴がプロジェクトを作ったせいで
JSのパッケージビルドもされない、jQueryを突っ込まれるなどひと悶着あった。
3年前くらいだったけど既にTypeScriptも出てたし、何故そうしなかったのか理解できない。
結果ロードが激重になった。そりゃそうだ、minifiedされてないのだから。
用法用量を正しく守って使わないと、後で面倒になる好例だった。
大概は専用プラットフォーム上でビルドしていくがこれがくせ者。
ブラウザIDE(という名のただのテキストエディタ)が使えるけどそもそも構成管理できない。
ローカルビルドと乖離するし、ブランチすら切れないのだから本人以外は触れないシロモノになってくる。
別端末でビルドしようとすると同名の新しいプロジェクトが作成される。
ここまでくるともう触りたくなくなる。ただ、触らないわけにはいかないので何とか整合が取れる状況にした。
さらに言えば、ビルドが終わってステータスが見れるが、内訳が見れるのはそのタイミングだけ。
多分、海外で公開したプラットフォームをそのまま持ってきてるんだと推測しているが流石にこれは悪意しか感じない。
ただのCLIをバックグラウンドで実行するだけのGUIラッパーと化している。
かといってlintを掛けてくれるわけでも無し。
個人的に要らないし今後は使わない。
突き当たったのはWebSocketを使うシーンが出てきたとき。
ライブラリで何とかする方向で進めたかったけどそもそもwebpackビルドにすら対応していなかった。
件のAngularベースの場合はもっとひどくてクソラッパーを作りやがったせいで依存度が激高になった。
ちなみにネイティブはそれぞれにサポートするライブラリが出ていて、最新バージョンに向けてきちんとメンテナンスされている。
根本的にiOS側の実装でレスポンシブ的なレイアウトが作りにくい現状を鑑みて、
WEBベースで新商品などの通知をしたい、残りは情報の閲覧のみでSPA構成的なシロモノで作りたい。
こんな需要には使ってもいいんじゃないかと思う。相当なレアケースだけれども。
いいところは確かにあって、CSSでデザインの調整が効くところは大いに評価できる。
これがまたネイティブ実装だと面倒。特にiOS。お前はダメだ。
結局進めていくとネイティブ実装の知識を求められるのだから、ネイティブで実装したほうが良くね？と言ったところ。
ユースケース的に超単純要件でアプリを作りたい、かつ、ユーザに何かpush通知的なやつを入れたいって場合は使ってもいい気がする。
まあ終了自体は仕方ない。このゲームはゲームと言うには余りに大きな設計ミスを抱えすぎており、また、システム的にもかなり古くなっている。
だいぶ前からオンラインゲーム終了時にどうするか、という話はあるけど、あまり進展はない（ソシャゲ、ネトゲ等のサービス終了後のゲームの保存について考える、とか、米国でサービス終了オンラインゲームを著作権法例外とする動き―ESAは反対とか）。一つ根本的な問題として、本当にオンラインが重要なゲームはオフラインモードに余り意味がないのも大きい。
逆に、ゲームとしてのサービスが終わろうが俺には見たいエロシーンがあるんだよ！
anond:20190209083051 とかでも書かれていたけど、エロの質はいいし、ここにしかないものも多い。しかもそれは(ゲーム上で)自分が苦労して手に入れたものだ。勝手に閉じてほしくない。
……けど、運営コストを考えたらそうも言ってられないのはよく分かる。
自分入手した分のデータをダウンロードして、後は各人がローカルPCで再生すればいい。
必要な機能は大きく分けて、サーバからデータをダウンロードしてくる部分、それからデータ（カードやエロシーン）を閲覧するパートだ。
ちなみにこのゲームは初期に作られただけあって(?)、エロシーンに機能が少なく、BGV はおろか BGM も無い。オーバレイも１枚のみで、基本的に背景(シーン画像含む)と、テキストに 1:1 対応するボイスしかない。
これなら割とできそうな気がしたので保存・再生するソフトウェアを書いてみることにした。
https://aakeeper.appspot.com 驚くほどあっさりできてしまった。
でも、今はできた物自体の話はいい。それより作る過程で色々感動したのでその話をしたい。
今回使ったのはざっくり以下のもの
Quasar Framework も Node.js も Electron も使うのははじめて、他はちょっと触ったことあるけどそんな詳しくない。 ES もあまり好きでなかったので基本的には避けてきた。
Quasar Framework は、とにかく物凄くよく出来ていてびっくりした。今回 Electron モードしか使っていないけど、本来はこれで SPA/PWA/モバイル(Cordova) アプリケーションが作れるという凄まじい対応幅のプラットフォームになっている。着手時に 1.0beta の予告だけあるというタイミングの悪さ(数日後に出た)だったので、 0.17 系を使った。しかし、それでも十分すぎるほどよく出来ている。
ES は今でも嫌いな点は多いんだけど、今回 async/await を使って感動した。これは素晴らしい。他の言語にも欲しい。
CoffeeScript は趣味だけど、とにかく短く書ける点が素晴らしい。あれは終わったという人もいるが、記述量の少なさは js 系では他の追従を一切許していない。今回みたいな急いでいるケースでは、括弧の世話を焼いたり eslint おばさんと語り合う時間はない。CoffeeScript ならコンパイラが全部上手くやってくれる。
HTML5 ベースの GUI は今や chronium の各種アクセラレーションのおかげで、並のポータブル GUI ツールキットよりずっと高速に動作する。
また、Vue.js + pug は非常に記述量が小さくて目的の画面がすぐ作れ、カプセル化がしやすくコンポーネントの再利用も容易だ。
Babel/Webpack は正にバッドノウハウを煮詰めて固めた感じだが、こいつがバッドな部分を吸収してくれるおかげで開発者は正気を保てる。ただし追求しだすとSAN値が減る。
ユーザ側から見ると、Electron 製のアプリはメモリをやたら喰う、少しもっさりしている、配布バイナリが巨大になるという問題は確かにある。
しかし、そうだとしても何より、とてつもなく高速に作れて、各種プラットフォームで割とちゃんと動く。
自分は色々初めてだったので結局２週間分くらい掛かったけど、前提知識が揃っている人なら本当に数日でできたりするんじゃなかろうか。
つい数年前まで、クロスプラットフォームなアプリケーションの作成というのは本当に本当に大仕事だった。こんなに早く手軽に書ける事は無かったし、ユーザ側でもラインタイムのインストールが必要とか環境側のハードルも非常に高かった。
自分は今まで知らなかったけど、最早そういう時代は終わっていた。
もちろん過去に数多くのクロスプラットフォームフレームワークが登場しては消えていったのと同じく、Electron もいつかその仲間入りをするだろう。
でも確実に、びっくりするくらい状況は良くなっている。
興味があるけどまだ触ってないという人は、ぜひ試して感動を味わってもらいたい。
