「cordova」を含む日記 RSS

はてなキーワード: cordovaとは

2021-10-08

anond:20211008015428

FlutterXamarinRNCordovaも基本クセが強いし(特にiOS側が)ガワネイティブでWebview貼るだけならネイティブでいいよ

最近Android WebViewは基本的Android ChromeだしWKWebViewはMobile Safariなので検証もそんなに大変じゃない

Cordovahtmlを使ってローカルで動くアプリのビューを組み立てるelectronみたいなやつだからユースケースが別

Android開発に詳しい人で分かる人がいたら教えてほしいんだけど

Androidでガワネイティブアプリ(Webとしてアプリ実装してWebViewで表示するだけスマホアプリ)を作りたい場合ってどういう技術使うのが良いの?

具体的には広告関係だけネイティブっぽい機能ライブラリ使って表示できるようにして、

機能的なアプリ側の部分は基本ほとんどガワネイティブ実装したいと思ってる、なるだけ手間がかからない方法で。

一番ラクPWAとかTWAはAdmobみたいな広告が載せられないっていう問題があるんよね。広告載せたいためだけのガワネイティブ化。

ちなみにWeb屋だからガワネイティブの中身側はわかるけどアプリ開発自体初心者

普通にネイティブがいい?なんか最近名前聞くFlutterとかXamarinがいい?それともCordova?

2019-12-29

モバイルアプリハイブリッド実装で後悔したもろもろ

モバイルアプリ実装と言えば主力はKotlinSwift(Objective-C)だけど、簡単な作りであればcordovaベースフロントエンド開発ライクに進められる。

そもそもライブラリ選定には関わっていなかったものの、便利と思って使った結果後悔した思い出のお話

WebViewベースである以上、イベントレンダリング系統ネイティブに劣る

特にiOSが顕著だった。

Angular, Vue実装していたけどレンダリング系に属するイベント盛りだくさんの場合

結果的ネイティブ実装したほうが楽だしレンダリングの面で有利。

そもそもcordovaからと言ってネイティブ知識がいらないわけじゃない。

標準サポートしているプラグイン群でできることは限られてくるし、そのまま突き進むならネイティブ実装知識必要になる。

フロントエンド開発できない奴が作れる代物ではない

これは当たり前だけど…

JSパッケージングだったりCSSビルドが組めないとなると逆にコスト高。

Angularベースで進めていたときにそれは起こった。

そもそもNode.jsビルド根本的に理解してない奴がプロジェクトを作ったせいで

JSパッケージビルドもされない、jQueryを突っ込まれるなどひと悶着あった。

3年前くらいだったけど既にTypeScriptも出てたし、何故そうしなかったのか理解できない。

結果ロードが激重になった。そりゃそうだ、minifiedされてないのだから

用法用量を正しく守って使わないと、後で面倒になる好例だった。

ビルドが意外と面倒で手間

大概は専用プラットフォーム上でビルドしていくがこれがくせ者。

ブラウザIDE(という名のただのテキストエディタ)が使えるけどそもそも構成管理できない。

ローカルビルド乖離するし、ブランチすら切れないのだから本人以外は触れないシロモノになってくる。

ビルドのためにアップロードするんだがこれまた賢くない。

別端末でビルドしようとすると同名の新しいプロジェクト作成される。

ここまでくるともう触りたくなくなる。ただ、触らないわけにはいかないので何とか整合が取れる状況にした。

さらに言えば、ビルドが終わってステータスが見れるが、内訳が見れるのはそのタイミングだけ。

これはマジで止めてほしい。殺意が湧くレベルでやめてほしい。

多分、海外で公開したプラットフォームをそのまま持ってきてるんだと推測しているが流石にこれは悪意しか感じない。

やろうと思えばそりゃローカルビルドはできるけれども。

クライアントOSで動くビルドツールが使い物にならない

ただのCLIバックグラウンドで実行するだけのGUIラッパーと化している。

かといってlintを掛けてくれるわけでも無し。

個人的に要らないし今後は使わない。

WEB RTCを使うとiOS互換に苦しむ

突き当たったのはWebSocketを使うシーンが出てきたとき

ライブラリで何とかする方向で進めたかったけどそもそもwebpackビルドにすら対応していなかった。

件のAngularベース場合もっとひどくてクソラッパーを作りやがったせいで依存度が激高になった。

ちなみにネイティブはそれぞれにサポートするライブラリが出ていて、最新バージョンに向けてきちんとメンテナンスされている。

その辺はJS世界の闇に降れた瞬間でもあったりした。

総括

根本的にiOS側の実装レスポンシブ的なレイアウトが作りにくい現状を鑑みて、

