まもなくリリースされる予定の Magic WebClient は、単に Magic の歴史を塗り替えるだけでなく、開発ツール業界全体の歴史を変えてしまう程のインパクトを秘めていると言えます。

今回は Magic xpa 4.x WebClient のリリースを目前に控え、その歴史をひも解きながら、なぜこの業界が今、あらためて Web アプリなのかを検証してまいりたいと思います。

この流れから分かるように、Magic は常に Web アプリを最終目標に据えて進化し続けてきました。その過程において、ブラクラだけは Java アプレットの衰退と、.NET Framework による RIA の登場で自然消滅した状態となっていますが、マージと RIA は現在もなお、Web アプリの先鋭として第一線で活躍しています。

ただ、マージは Web ブラウザ上で動作はするのですが、バッチタスクがベースであるため、インタラクティブなロジックの記述ができませんでした。これに対して RIA はインタラクティブなロジックの記述は可能となったのですが、クライアントは OS ごとに実行用の専用アプリの配布が必要でした。

実は、その背景にはここ数年における Web アプリの環境の進化があります。その代表とも言えるのが、今回 WebClient で採用された Angular と Node.js です。Magic のタスクで定義されたインタラクティブなロジックは、Angular によるシングルページアプリケーションに変換されて実行されます。この連携は、他社のどのツールも成し遂げえなかった画期的なアイデアなのです。

つまり Magic は、時代の先端を行っているどころか、すでにそれを超越して活用レベルの域にまで到達してしまっているのです。これはひとえに、Magic 30年の履歴と、熱烈な Magic ユーザの支持に支えられてきた結果の賜物であると言えます。

ここでは、これらの流れを踏まえたうえで、WebClient を導入して完璧に使いこなすための心構えと、具体的な準備事項を連載購読者の皆さんにご案内して参りたいと思います。

SQLite は名前こそ「Lite」とはなっていますが、実際に使用してみると、「ライト」とは言い難いほどの高性能なリレーショナルデータベースであることが分かります。SQLite のデータベースファイルの最大サイズは140TB（テラバイト）で、Microsoft SQLServer Express 版の10GB と比較しても、その約1万4千倍の値となります。さらに、SQLite は現在、Android OS に標準で搭載されているDBでもあり、Google のお墨付きリレーショナルデータベースであるとも言えます。

Magic から SQLite を使用する場合、何が便利であるかのトップは、データベース用のエンジンを別途、インストールしたりメンテナンスしたりする手間が不要であるという点です。Magic 本体に組み込まれた SQLite 用のゲートウェイがすべてをこなしますので、DB エンジンへの接続設定も不要です。データベースファイルの管理も Magic の Project フォルダ単位で行えますので、移動にまつわるアタッチ・デタッチやバックアップ・リストア等の作業も不要となります。

ただ、Magic から SQLite を使用するに際して唯一、不便であるのが、デフォルトではマルチユーザアクセスに対応していないという点です。たとえば、Magicに標準添付されているサンプルアプリケーションはその大部分が SQLite を用いて動作するように設定されていますが、これらをマルチユーザ対応にしようとすると、若干のタスクロジックの変更が必要となります。

このタスクロジックの変更方法については、本連載の第92回（2015年10月号）～第97回（2016年3月号）で「データベース SQLite の使い方」と題して詳しく解説しています。ただし、その時点での解説はクラサバを中心とした内容でしたので、今回はこれを RIA で用いた場合の利便性についてまとめていきたいと思います。

今年（2019年）の11月にリリースが予定されている Magic WebClient を含めると、これで Web マージ、RIA、WebClient のすべての Magic 製品群がブローカー経由でのバックグラウンド実行の形態となり、唯一、クラサバだけがフォアグラウンド実行の単体アプリケーションとして残ることになります。

つまり、Magic 製品群においては、すでに xpi シリーズをも含めてブローカーは Magic アプリの中核をなすミドルウェアゲートウェイとなっており、ブローカーの位置付けは今後も更に重要なものとなってきますので、この機会にぜひその操作法に慣れ親しんでおきたいと思います。

さて、前回までは1つのブローカー上で複数のアプリを並行実行させるところまでを学びました。今回はその続きとして、RIA Server と Enterprise Server を同居させる方法を解説し、将来的に WebClient との同居までを考慮した予備知識を蓄えておくことにします。

ご周知のとおり、Magic では RIA Server と Enterprie Server は別売の製品となっています。そして、RIA Server がすでに導入されている環境に、さらに Enterprise Server（あるいは将来の WebClient）をインストールして一元管理しようとすると、特殊な設定が必要となります。今回はその設定を行う方法について学びます。

