121 202 538：thingsboard二次開発のディスカッショングループへの参加を歓迎
ThingsBoard民営化の展開は、携帯電話上のダッシュボードのニーズを見る必然的にそこにあります。携帯電話のブラウザ上の一方ではなく、十分な専門的な経験のユーザーが貧弱であるため、ウェブサイトにアクセスすることができ、そのため、管理または表示するために、専用のアプリケーションを提供する必要があります。
このアプリケーションでは、2つのオプションがあります：まず、新しいアプリケーション、完全にネイティブ開発モデルであるThingsBoard対応する機能を呼び出すことにより、APIを開発し、2番目はの形で、UIパッケージThingsBoardある内蔵のWebアプリケーションモードブラウジング。高コストのかつての仕方、サイクル時間が比較的長いです;後者のシナリオは、コンティンジェンシー・プランとしてより適切である、とPCと携帯電話端末のパフォーマンスを最適化しながら、これに基づいて開発し続けることができます。
そここのようなパッケージのUrlアプリケーションを生成することができAppCanなど、多くのウェブサイトがありますが、すべてのリソースがリモートにあるこの方法は、リソースの多くは、だけでなく、ネットワークのアクセス速度が遅い上、またそのページに影響するときにページを訪問するたびにダウンロードしますレンダリング速度、直感的なユーザーエクスペリエンスは、より多くのカードであってもよいです。UIフレームワークもThingsBoard分離前端と後端を実現し、フロントエンドは、App、AndroidとiOSを使用するパッケージに直接コンパイルすることができます。リソースはローカルの携帯電話にしているので、あなたがフロントエンドアプリケーション、唯一のリモートアクセスAPI、上のJS / CSS / HTMLや他のリソースを置くことができますので、すぐにロードされます。今、ローカルリソースへのアクセス、リモートサービスを聞かせて、コードAngular.jsアクセスパスUI APIを変更する必要があり、その後、アプリケーションをパッケージ化、次の手順を実行します。
まず、コード変更のUI
1.変更したファイルのUI \ SRC \アプリ\グローバルinterceptor.service.jsは今ローカルリソースへのアクセス、リモートサービスを聞かせて、問題な角度APIアクセスのパスを変更する必要があります。
このファイルには、ここにAngular.jsグローバルインターセプタ、Ajaxリクエストの応答共通部分です。デフォルトのAjaxリクエストのような訪問することである「/ API / 」このパスは、前記宿主のパスで現在のページを訪問して行くだろう、と実際のアクセスへのフルパスがあるべきとして「http://192.168.1.222:8080/api/」これは、形成されます。アプリケーション内部では、jsはローカルで実行されますが、リモートサービスURLは、そのデフォルトのパスによって実際のサービスにアクセスすることはできません。図に示すように、赤色は、位置特定部1と内容を変更します。
これは、のCustomHostのようなカスタム変数、実サーバへのアクセスアドレスを指し、次のとおりです。
VARのCustomHost = " http://iot.yoxvtech.com:8080 "。
また、ソースは、応答判定、赤識別部2を変更したURL、及びライン167は同一のコードを追加する必要が後の最初の位置と同様です。
2.変更UI \ SRC \アプリ\ API \テレメトリ-websocket.service.js、実サーバアドレス点用WebSocketサーバ、図3に示したコンテンツの遠位端。
第二に、パッケージのApp
変更するためのフロントエンドUIの後、コンパイルし、道のファイルクロスドメインリクエストに問題があるだろうので、資産およびファイル道へのアクセスのアプリケーションに直接distのファイルにすることはできません、アクセス経路などの角がより良い方法アプリケーションにパッケージ化された後これは、単純なHTTPサーバ、フロントエンドUIファイルフォルダルートを構築しました。
内蔵のサーバーは、2つのモードがあります。まず、GitHubの上で使用するNanohttpdプロジェクトは、ウェブブラウザの負荷に、単純なHTTPサーバーを書き、ルートディレクトリにアプリケーション資産に適切なディレクトリを設定し、2番目は完全に混合使用の開発モードです、ビルトインのhttpdプラグインハイブリッドやサービス開発。
比較的単純なものの前者のアプローチは、まだ、いくつかの開発が必要です。幸いなことに、後者はまた、カウンターパートを達成してきた、我々はコルドバ枠組みでCorHttpdマナーのhttpdウェブサーバをサポートできるようにする必要があります。プラグインの今更新を停止している、問題があるが、私が見る、コードを修正し、問題を修正する、元のプロジェクトでは、コンテンツのマージに基づいて要求を持っている、ロードされたSVGすることはできません。https://github.com/lsyer/cordova-httpd
したがって、全体のパッケージングプロセスが選択することができ、次のように使用コルドバは、特定のコードを達成CorHttpd。
$npm install -g cordova
$cordova create YoxvIoT
$cd YoxvIoT
$cordova platforms add android
$cordova plugin add https://github.com/lsyer/cordova-http.git
$mkdir www/htdocs //前端生成的UI放入该目录，是CorHttpd的服务器根目录
$touch www/index.html //使用CorHttpd建立http服务器，并使用全屏无边框的iframe显示UI，具体代码参考cordova-httpd项目中的test文件夹，在服务启动后将iframe的src重定向到UI界面
$touch www/loading.html //在CorHttpd完全启动之前的预载入界面，作为应用可用前的Splash
$cordova build android //编译生成App
実際には、アプリケーションの最後のステップは不可能ですが、プラットフォーム・プロジェクトのコルドバの完了は、このコマンドによって生成されたAndroidの、あなたがAndroidアプリプラットフォーム/で完全なプロジェクトを見ることができる、Androidのメーカーは、最後の最後にコンパイルを実行インポートすることができますリリースパッケージ。supportsRtl =「true」を、より8.0システムのAndroidをサポートするために：アプリケーションを生成したプロジェクトはまた、AndroidManifest.xmlをラベルにアンドロイドのアプリケーションに参加するために、権限を追加する必要がある、ということに注意してください。