はじめにElectronでアプリを作っています。弊社のイベントでも、なんどかそのお話をしています。connpassElectronのアプリは、大きく分けて以下の2つのパートで構成されています。Main側:Node.jsのプロセス。OSの機能を呼び出したり、Renderer側を起動したりできるRenderer側:Chromiumによる画面描画のプロセス。CSSファイル)を読み込んで画面描画を開始するのですが、このHTMLは、アプリ内に同梱したものだけでなく、Webに配置したものを読み込むことが可能です。CSSを配置すると何がうれしいかと言うと、アプリに何か修正を行いたい場合、Renderer側の修正だけであれば、修正したバージョンをユーザーにインストールしてもらうことなく、修正が全ユーザーに反映されるということです。要するに、インストール型アプリでありながら、部分的にWebアプリのようなリリースの利点が得られるということです。我々のアプリは、当初はRenderer側のファイルもローカルに保持する構成で開発していたのですが、途中から上記のようなメリットを得るために、Renderer側をWebに配置する構成への変更を行いました。この変更が、思ったよりも大変だったため、具体的に何を考え、どのような変更を行ったのかをまとめたのが、本記事の内容となります。Policyは、ブラウザで読み込んだページが属するオリジンのみからしかリソース取得を行えない、という制約です。詳細は、以下のサイトをご覧ください。developer.mozilla.org要するに、ブラウザ上からは、ドメインが違うサイトへのHTTPリクエストは発生させられない、ということです。Policyが発動することはありませんでした。Webからファイルを読み込む場合は、この制約が発生してしまいます。これにより何が困るかと言うと、Renderer側からWebAPI等へのアクセスができなくなるということです。本アプリでは、認証などのためにWebAPIを叩く必要があったため、これは困ります。そこで、本アプリでは、HTTPリクエストを発生させる元を全てMain側に移しました。Main側では、Electronのnetモジュール、Node.jsのhttpモジュール、あるいはaxiosに代表されるようなHTTPクライアントライブラリを使うことができます。Renderer側からは、ElectronのIPCを通じて、Main側のHTTP呼び出し機能にアクセスします。Main側はIPCで"http"というメッセージを受けたら、HTTPリクエストを行うようにしておきます(httpRequestはHTTPリクエストを行う関数です)。httpRequest(message);});そして、preloadスクリプトに上記のIPC呼び出しを行う関数を定義しておき、Renderer側ではこの関数を呼ぶことで、HTTPリクエストを行うようにします。Policyは回避できました。これによる副次的な効果として、Webに公開しているコード内に、アクセス先のURLや、WebAPIに渡すトークン等のパラメータを埋め込む必要がなくなったので、セキュリティ的にもよかったと思います。ローカルでの動作確認用にWebサーバーを立てる開発中のローカルでの動作確認時に、Renderer側はどこにあるファイルを読みに行くべきか、は少し悩みました。Node.jsでのアプリ開発ではNODE_ENV環境変数で動作モードを切り替える、という手法がよく使われるので、developmentモードを指定した場合はローカルにあるファイルを、productionモードを指定した場合はWebに配置したファイルを読む、というようなことは少し考えました。これは以下の理由により避けました。Policyなど)ため、日常的にWebから読む状態で開発しないと、いざリリースするときに想定していなかった問題が発生する恐れがあるdevelopmentモードかproductionモードかは、ファイルをどこから読むかとは別問題というわけで、開発中でもWebサーバーを立ててファイルをホストさせ、Renderer側はそれを読み込みに行くようにしました。Webサーバーを立てるツールは、以下のようにしました。developmentモードの場合:webpack-dev-serverproductionモードの場合:http-serverwebpack-dev-serverは一般的なフロントエンド開発でもよく使われるツールです。hot-reloadを有効にすれば、Electronであってもコードの変更時に自動的にリロードされるため、便利でした。http-serverは、Node.js製の、手軽にWebサーバーを起動できるCLIツールです。www.npmjs.comproductionモードの場合、実際のリリース物と同じビルドとなるため、webpack-dev-serverを使うのは適切ではありませんでした。代わりに、webpack-dev-serverと同様にコマンドで起動して手軽に使える、http-serverを採用しました。ローカルでの動作確認用にアプリとWebサーバーを同時に起動する前述のように、開発中であってもWebサーバーを立てる構成としたので、動作確認の際には、ElectronアプリとWebサーバーの両方を起動させる必要があります。ElectronもWebサーバーも、プロセスが端末を占有してしまうので、それぞれを起動させておくために端末を2つ立ち上げておく必要があります。このような操作が必要な場合、以下のようなミスが発生しやすくなります。動かないと思ったら、Webサーバーが起動していなかったなぜか動かないと思ったら、Webサーバー側でエラーがでているのに気づかなかったElectronとWebサーバー、両方の再起動が必要なのに、それを忘れ、うまく動かなかったいずれも些細な問題ではありますが、発生頻度がそこそこ高く、開発速度の低下につながるため、早めに対処しておきたいところです。どのように対処するかというと、要するに以下のようなことが実現できていればよいと考えました。コマンド一発でアプリとWebサーバーが両方起動することアプリを終了したら、Webサーバーも終了すること上記を実現するため、今回はConcurrentlyというCLIツールを利用しました。www.npmjs.comこのツールは、複数のコマンドを並行して実行できるため、この問題の解決にピッタリです。このConcurrentlyを使い、アプリの起動コマンドを以下のように作成しました。上記のコマンドでのポイントは以下です。0を直後に実行して、終了コードを強制的に正常終了にするこのようにすることで、Webサーバーの存在をほとんど意識せず、アプリの動作確認を行えるようになりました。アプリからの参照先Web環境を切り替える一般的なWebアプリを開発する場合、開発/ステージング/本番のように、用途ごとに環境を使い分けることはよく行われます。Webアプリの場合は、ブラウザに入力するURLをそれぞれの環境のものに切り替えれば済むのですが、Electronアプリはアプリ内に参照先のURLを持たせなければならないため、Webアプリほど簡単に環境を切り替えることができません。Electronアプリが参照するURLを切り替える方法を考えたとき、真っ先に思いつくストレートな方法としては、設定ファイルにURLを記載し、アプリはそれを参照してURLを取得する、というものがあります。これは以下のような理由で避けることにしました。ユーザーによって値を改変されたくない:もしユーザーがファイルの内容を書き換えたりしてしまった場合、アプリが動作しなくなる恐れがありますユーザーが普通に見える場所に値を置きたくない:URLや各種パラメーターが見えることで、アプリへの攻撃を行うヒントになってしまうかもしれませんただ、個人的にはそもそも環境の値が可変値なのがしっくりこなかったのが理由としてあります。アプリ本体とWeb側は一体のものであり、Web側はパラメータとして気軽に差し替えするようなものではないと考えました。結果として、アプリをビルドする際に、Web側の環境を埋め込むことにしました。以下に、環境を決定する仕組みを示します。ビルドを行うコマンドを実行する際に、環境変数で参照先の環境を指定します。ここでは、DEPLOY_ENVという環境変数で、環境指定を行っています。buildアプリのコード内では、上記の環境変数で指定された値に対応する環境設定ファイルをrequireするようにします。環境変数は、WebpackのDefinePluginを用いてビルド時に埋め込みを行っています。"development"}`)以上の仕組みにより、ビルド時に例えば"development.js"のようなファイルが結合され、アプリ内に環境の値が埋め込まれるようになります。参照先Web環境を上書きする前述の仕組みにより、参照先の環境の問題は解決したと思ったのですが、開発工程の中で「本番環境向けのビルドを開発/ステージング環境へ向けるようにしてテストしたい」という要望があることがわかりました。要するに、本番環境向けビルドと開発環境向けビルドは、同じソースからビルドしていても別物なので、開発環境向けビルドをテストしても、本番環境向けビルドをテストしたことにはならない、ただし本番環境でテストすることは避けたい、という理屈です...。これを解決するため、特定の位置に設定ファイルがあれば、そこに記載された値をアプリに埋め込まれた設定値よりも優先する、という機構を追加しました。先ほど「設定ファイルを避けた」と述べましたが、これは開発中のリリース前テスト等の工程で利用するものであり、ユーザーが使う機構ではないため、設定ファイルを回避した理由は維持しているつもりです(;・∀・)なお、弥生の他の製品でも、実際にこのような設定の上書きを行うような機構を使ってテストを行っています。おわりにElectronアプリのRenderer側をWebに配置するようにする際、どのような変更を行ったかについてご紹介しました。同様のことでお困りの方の助けになれば幸いです。明日は@t_haraさんの「Swift製ファミコンエミュレータ開発の進捗について書く」です。こんにちは、弥生のヨコヤマです。最近入社したばかりのぺーぺーUI/UXデザイナーです。いうと★5が出るくらいの確率です。そのため、初めて日本に来たパンダのような感じであたたかく見守られています。ところでみなさんはAR好きですか?日本語では拡張現実と呼ばれているアレです。ARもVRも好きです。サンタさん今年のクリスマスはOculusください。ARはたくさんの可能性を秘めています。AppleやMicrosoft、Googleと有名企業もこぞって取り組んでいるところを見るに、その勢いは弥増しているように思われます。購入前の家具を部屋に置いた時のイメージを把握できたり、晴れた空にクジラを泳がせてみたり、もしかしたら、思い出せないあの人の名前を頭上に表示してくれたりなんてことも可能になるかもしれません。空を泳ぐクジラ見た~い🐳そんなARコンテンツを自分の手でで作れたら最高だと思いませんか?思います。「でも、ARってプログラムとか3Dモデルが必要だったり難しいんでしょ?」とお思いのそこのアナタ。AeroはPhotoshopやIllustratorなどでおなじみの、Adobeが開発したARツールです。MAXで発表され話題を集めました。以前よりAdobeがARに注力していることは知られていましたが、満を持してお披露目されたというわけですね。そんなAeroさんですが、何がステキなのか。その理由を以下に記します。Cloud契約してるから実質無料」とかではなく、混じりっけなしのピュアな無料です('19/12/21現在)。13.1以降にアップデートされているデバイスをお持ちの方なら、誰でも利用することができます。入口が絞られた感じがしますが、iPhoneシェア率が異常に高い日本人にはそこまで高くないハードルではないでしょうか。コーディングスキルが必要ないこれこそが人々をARコンテンツ制作から遠ざけていた一番のハードルではないでしょうか?Aeroでは一切のプログラミングが不要です。アプリ画面を数回タップするだけであっという間にARコンテンツができあがります。デザインスキルも必要ない逆にデザインスキルがなくて、「自分で素材を作れないよ(><)」という方も大丈夫。Aeroには結構な数の「スターターアセット」が用意されていて、すべてロイヤリティフリーです。使いたいモデルを選んで、あとはアプリ画面を数回タップするだけであっという間にARコンテンツができあがります。アセットたくさん!ここで紹介してるのはほんの一部です。アニメーション付きのアセットもあります。サルでもわかるUIわざわざ天丼してまでお伝えした通り、何も分からなくても数回タップすればとりあえず作品ができてしまうくらい直感的なUIです。サーフェス設定後の初期画面では、重要そうなボタンは1つしか見当たりません。「とりあえずそれを押す」以外の答えを導き出せるならむしろ教えてほしい。おサルさんでも使えますね。シンプル~~!青いボタン1個しかないもん。押すよね!🐵チュートリアルが手厚い残念ながら使い方が分からなかったみなさん、ご安心ください。手厚いチュートリアルがあります。アセットの配置からスタートして、一般的な制作手順に乗っ取って進んでいくので、全体の流れも掴みやすいです。長すぎず短すぎず、しかしながら要点を抑えたコメントも随時出てくるので、きっと迷いも少なく次へ進めることでしょう。私はサル以下だったので大変お世話になりました。お前もARにしてやろうか!さて、Aeroの概要を把握したところで実際にARしてみましょう。AeroではDimensionをはじめとして、Adobe製品のファイルを多くサポートしています(もちろんヨソで作った子も読み込めます)。ARなので派手に3Dモデルを使いたい気持ちもありますが、10年以上モデリングなんてしてないし時間もないので、今回はPhotoshopで作ったネコチャンのデータを使いたいと思います。2Dなのでペラペラです。言うとナニッパラッパーです。Aero用のpsdファイルを書き出すネコチャンこと「nekochan.psd」は1枚のレイヤーで構成されているファイルです。PCでPhotoshopからAeroで読み込めるファイル形式にします。[Aeroに書き出し]これだけです。Cloudファイルにしておくと後々ラクチンです(その他の方法でもモチロン読み込めます)。※[Aeroに書き出し]は最新のデスクトップ版Photoshop(バージョン21以降)のみに搭載されている機能です。iPad版ではできないのでご注意ください。Aeroに読み込む舞台をモバイルデバイスに移し、Aeroに今作ったpsdファイルを読み込ませます。Cloud]から「nekochan.psd」を選択します。無事ネコチャンが世界に顕現しました!1本指操作でX軸・Z軸の移動、2本指操作で拡大縮小・回転、3本指操作でY軸の移動ができます。配置場所を決めたら、アセットをタップして終了です。インタラクティブ機能をつける最後にインタラクティブ機能を追加しましょう。アセットをタップして、出てきた下部メニューの[動作]をタップします。そこからまずトリガーを選択します。トリガーには3種類あって、それぞれ開始時、タップ時、指定した距離に侵入した時にアクションが開始します。アクションにはたくさん種類があるのですが、今回はトリガー:タップ、アクション:バウンスを選択します。いい感じのバウンスになるように各種数値を調整。納得できる動きになったら、もう一度アセットをタップして完了です。完成ショボいですがとりあえず完成です。上部メニュー右のプレビューをタップすると、実際の動作を確認したり、画面を撮影したりできます。ファイルの書き出しを失敗したりもしましたが、それを含めても30分くらいでここまでたどり着けました。う~ん、簡単!タップするとネコチャンがピョンピョンします。実は複数レイヤー読み込めるちなみにpsdファイルですが、複数レイヤーを保持したままAeroに読み込むことができ、読み込んだレイヤーを等間隔に配置することができます。これだけだとピンとこないと思うので早速やってみましょう。ここではネコザイルのデータを使います。ネコザイルこと「nekoxile.psd」は以下の5枚のレイヤーで構成されています。[Aeroに書き出し]をクリックすると、レイヤーをフラット化するか保持するかのダイアログが出てくるので[保持]を選択します。これでpsdファイルの準備は完了です。次にAeroに読み込みます。以下が読み込んだ直後の「nekoxile.psd」です。レイヤーが多層的に配置されているのが分かります。このままではギュウギュウに詰まっていて、ネコザイル達が息苦しそうです。ここでアセットをタップして、複数レイヤー情報を持つアセットのみに表示されるメニュー[レイヤー]をタップします。X軸・Y軸・Z軸それぞれの調整スライダーが表示されるので、Z軸を広げてやります。すると......程よく距離感ができて、いい感じのファンファンウィーヒッタステーッステーになりましたね。ちなみに縦並びや横並びにもできます。タテザイルとヨコザイル作ってみたというわけで、今回得られた知見を駆使してARクリスマスディスプレイを制作してみました。思ったところに配置できなかったり、考えていたものと違うアクションになったり、見た目の華やかさと裏腹に地味で地道な作業が目白押しです。自分の空想でしかなかったものが形を成して日常空間に浮かび上がっていく過程はとてもワクワクできる時間だと思います。これを見て「自分もARはじめよっかな」と興味を持ってもらえたら幸いです。ちなみにお使いのiOS端末(13.1以降)で実際にご覧いただけるので、よろしければこちらのQRコードからお楽しみください。デスクトップ版もプライベートベータとしてリリースされていて、これからの展開もとても楽しみです。私も今回の知見を活かし、弥生会計ARの開発に取り組んでいきたい所存です嘘です。Composerにも挑戦してみたいですね。22日目は、uchoさんです。震えて待て!それではみなさんハッピーホリデーよいお年を。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。