さて、これで Magic 開発版と RIA Server を共存させ、1つの Broker からこれらを一元管理する方法について確認することができました。今回は引き続き、1つの RIA Server 上で複数のアプリケーションを実行させ、1つの Broker でこれらを一元管理し、各アプリケーションを個別に停止・再起動させる方法について学びます。

通常、Windows のサービスで Broker を停止すればすべてのアプリケーションは自動的に終了するのですが、この方法では保守を必要とする1個のアプリケーションの再起動に伴い、保守を必要としない他の複数のアプリケーションも一時停止を余儀なくされてしまうという不都合が生じます。

とくに、アプリケーションの再起動によって、エンドユーザが持つ各セッションのコンテキスト ID が初期化されると、それに伴いローカルデバイスに記録されているクッキー等が無効になるという副作用が発生します。なるべくならば、必要としないアプリケーションの再起動は避けたいものです。

そこで今回はこれらの不都合を無くすために、Windows のサービスを再起動せずに、Broker モニターの機能だけで、各アプリケーションを個別に停止・再起動する方法について学びます。

Broker モニターとは、Magic に添付されている Broker の動きをリアルタイムでモニタリングするツールのことです。アプリケーションが正常に動作しているかどうかの確認や、アクセスログを見たりすることができる便利なツールです。

デフォルトでは、この Broker モニターは単一アプリケーションの監視を担う役割となっていますが、実はこのモニタリングツールは複数の Broker を一元管理できる仕組みとなっており、複数のアプリケーションや複数の Magic 製品、あるいは RIA と Web マージとを同時に管理したりすることも可能となっています。

※画面1は、Magic xpa 2.5 RIA Server と Magic xpa 3.1a Enterprise Server、および Magic xpa 3.2c RIA Server の3つを一元管理している図です。

今回はこのモニタリングツールを使った複数ポート、複数アプリケーションの管理法について学んでいきたいと思います。

では、この原因はいったいどこにあるのでしょうか？

原因は、iOS の位置情報にまつわるセキュリティの仕様変更にあります。

iOS 10 + Xcode 8までは、位置情報の利用は「常に許可」または「許可しない」からの二者択一だったのですが、iOS 11 + Xcode 9以降は「このアプリの使用中のみ許可」という選択肢が必須オプションとなったため、従来の記述方式ではこのダイアログが正常に表示されなくなりました（画面4）。

そのため、App Store 提供の汎用クライアントでは画面5～6のように位置情報の設定オプションが iPhone の設定項目として表示されているにもかかわらず、オリジナルビルドでは画面7のように設定項目が非表示となってしまっています。

では、これに対処するにはどうしたらよいでしょうか。

前回の Android クライアントの手動ビルドに続き、今回は iOS クライアントの手動ビルドについて解説いたします。

Magic のインタフェースビルダを用いた Xcode プロジェクトの生成法については、本連載の第120回から第123回に渡って解説しましたが、ここではインタフェースビルダを使用せず、すべてを手動でビルドする方法について解説します。

Magic xpa の当初の理念は、Xcode の知識がなくてもインタフェースビルダとシェルスクリプトの実行だけで iOS 用のビルドが完了するという簡便性にあったのですが、Xcode の進化と共にアプリの認証法が容易になってきたため、Xcode を起動して手動でビルドを行ったほうが簡潔に処理できるようになってきた経緯があります。

このような歴史的な観点を踏まえて、手動ビルドの方法について検証していきたいと思います。

なお今回より、使用するソフトウェアのバージョンが iOS 12.2、Xcode 10.2.1、macOS 10.14.4となります。これは実機ビルドに際して、最新の iOS のバージョンにフェーズを合わせるための必須環境となります。バージョンアップはすべて無償ですので、App Store より最新のバージョンを取得してインストールしておいてください。

※このアップデートがないと、iOS 画面のナビゲーションバーとタイトルバーの表示が重なってしまいます。

本連載の第124回から第127回に渡り、「インタフェースビルダで Android クライアントを作る」と題して、インタフェースビルダを用いた Android クライアントのビルド方法を解説してきましたが、今回ここではもう一つ別のビルド手段である手動ビルドの方法について解説して参りたいと思います。

インタフェースビルダを用いた方法は、ウィザードというブラックボックスを用いた方法である関係上、ビルドの途中で何かトラブルが発生した場合に個々の要素を順を追って確認することが困難です。これに対してコマンドを用いて手動ビルドを行う方法は、設定が面倒である反面、個々の設定要素を目視で確認できるというメリットがあります。

どちらが便利であるかは環境に応じて異なりますが、マジック社では手動によるビルドを推奨しているようですので、本連載も手動によるビルド法を詳細かつ具体的に解説していくことにします。ビルド時に画面1のようなエラーばかり出てお困りの方は、ぜひお役立てください。