React Nativeはプログラマーの夢、つまりWeb、Android、iOSの単一コードを実現しますか？

コードを書くのは難しいです。 複数のプラットフォーム用のコードを書くことはさらに困難です。 プログラマーはこれを知っており、過去20年にわたり、「万能の万能者」のアイデアは心を刺激し、さまざまなテクノロジーで具体化されてきました。 Javaから電話のギャップまで、開発者は本当に一度書くだけでどこでも仕事をしたかったのです。 しかし、うまくいきませんでした。

そして、facebookはReactJSを作りました。 自分でチャットを修正します。 そしてそれは起こった。 javascriptの「キューブ」からインターフェイスを構築するというアイデアは非常に優れていることが判明したため、facebookはフレームワークをモバイルプラットフォームに移植し、最初にiOS用のReact Nativeを作成し、6か月後にAndroidを作成しました。 Webから生まれたテクノロジーは、Javaや.NETなどのモンスターが失敗したことを実行できますか？

夢が叶う：一度書いて、どこでも走る

クロスプラットフォーム開発が最近一般的になりました。 15年前、「プログラム」という言葉は「Windows用のプログラム」と同義語でした。 ほとんどのコンピューターはWindows上で動作していました。 エンタープライズソリューションの平行した世界では、HP-UX（よりよく知られているchpux）、サーバーLinux、およびJavaが生きていました。 別の平行した世界で-フォトショップとイラストレーターとマコス。 世界は交差せず、プログラムは特定のプラットフォーム用に作成され、クロスプラットフォームソリューションは必要以上に好奇心が強いものでした。

そして、いくつかのことが起こりました。 彼らはモバイルプラットフォームを「撃ち」、ポピーの人気が高まり、ソフトウェアの購入とレンタルが大幅に簡素化されました。 プログラムは、コンピューターエンジニアだけでなく、全員が使用するようになりました。 そして突然、長年のJavaスローガン「一度書くだけでどこでも実行する」が非常に重要になったことが判明しました。 銀行からスターバックまで、膨大な数の企業がアプリケーションを必要としていました。 望ましい-すぐにすべての関連プラットフォームに。 安くて非常に望ましい。 そして、もし今なら。

設計ガイドと実行速度があなたの夢を妨げます

開発者は実績のあるツールからほこりを払い落としましたが、すべてがそれほど単純ではないことが判明しました。 モバイルプラットフォームで利用可能なクロスプラットフォーム開発技術の大部分は、ユーザーインターフェイス自体を描画します。 なぜ、最初に、彼は外国人に見えるのでしょうか。 そして、第二に、速度が低下します。 これに「流れるような抽象化」を追加してください。遅かれ早かれ、複雑なアプリケーションはクロスプラットフォームフレームワークのフレームワークを超え、その「ネイティブ」コードで拡張する必要があり、拡張機能とフレームワーク自体の相互作用の問題につながることがよくあります。

この問題を解決するために設計されたフレームワークとライブラリは、お金の雨の後、キノコのように増え始めました：Appcelerator、Phonegap、Xamarin、FireMonkey、NativeScript。 しかし、誰も特別な人気を獲得することはなく、インターネット上の記事は「 フレームワークの名のもとにクライアントバンクを作り始め、1年後にそれを捨ててネイティブに切り替えました」などのインターネット上の記事が現れ始めました。

ReactはレスポンシブなWeb-to-Mobileデザインをもたらします

そして、ここで、2015年半ばに、FacebookはReact Nativeを導入しました。 一見、新しいものはありません。 JavaScript。iOSおよびAndroidの両方で「ネイティブ」ユーザーインターフェイス要素を作成できます。 Appceleratorはこれを長年にわたって使用しています。

悪魔は細部に隠れていました。 「キューブから」インターフェースのアセンブリと、ウェブから借用した「適応」設計アプローチにより、興味深いことが可能になりました。 Reactを使用すると、Webの場合と同様に、インターフェイスが意味的に強制されます。 iOSまたはAndroidのインターフェイス要素で操作する代わりに、デザイナーは論理コンポーネント（「画面」、「タイトル」、「リスト」、「ボタン」）からインターフェイスを作成します。 そして、すでにコンパイルされたインターフェースはファイルで特定のプラットフォームにもたらされます：数行のコードは「進行」コンポーネントをウェブ用のHTMLタグのセット、Android用のProgressBarAndroidおよびios用のProgressViewIOSに変換します。

このアプローチは非常に便利です。最初は、インターフェイスはすぐにユニバーサルブロックで構成され、その後、実際に必要な場合にのみ各プラットフォームで確定されます。 これは、ユニバーサル「ゴム」インターフェースが最初に課され、次に@mediaの助けを借りて、電話画面、タブレット画面、および大画面用に確定されるアダプティブレイアウトを思い起こさせます。

