クライアントから rhomobile フレームワークについて尋ねられました。私はそれを少し調査しており、コミュニティ全体がフレームワークについてどう考えているか、また、フレームワークを使用して開発する際に遭遇した問題 (ある場合) を確認したいと考えていました。
ありがとうございました、
L.
クライアントから rhomobile フレームワークについて尋ねられました。私はそれを少し調査しており、コミュニティ全体がフレームワークについてどう考えているか、また、フレームワークを使用して開発する際に遭遇した問題 (ある場合) を確認したいと考えていました。
ありがとうございました、
L.
アプリケーションのビューのみがプラットフォームのブラウザーでレンダリングされます。Ruby コードからデバイスのネイティブ機能にアクセスするためのバインド (写真の撮影、GPS データへのアクセスなど) があり、これを独自のネイティブ コードで拡張することができます。もちろん、ビューは単なる HTML であり、デバイスのネイティブ UI ほどネイティブではありませんが、それはクロス プラットフォーム開発のために支払わなければならない代償です。RhoMobile の大きな強みは、組み込みの同期機能です。これにより、モデルデータを中央のバックエンドと同期できます。
基本的に、RhoMobile の戦略は、各デバイスのブラウザを活用して、Web コントロールを各デバイスの「標準」コントロールのようにスタイリングすることで「ネイティブな感じ」を作成することです。これは、各 OS/デバイスの Web 機能によって、できることがいくらか制限されることを意味します。したがって、各アプリはネイティブ アプリですが、基本的には「ブラウザーで実行」されます。
また、App Store や Android Market などのさまざまなプラットフォームで展開がどのように機能するかもわかりません。
これらのマルチプラットフォーム モバイル開発者フレームワークを使用してアプリを App Store にデプロイするには、Mac OS X が必要です。ここでは、Rhomobile の従業員が Windows でアプリを開発していますが、Mac でのみ動作する Application Loader アプリを使用するために、Mac OS X に変更してデプロイしています。
フレームワークを使用するアプリを使用したことがありますが、動作が遅いと言わざるを得ません。ドキュメントを読むと、クロス プラットフォーム アプリケーションをすばやくリリースしたい場合に有効な選択のように思えます。
最近15日前に、Rhomobileの学習を開始し、いくつかの問題が発生しました。CRUD機能を含む単純なアプリケーションの作成は簡単です。しかし、Rhohubがデバイスで動作しないこの.apkファイルビルドで私が言及したいくつかの短所もあります