WEBベースで新商品などの通知をしたい、残りは情報の閲覧のみでSPA構成的なシロモノで作りたい。

こんな需要には使ってもいいんじゃないかと思う。相当なレアケースだけれども。

いいところは確かにあって、CSSデザインの調整が効くところは大いに評価できる。

これがまたネイティブ実装だと面倒。特にiOS。お前はダメだ。

結局進めていくとネイティブ実装知識を求められるのだからネイティブ実装したほうが良くね?と言ったところ。

ユースケース的に超単純要件アプリを作りたい、かつ、ユーザに何かpush知的なやつを入れたいって場合は使ってもいい気がする。

うそ大手でもなければ無い気がするけど。

2019-02-20

オンラインエロゲ終了でオフラインプレイヤーを書いたら感動した

「対魔忍アサギ 決戦アリーナ」というオンラインゲーム(エロゲ)が終了する

まあ終了自体は仕方ない。このゲームゲームと言うには余りに大きな設計ミスを抱えすぎており、また、システム的にもかなり古くなっている。

だいぶ前からオンラインゲーム終了時にどうするか、という話はあるけど、あまり進展はない(ソシャゲ、ネトゲ等のサービス終了後のゲームの保存について考える、とか、米国でサービス終了オンラインゲームを著作権法例外とする動き―ESAは反対とか)。一つ根本的な問題として、本当にオンライン重要ゲームオフラインモードに余り意味がないのも大きい。

でも、対象エロゲ特に抜きゲ)なら話は別

何せ、最低限エロシーンだけ再生出来れば需要を満たす。

逆に、ゲームとしてのサービスが終わろうが俺には見たいエロシーンがあるんだよ!

anond:20190209083051 とかでも書かれていたけど、エロの質はいいし、ここにしかないものも多い。しかもそれは(ゲーム上で)自分が苦労して手に入れたものだ。勝手に閉じてほしくない。

……けど、運営コストを考えたらそうも言ってられないのはよく分かる。

というわけで、今こそオフラインプレイヤーの出番だ。

自分入手した分のデータダウンロードして、後は各人がローカルPC再生すればいい。

必要機能は大きく分けて、サーバからデータダウンロードしてくる部分、それからデータカードエロシーン)を閲覧するパートだ。

ちなみにこのゲームは初期に作られただけあって(?)、エロシーンに機能が少なく、BGV はおろか BGM も無い。オーバレイも1枚のみで、基本的に背景(シーン画像含む)と、テキストに 1:1 対応するボイスしかない。

これなら割とできそうな気がしたので保存・再生するソフトウェアを書いてみることにした。

というわけで出来たものこち

https://aakeeper.appspot.com 驚くほどあっさりできてしまった。

でも、今はできた物自体の話はいい。それより作る過程で色々感動したのでその話をしたい。

今や OSS には巨人の肩どころか常にジェット機に乗ってるくらいのツールが揃っている

今回使ったのはざっくり以下のもの

これらのツールに関して、自分殆ど学者だ。

Quasar FrameworkNode.js も Electron も使うのははじめて、他はちょっと触ったことあるけどそんな詳しくない。 ES もあまり好きでなかったので基本的には避けてきた。

にもかかわらず、全体で余暇時間2週間分くらいで出来た。

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 製のアプリメモリをやたら喰う、少しもっさりしている、配布バイナリが巨大になるという問題は確かにある。

しかし、そうだとしても何より、とてつもなく高速に作れて、各種プラットフォームで割とちゃんと動く。

自分は色々初めてだったので結局2週間分くらい掛かったけど、前提知識が揃っている人なら本当に数日でできたりするんじゃなかろうか。

状況は良くなっている

つい数年前まで、クロスプラットフォームアプリケーション作成というのは本当に本当に大仕事だった。こんなに早く手軽に書ける事は無かったし、ユーザ側でもラインタイムインストール必要とか環境側のハードルも非常に高かった。

自分は今まで知らなかったけど、最早そういう時代は終わっていた。

もちろん過去に数多くのクロスプラットフォームフレームワークが登場しては消えていったのと同じく、Electron もいつかその仲間入りをするだろう。

でも確実に、びっくりするくらい状況は良くなっている。

興味があるけどまだ触ってないという人は、ぜひ試して感動を味わってもらいたい。

Happy Hacking!

2016-07-05

http://anond.hatelabo.jp/20160705125248

から割り込みスマソン。

特にネイティブレベルデバイス操作する必要がなかったり、グラフィックゴリゴリ動かすってことじゃなければワンソースマルチプラットフォーム正義、って理解でOKですかね?

ちょうど今日Cordovaってのを教えてもらったばかりのトピックなので食いついてみた。

 
ログイン ユーザー登録
ようこそ ゲスト さん