アプリケーションのプロトタイプは数日で完成します

例として、React Native SDKのテストアプリケーションを見てみましょう。 SDKを使用すると、無料のピアツーピアを含む通常の通話またはビデオ通話を送受信できます。 そして、アプリケーションはそれを使用する方法を示します：ログインウィンドウ、番号または名前を入力するためのウィンドウ、「コール」タイプのボタンの散在、「ビデオをオンにする」、「マイクをオフにする」など。 ソースを見ると、両方のプラットフォームで動作する1つのコードが表示されます。 コードは、私たちが望んでいた場所でのみ異なります。 たとえば、スイッチのネイティブバージョンが使用されるため、その実装はColorSwitch.ios.jsとColorSwitch.android.jsの 2つのファイルに分割されます。

デモアプリケーションは2日で作成されました。 iOSとAndroidのすぐ下。 また、Web用のバージョンを作成する場合は、さらに1日かかります（はい、web SDKがあり、はい、webRTCの魔法のおかげでブラウザーから呼び出すことができます）。 ユーザーインターフェイス要素をdivに置き換え、Webバージョンとモバイルバージョンで異なるSDK呼び出しを変更するだけです。

<View style={styles.settings_table}> <View style={styles.settings_switch}> <Text style={styles.settings_label}>Peer-to-peer</Text> <ColorSwitch defaultValue={settings_p2p} valueUpdate={(value) => {settings_p2p = value}}/> </View> <View style={styles.settings_switch}> <Text style={styles.settings_label}>Video</Text> <ColorSwitch defaultValue={settings_video} valueUpdate={(e) => this.videoSwitch(e)}/> </View> </View> 

ここからコードスニペット

実際にはすべてがとてもスムーズですか？

毎月、ますます多くの企業がReactJSとReact Nativeを使用しています。 ただし、この技術はまだ非常に新しく（Androidバージョンは数か月前のものです）、すべての「小児疾患」が含まれています。

まず、 「箱から出してすぐに」利用できる少数のインターフェース要素に注目したいと思います 。 iosとandroidには、1半ダースのユニバーサルと10の特定があります。 ネイティブ要素は簡単にラップできますが、これにはjava、objective-c、またはswiftの知識が必要です。 別の方法は、GitHubで利用可能な何百もの愛好家が作成したアイテムの1つを使用することです。 しかし、オープンソースは特定のものです-不注意に書かれた要素には、自分で行う場合よりも多くの問題がある場合があります。

技術の若さも利用可能なライブラリとバインダーの選択を制限します。 React Nativeの発表の時点で、iosとandroidのネイティブSDKが長い間ありました。 これを使用して、すぐに移植を開始し、webRTCをReact Nativeで初めてパックしました。 しかし、それでもかなり時間がかかりました。ドキュメントを勉強している間、コードを書いている間、すべてをテストしている間、継続的インテグレーションを設定している間-深刻なライブラリの場合、これは1か月以上の質問になります。

また、フレームワークの開発速度が開発者の手に渡るとは限りません。 最新バージョンに更新すると、ログのエラーだけでなく、警告も表示されずに、ビデオの再生が突然停止しました。 コードを長時間掘り下げたところ、作者がAndroid用のReactPropを「ちょうど」別の場所に移動したことがわかりました。 もちろん、このような変更は頻繁に発生するわけではありませんが、特にAndroidバージョンでは依然として発生します。

 import com.facebook.react.uimanager.*; import com.facebook.react.uimanager.annotations.ReactProp; public class VoxImplantViewManager extends SimpleViewManager<VoxImplantRendererView> 

結論

この技術は非常に有望ですが、若いです。 直接の競合他社の中で、マイクロソフトの「windows universal apps」という名前を付けることができます。インターフェイスのセマンティックレイアウトという概念は、最近連続技術によって強化されました。 「Xamarin.Forms」は、「ユニバーサル」および「プラットフォーム固有の」インターフェース要素を備えた同様のソリューションを提供します。 しかし、Reactにはいくつかの利点があります。プラットフォームの1つとしてのWeb、非常に人気のあるJavaScript、それほど人気のないnode.jsツールチェーン、無料、Facebookのサポート、追加設定なしの「ホットリロード」です。

React Nativeを使用して、Webアプリケーションのモバイルバージョンをすばやくプロトタイプ化できるようになったと言えます。 さらに、Webアプリケーションが既にReactJSで記述されている場合、転送速度は大幅に向上します。 店舗での出版を伴う複雑なアプリケーションの作成はすでに可能であり、ギャラリーで明確に見ることができます 。 しかし、最終的な「頭に浮かぶ」が引きずり出されて、javaとobjective-cに登る必要があるという事実に備えてください。

PSそして、彼らは彼ら自身のためにチャットを決して修理しませんでした。 しかし、そこには、キャンペーン、そして実際に場所が呪われています。