2017-01-23 4 views
0

Meteorをサーバーとして使用し、Ionic2をクライアントとして使用したいと考えています。私は現在、認証と頭痛を持っています。Ionic2クライアント+流行の方が良いですか?

  1. 最初に、ionic-angularライブラリを持つMeteorサーバーとMeteorクライアントを使用しています。このアプローチは、私はこの方法の利点は、流星のネイティブなアーキテクチャを使用することであると思い、ここ

https://angular-meteor.com/tutorials/socially/angular2/ionic2

を説明し、一方で私たちはちょうどサブフレームワークのようなIonic2を使用して、おそらくからいくつかのものを失うことだと思いますネイティブイオニック2。

  1. 2つ目は別のMeteorサーバー(完全に削除された 'client'フォルダー)とネイティブIonic2を使用しています。このアプローチは、

https://angular-meteor.com/tutorials/whatsapp2/ionic/authentication

このオプションはその逆である、ここで説明:ネイティブIonic2の使用が、それは、私はよく分からない流星のネイティブである、などmeteor-client-sideaccounts-base-client-sideaccounts-password-client-sideのようなライブラリを使用する必要があります。

すぐに使用できるのは認証用のすぐ使えるUIコンポーネントがあるからです。しかし、さまざまなタイプのデバイスのアプリケーションを完成させる段階に来るとき、私はどんな問題があるのだろうかと思います。

ご協力いただきありがとうございます。

答えて

1

これらのアプローチは、認証自体にとって本質的に同じです。 あなたが指摘していることは、モバイルプロジェクトを開発して実行するために選択するモバイルプラットフォームについてです。

最初のケースでは、Meteorの組み込みCordovaプラットフォームを使用してアプリを開発し、Meteorのコンパイラとバンドラープラグイン(TypeScriptパッケージやBabelやUglifyJSなどのMeteorコアパッケージなど)を使用してアプリケーションを開発します。 2番目のケースでは、Ionic 2 CLIのみでアプリケーションを開発して実行します。

しかし、アプリケーションロジックの観点からは、これらのアプローチは全く同じです。同じIonic 2コンポーネントをインポートし、同じMeteorパッケージを使用するのは、これらのパッケージがNPMではないことです。これらのNPMはAtmosphereパッケージから構築されているため、同じスクリプトを含んでいます)。

What'sAppクローンが社会的なものと異なっている理由は、 のREADMEのWhat'sAppレポ(https://github.com/Urigo/Ionic2CLI-Meteor-WhatsAppを参照)に簡単に説明されています。繰り返す場合:Ionicはモバイルアプリの構築だけに特化した最高のWebフレームワークの1つで、Meteor自体よりも強力なものになっていると推測するのが妥当です。その観点から、第二のアプローチは将来的にはより確実であると私は言うだろう。将来的にある時点でMeteorを使用することに決めた場合、Meteorを他のフレームワークに簡単に置き換えることができるような方法でプロジェクトを構築することさえ考えることができます。

2番目のケースで言及したNPMを使用することに懸念がある場合(例えば、それらを構築するプロセスがあなたにとって透過的ではない場合)、このプロジェクトhttps://github.com/Urigo/meteor-client-bundlerを使用して、必要なAtmosphereパッケージをスクリプトを実行してから使用してください。

+0

ありがとうございます、それは非常に役立ちます!私は両方の方法を試してみます。私は2番目の方法は、私はアポロを使用して起動する場合は、サーバーとクライアントの関係から、このケースは週になるので、より一般的だと思う。リンクバンドラーに感謝し、私はそれを自分で見つけることはできません。 – Vladimir

関連する問題