モバイル開発アーキテクチャの詳細なガイドですが、決して決定的なガイドではありません

ネイティブ、Web、PWA、ハイブリッド、クロスコンパイル…AndroidおよびiOSプラットフォーム向けに開発する「最良の」方法は何ですか?合理的に見えるものは何ですか?そして、オプションの中からどのように選択することになっていますか?この記事では、十分な情報に基づいた意思決定ができ​​るようにすべてを説明します。

まず最初に、少しコンテキストを説明します。私はITのシニアコンサルタントであり、このガイドをまとめるというアイデアは、クライアントにとって最適なアプローチについてクライアントと話し合うことから生まれました。はい、彼らのためだけに。そして、正しい答えを出すのに役立つ明確に定義された戦略、堅実で信頼できる基盤がないことに気付きました。

そして、あなたは何を知っていますか?インターネット上のどこでも、このようなガイドを簡単に見つけることができませんでした。このトピックについてはいくつかの記事がありますが、私が出会ったものはどれも合理的に完成していません。残念ながら、大多数は多くの概念を見落としているか、さらに悪いことに、本質的に間違っています。

今、私はより広く見てみたいと思います。そして、私は誰かが自分で決断を下すのを潜在的に支援する一方で、このテーマについてのより多くの考えをコミュニティに尋ねています。

このガイドには2つの部分があります。

  1. モバイル開発アーキテクチャー層(これ)
  2. 決定方法

YouTubeでは、10本のビデオのシリーズとして、またUdemyの無料コースとしても利用できます。ここには、ここと同じ書面の資料、YouTubeシリーズの同じ動画、すべてのトピックを修正するクイズと最終認定があります。

それでは始めましょう。

前書き

モバイルプラットフォームに関しては、AndroidとiOSの2つの大きなプレーヤーしかないことは間違いありません。 Tizen、Blackberry、Windows Phoneなどの他のテクノロジーは、死んでいるか、しばらく使用されており、大きな市場シェアを獲得する見込みはありません。

この大規模な複占性を簡単に見てみると、モバイルアプリを作成する際に開発者には多くの選択肢がないと思われるかもしれません。しかし、この考えは真実から遠いことはできません。 C / C ++、Java、Kotlin、Objective-C、Swift、JavaScript、TypeScript、C#、Dart、Rubyなど、使用されている数多くのプログラミング言語をすぐに見つけることができます。もっと。

モバイル開発フレームワークでも同じことが言えます。あなたが開発者ではない場合、または過去10年間に何らかの形で新しいテクノロジーを知らなかった場合を除き、Cordova / PhoneGap、React Native、Xamarin、Ionic、Nativescript、またはFlutterについて聞いたことがあるでしょう。モバイルアプリ向けのプラットフォームソリューション。

それでは、これらのすべてのアーキテクチャを見て、少し分解してみましょう。

TL; DR

明確な勝者はありません。すべてのアプローチには長所と短所があり、次のプロジェクトに最適な場合と最悪な場合があります。このガイドでは、アーキテクチャがネイティブプラットフォームからどれだけ離れているかに応じて、さまざまなソリューションをさまざまな層に分類しています。

ネイティブアプリ

まず、金属に直行しましょう。最初のアーキテクチャ層はネイティブアプリです。

ネイティブアプリ層—特定のプラットフォームごとに開発する場所(NDKを検討する場合はさらに具体的かもしれません)

これは、各プラットフォームの特異性に注意する必要がある層です。それらを掘り下げることは私の意図ではなく、ちょっとした文脈でいくつかのことを述べたいだけです。

iOS

iOS側から始めて、単純だからといって、世界を支配しているのはAppleだけです。もともと、開発者は、SmallTalk(および非常に長い名前のAPI)からインスピレーションを得て、独自のオブジェクト指向CのバリエーションであるObjective-Cを学ぶ必要がありました。

2014年に、Appleはマルチパラダイム言語であるSwiftを発表しました。これは、以前のものよりもずっと簡単でした。 Objective-Cのレガシーコードを扱うことはまだ可能ですが、Swiftは高い成熟度レベルに達しました。したがって、iOS向けにネイティブに開発する方法を学習することを計画している場合、Swiftは間違いなくあなたが始めるべき場所です。

アンドロイド

Android側には、さまざまなメーカーがあります。それらの大半はARMプロセッサに依存しています。しかし、一般的に言えば、Androidアプリは潜在的な潜在的な特異性に対処するために仮想マシンインスタンス(ARTのインスタンス)に置かれます(多くの驚くべきトリックなしではありません)。

そのため、もともと、選択言語はJavaでした。これは、ほぼ20年にわたって世界で最も人気のある言語であった(Cとの位置の入れ替えがいくつかあった)だけでなく、そのJava仮想マシン(JVM)でも注目に値します。これにより、開発者は、JVMで読み取りおよび実行できる中間バイトコードにコードをコンパイルすることができました。

Android Native Development Kit(NDK)を使用すると、アプリの重要な部分をネイティブコードで直接開発し、C / C ++で記述することもできます。この場合、基盤となるプラットフォームの癖に注意する必要があります。

Kotlinは2011年にJetBrainsによって発表された言語です。柔軟性と簡潔さにもかかわらず、最初に登場したのは、Scala、Clojure、Groovyなどの競合他社が成功しているJVM言語に他なりませんでした。ただし、2016年の最初のメジャーリリースの後、特にGoogle I / O 2017でAndroidプラットフォームで公式にサポートされることをGoogleが発表した後、急速に群衆から目立ち始めました。

KotlinはGoogleの第一級言語になりつつあります(現在、KotlinとJavaは、この順序でAndroidの公式ドキュメント全体で使用されています)。米国連邦控訴裁判所が、GoogleがJavaの著作権を侵害しているとしてOracleが提起した無限の訴訟を裁定したため、Javaの完全な置き換えがさらに予想されます。

ネイティブコンポーネント

この層での開発では、すべてのネイティブAPI、特にネイティブコンポーネントも活用できます。これにより、アプリが車輪を再発明する必要がなくなります。

Xcode(iOS)とAndroid Studioで簡単なプロジェクトを作成する方法のビデオデモを公開しました。確認したい場合:

ネイティブアプリの利点

  • 最高のパフォーマンスとトップユーザーエンゲージメント
  • 最先端のネイティブ機能
  • かなり良いIDE Android Studio / Xcode
  • 最新の高レベル言語Kotlin / Swift
  • NDKを使用した非常に低レベルのアプローチ

ネイティブアプリの欠点

  • 維持する2つのコードベース
  • インストールが必要(Android Instant Appsを除く)
  • SEOの分析が難しい
  • ユーザーにアプリをダウンロードさせるのに非常に費用がかかる

Webアプリ

スペクトルの反対側には、Webアプリがあります。 Webアプリは、基本的にブラウザで実行されるアプリです。プラットフォームを対象とするコードを書くのではなく、その上で実行されるブラウザーを作成します。

Webアプリ層—明らかにAndroidとiOSの間に座っている獣をターゲットにしたブラウザバーの上にあります。

この層では、非常に多くの競合他社が互いの喉でジャンプしていることがわかります。しかし、それらはすべて同じ武器で構成される兵器、HTML、CSS、およびJavascriptを使用します。

Webフレームワークとライブラリは、LESSやSASSなどのCSSプリコンパイラ、TypeScript、CoffeeScript、FlowなどのJavascriptプリコンパイル言語、JSXやElmなどの共生を活用する場合でも、Babelのようなツールだけを使用してJavascriptに変換しますECMAScriptの年間仕様(ES6 / ES7 / ES8、またはES2015 / ES2016 / ES2017 / ES2018を希望する場合)に準拠する構成可能なレベル。

結局のところ、これらはすべて、ブラウザーによってレンダリングおよび実行されるHTML、CSS、およびJavaScriptです。カメラ、振動、バッテリーステータス、ファイルシステムなどのネイティブAPIに直接アクセスすることはできませんが、それらの一部はWeb APIを介して実現できます。

Webプラットフォームの機能に依存してアプリを構築できますか?

Web APIの大きな問題は、その成熟度です。それらの多くは、一部のブラウザーではサポートされていません。特にモバイルブラウザ間で実装に違いがあります。

Webアプリの利点

  • プラットフォームとデスクトップブラウザー間の共有コード
  • 以前のインストールは不要で、ナビゲートして使用するだけです
  • たくさんのフレームワークとライブラリー
  • SEOに最適

Webアプリの欠点

  • 低い性能
  • ネイティブユーザーエクスペリエンスを取得するのは難しい
  • インターネット接続が必要です
  • 公式アプリストアでは利用できません
  • APIはネイティブAPIほど成熟しておらず、信頼性も低い

フレームワークとWebコンポーネント

Angular、React、およびVueはおそらく2018年の時点で最も人気のあるWebフレームワークです。しかし、正確に言うと、Reactは柔軟性があり、意見が少ないという性質のため、単なるライブラリと見なされます。一方、Angularは、強く考えられたフレームワークです。 Vueはそれらの間のある時点で生きています。

角度対反応対Vue

元々はAngularJSと呼ばれていたAngularは、2010年にGoogleによって世界に発表されました。当時の他のライブラリ(当時最も人気のあったjQueryなど)と比較してパラダイムが逆転したため、すぐに輝き始めました。 HTMLエレメントと直接対話してUI状態を操作する代わりに、AngularJSを使用して、JavaScriptモデルが更新されるたびにテンプレートが魔法のように更新されました。

AngularJSの人気が高まるにつれて、AngularJSも目的が拡大しました。これは、SPA(Single Page Apps)を真剣に考えた最初の1つである、完全で意見のあるフレームワークに変わりました。この成長(両方の面)は、いくつかのAPIの膨張とパフォーマンスの問題の原因でした。

Reactは、プレゼンテーション層でのニーズを解決するためにFacebookによって作成されました。仮想DOM、一方向のデータフロー(元はFlux、特にReduxと呼ばれる実装ライブラリを介して人気があった)、JSXと呼ばれるHTMLとJavaScriptの混合など、突然非常に人気になった多くの側面を紹介しました。

長い議論と予想外の大きな変化の後、2016年になって初めて、Googleは人気のあるWebフレームワークのバージョン2をリリースしました。彼らはそれをAngularJSではなくAngularと呼んだ。しかし、多くの人々がすでに最初のバージョンを「Angular」(接尾辞「JS」なし)と呼んでいたため、人々は新しいバージョンAngular 2の呼び出しを開始しました。 6ヶ月。

私の意見では、それは巨大な間違いでした。これは以前に見たことがあります(たとえば、Struts vs Struts 2 / WebWorkで)。彼らは非常に人気のある製品を持っているが、それはプラトーに達したように見え、賞賛されるよりも批判されるようになった。 Googleがゼロから再構築することを決定した場合、決してメジャーバージョンを変更しないでください。新しいメジャーバージョンのリリースごとに繰り返さないことを人々はどのように信頼しますか?バージョン2は、重大な変更を提示することになっていますが、完全に刷新できるわけではありません。

Angularは素晴らしいWebフレームワークであり、私はそれに対して情熱を感じています。しかし、それは完全に新しい獣です。 AngularJSとはあまり関係ありません。別の素晴らしいフレームワークであるVue(おそらく、最も使いやすいフレームワークの1つ)でさえ、AngularJSに鳥瞰的に似ています。これはAngularからの大きな動きを引き起こし、Reactの人気に大きく貢献したと思います。

Vueは、3つの最も人気のあるWebフレームワークのうち、大企業に支えられていない唯一のフレームワークです。実際には、元のGoogle開発者によって開始されました。その手ごわいシンプルさと小さな設置面積により、大規模で熱狂的なコミュニティから注目されました。

より完全なソリューションはありますが、それらはすべてWebコンポーネントの概念の上で機能します。 W3Cで現在進行中のそれらについてのオープンな仕様があり、Polymer、Stencil、X-Tagなどの興味深い実装があります。

シリーズの3番目のビデオでは、フレームワークについてあまり時間をかけずに、Webコンポーネントライブラリについて説明します。

モバイルアプリとWebアプリ

気づいたかどうかはわかりませんが、ここで紹介するティアの順序は、すべてのアプローチを学ぶための最も簡単な方法だと思います。最も純粋なモバイル開発であるネイティブ層から始めました。次に、他の極端な場所に直接飛んで、最初のスマートフォン以来利用可能な層であるWeb層を提示することにしました。

ダイアグラムの2つのエッジの比較について詳しく説明した後、モバイルアプリを構築するためのクロスプラットフォームアプローチの多くについて話を始めましょう。

モバイルアプリとWebアプリの間には長い議論があります。モバイルアプリについて私が言うことはすべて、ネイティブ層だけに限ったことではありません。また、後で説明するすべてのクロスプラットフォーム層にも適用できます。

ユーザー行動のジレンマ

ユーザーは、モバイルWebサイト(13%)よりもモバイルアプリ(87%)により多くの時間を費やします

2017年のComscoreの調査によると、モバイルアプリに対するユーザーの忠実度は、モバイルWebサイトよりもはるかに関連性があります。 Forbesの提携記事によると、これは通常、利便性(たとえば、ホーム画面ボタン、ウィジェット、トップ通知)、速度(たとえば、よりスムーズなインターフェイス、ほとんど瞬時に起動)、および保存された設定(たとえば、オフライン)によるものですコンテンツ)。

モバイルWebサイトはより多くの人々にリーチします(330万のモバイルアプリに対して毎月890万のユニークビジター)

一方、同じComscoreデータでは、少数の好みのアプリにあまり縛られていないため、モバイルWebサイトからより簡単にアクセスできることがわかります。最も人気のあるWebサイトと最もダウンロードされたアプリを比較すると、1か月あたり平均890万のユニークWebビジターが上位1000のWebサイトにアクセスしていると推定されます。これは、最もダウンロードされた上位1000のアプリの平均ユニークユーザーのほぼ3倍です。

配信(Webアプリ)xエンゲージメント(モバイルアプリ)

それは、配布とエンゲージメントのすべてです。ユーザーはモバイルブラウザーを操作するときに新しいことを試す可能性が高いため、Webアプリにアクセスする可能性が高くなります。しかし、モバイルアプリはより魅力的であることが実証されており、はるかに長い期間にわたってユーザーの注目を集めています。

ジレンマを理解したので、Progressive Web Appsを見てみましょう。これはWeb Apps層に関連付けられているアプローチなので、Web Appsの単なる補足として分類します。しかし、それは大きな混乱を招くものであり、ウェブおよびモバイル開発における最も顕著な新しくクールなものの真剣な候補です。

プログレッシブWebアプリ

プログレッシブWebアプリ(PWA)は、Webアプリユーザーがモバイルアプリを実行するときに慣れているのと同じエクスペリエンスを提供するために使用されるツールのセットです。これは、Web Appsがより適切なエンゲージメントで潜在的に高いレベルの配信を活用できることを意味します。

Web Apps層へのプログレッシブWebアプリの補遺

Googleは、PWAの3つの主要な資格を定義しました。それらは、信頼性、高速性、魅力的なものでなければなりません。

Service WorkerおよびApp Shellと呼ばれる機能は、プログレッシブWebアプリの基盤です。デバイスの接続状態に関係なく機能するように設計されたため、アプリの信頼性を促進するために作成されました。これには、オフラインモードと接続不良が含まれます。また、ローカルにキャッシュされたデータを使用してアプリを起動すると、コンテンツの同期ダウンロードの遅延がなくなり、パフォーマンスが大幅に向上します。

信頼性は、エンゲージメントの間接的なベクトルと考えることができます。たとえば、電車で通勤中のユーザーは影響を受けません。彼らは関与し続けることができます。

同じことが速度にも当てはまります。 Googleによると:

ロードに3秒以上かかる場合、53%のユーザーがサイトを放棄します。

ただし、もっぱら信頼性が高く、ロード時に高速であっても、必ずしも高いエンゲージメントが保証されるわけではありません。 PWAは、「ホーム画面に追加」オプションやプッシュ通知など、モバイルアプリ専用のモバイル関連機能を活用します。

「ホーム画面に追加」機能に関しては、Appleが最初のiPhone以来同様の機能を備えていることに気付くかもしれません。一部の人々は、プログレッシブWebアプリは、Appleのオリジナルのアイデアに対するGoogleの新しい名前だとさえ主張しています。

そして、あなたは本当に完全に反対することはできません。いくつかのアイデアは実際にサイクリングしています。彼らは来て、去って、新しい名前といくつかの機能拡張(たとえば、サービスワーカー)で戻ってきます。

一方、完全に同意することは困難です。 Web 2.0 + AJAXについてのSteve JobsのスピーチとWWDC 2007でのiPhoneの記憶に残る発表は、彼をPWAの父親、さらには予言者と呼ぶほど説得力がありません。

公平を期すために、iPhoneのホーム画面に追加機能は、フルスクリーンモードでWebアプリを起動するデスクトップアイコンを生成するための微妙な、ほとんど隠された機能に過ぎません。 HTTPリクエスト/レスポンスサイクルのすべての負荷があり、キャッシュの周りに明確なパスがありません。

PWAは正しいポイントから始まります。彼らは、モバイルアプリのクライアント側のブートストラップを失うことなく、Webアプリの以前のインストールが必要でないことを探ります。つまり、起動後の最初の対話にユーザーが必要とするすべてのものはローカルにキャッシュされ(「App Shell」と読みます)、「ホーム画面に追加」を押すとすぐに利用可能になります。

PWAのもう1つの有名な特性に移り、モバイルアプリの世界の非常に魅力的な(または再関与する)機能であるプッシュ通知について説明しましょう。これらは、ロック画面だけでなく、上部の通知バー/エリアに表示されるアラートスタイルのメッセージです。通知を受け取ったユーザーをアプリに引き戻す力があります。

PWAの魅力を強化するために、Googleはすべての最新のWeb APIをPWAの傘下に置いています。したがって、プログレッシブWebアプリのコンテキストで、支払い要求、資格情報管理、WebVR、センサー、WebAssembly、およびWebRTCなどが表示されることを期待してください。ただし、これらの機能は必ずしもPWAに関連付けられているわけではなく、PWAという用語が造られる前に生まれたものもありました。

PWAおよびApple

一方、Appleは2018年3月に初めてPWAに向けた最初の堅実なマイルストーンを発表しました。まだいくつかの制限がありますが、進展はかなりのものです。一部の制限は、Safariが競合他社より遅れているという事実に関連している可能性があります。他のものは、Appleの厳格な管理哲学に起因する可能性があります。

それでも、AppleはGoogleよりも収益性の高いApp Storeを持っています。 Appleは、アプリの公開に関する基準が増えると全体的な信頼性が高まり、PWAがApp Storeの収益を損なうことになると主張しています。これは、意図的に課せられていると思われるいくつかの制限(50 MBのPWA最大キャッシュサイズなど)を取り消すにはさらに費用がかかることを示唆しています。

残念ながら、PWAは完璧ではありません

Webソリューションと、さまざまなレベルでは、すべてのクロスプラットフォームソリューションは、ネイティブアプリの卓越性と包括性を達成するのに苦労しています。すべての新機能、およびAndroidまたはiOSに固有のすべての詳細により、ネイティブ層からアプリを遠ざけるにつれて、ネイティブはアクセスしにくくなります。

全体として、PWAはWeb Apps層のいくつかの問題を修正します。ただし、ブラウザ上で動作するソリューションでは解決できない他の問題があります。

PWAが修正するもの

  • より「ネイティブ」な体験
  • より速いロード時間
  • インターネット接続は必要ありません
  • Web開発者に、接続も接続不良も存在しない状況を認識させる
  • プッシュ通知、ジオロケーション、音声認識などのモバイルアプリの機能を組み込みます

彼らがしないこと

  • 固有の遅さ
  • アプリストアでは利用できません(まだ)
  • まだすべてのブラウザで完全にサポートされているわけではありません
  • NFC、アンビエントライト、ジオフェンシングなどのモバイル機能がまだありません
  • また、PiP、スマートアプリバナー、起動画面ウィジェット、3DタッチなどのAndroidまたはiOSの特性のサポートが不足しています

以下のビデオでは、PWAの簡単な概要を説明します。

ハイブリッドアプリ

このレベルで、モバイルアプリの世界に飛び込み始めます。最も遠い層であるハイブリッドアプリから始めます。

ハイブリッドという用語は、一般的にすべてのクロスプラットフォームソリューションにも適用されます。ただし、ここでは、WebViewと呼ばれるモバイルコンポーネント内で動作するアプリに制限しています。

ハイブリッドアプリ層。ブラウザの行の下、ただしWebViewの上

2番目のビデオのデモで、Hello Worldの例としてWebViewを追加する目的は、各プラットフォームに実際のブラウザのように実行できるネイティブコンポーネントがあることを明確にすることでした。

Cordova / PhoneGap

Cordova / PhoneGapのようなソリューションは、Webアプリとモバイルアプリの間のギャップを埋めます(ひらめきにごめんなさい)。開発者のHTML、JavaScript、CSSコード(および画像やビデオなどの追加アセット)をパッケージ化し、それらをモバイルアプリ(はい、実際のAndroidまたはiOSアプリ)に変換するツールを提供します。これらのアプリは、アプリのメインフォルダー(通常は「www」と呼ばれます)の「index.html」ファイルから開始して、元のWebコードを解釈して実行するためのWebViewのみを備えています。また、JavaScriptで部分的にネイティブ言語で部分的に実装されているプラ​​グインを介して、JavaScriptコードをネイティブAPIにブリッジします。

それでは、物事をより明確にしましょう。ハイブリッドアプリは(Web APIの代わりに)ネイティブAPIにアクセスできますが、WebViewに囲まれています。 Cordovaのボタンは、モバイルネイティブボタンではなく、WebViewによってレンダリングされるHTMLボタンでなければなりません。

これは、企業がWebアプリをモバイルアプリに移植して、アプリストアから出荷できるようにする魔法の層です。したがって、ここではすべてのWebフレームワークが許可されます。

イオン性

IonicのようなフレームワークはCordovaを独自のソリューションにラップします。 Ionicでは、すべてのコマンドがIonic CLIによってラップされているため、Cordovaのコマンドラインインターフェイス(CLI)を使用する必要はありません。

最近、Ionicチームは、ハイブリッドアプリのスタック全体を管理することにしました。そこで彼らは、コンデンサと呼ばれるコルドバの代替案を発表しました。コンデンサはCordovaプラグインをサポートしており、Ionic以外のプロジェクトでも使用できます。

シリーズの5番目のビデオでCordova Hello Worldのサンプルをご覧ください。

ハイブリッドアプリの利点

  • 基本的には公式アプリストアに発送可能なウェブアプリです
  • JavaScriptフレームワーク/ライブラリと一緒に使用できます
  • コードはまだプラットフォーム間で高度に共有可能です
  • ネイティブ機能(カメラ、加速度計、連絡先リストなど)へのアクセス

ハイブリッドアプリの欠点

  • Webビューはすべてを画面に表示するため、パフォーマンスの問題とメモリ消費に苦労します。
  • 単一のWebビューの上にすべてのネイティブUIコンポーネントを模倣する必要がある
  • App Storeで受け入れられて公開されるのが難しい
  • 通常、これらの環境でネイティブ機能を利用できるようになるには時間がかかります

Web Native

Web Nativeは比較的新しく、多くの場合誤解されている層です。 Webアプリがネイティブコンポーネントと出会う場所です。 Appcelerator(Axway)Titaniumは長い間使用されてきましたが、これを完全に独立したモバイルアプリのカテゴリにすることを正当化する比較的新しい競合他社がいくつかあります。

Web Native Appsは他のネイティブコンポーネントと直接通信するため、WebViewを必要としません

上記のように、アプリケーションをレンダリングして実行するためのWebビューはありません。では、JavaScriptはどのように実行されますか?コンパイルされていますか?さて、コンパイル(TypeScriptからJavaScriptなど、ある言語から別の言語へのコンパイル)、バンドル、縮小、マングリング、難読化をまとめてコンパイルすることを考慮すると、JavaScriptがコンパイルされます。

しかし、問題は、これによってJavaScriptがAndroidまたはiOSのオペレーティングシステムによって直接理解されるようにならないことです。そして、理論的には、HTMLレイアウトエンジンの肥大化なしにJavaScriptエンジンとしてのみ機能するネイティブコンポーネントはありません。

戦略は、コードとともにJavaScriptエンジン(通常はAndroidの場合はV8、iOSの場合はJavaScriptCore)を出荷することです。フットプリントが小さく、非常に高速ですが、アプリによって提供される必要がある外部のものです。

一方、このアプローチは、すべてのコンポーネントがネイティブアプリで使用されるものと同じである(たとえば、React Nativeの同じものに基づいている)ため、UIパフォーマンスが向上する傾向があります。

Web Native Appsの利点

  • 単一のコードベースで両方のプラットフォームに到達
  • ネイティブUIコンポーネントも処理するため、ネイティブアプリとほぼ同じパフォーマンス
  • 微調整が必​​要ですが、コードはまだWeb開発と共有可能です

Web Native Appsの欠点

  • 単一のコードベースでも、開発者はネイティブコンポーネントに注意する必要があります
  • Web開発者にとって、特にレイアウトに関しては、ハイブリッド/ Webアプリよりも学習曲線が急勾配です

React Native

シリーズのパート6では、React Nativeで簡単なHello Worldを実行します。これは、Android Studioのレイアウトインスペクターで、エミュレーターでレンダリングされたコンポーネントを示します。前の例と比較して、WebViewがまったくないことを確認します。

ネイティブスクリプト

過去2年間特に興味を持っていたもう1つのすばらしいフレームワーク(Udemyに関するコースをポルトガル語で持っています)は、Nativescriptです。 React Nativeに似ていますが、Reactの世界とは関係ありません(ただし、Nativescript-Preactの非公式な統合があります)。

Nativescriptを使用すると、バニラJavaScript、TypeScript、Angular、さらに最近ではVueを使用して開発できます。もちろん、他のフレームワークも使用できますが、それらは公式にサポートされているものです。ちなみに、それもかなりよく文書化されています。

Nativescriptには、Nativescript SidekickやNativescript Playgroundなどのツールのほか、コミュニティが提供できるテンプレートに基づいたプロジェクト構造があります。これは、プロジェクトの作成に役立ち、Macを使用して開発していない場合でも、クラウドおよびiPhoneデバイス上のシミュレーターで開始、展開、テスト、および実行することができます。

シリーズの第7回では、Sidekickを使用してHello Worldを行い、CLIから開始した別のプロジェクトと、学習用に作成したWhatsAppクローンテンプレートを使用します。

アプリがAndroidエミュレーターで実行されている場合は、レイアウトインスペクターを確認することが重要です。 Nativescriptを使用すると、ネイティブコンポーネント(WebViewなし)、およびTextViewなどの一般的なAndroidクラスの直接インスタンスが表示されます。これは、ネイティブコンポーネントをラップする独自のクラスを持つReact Nativeとは異なります。

だからこそ、Nativescriptは、iOSとAndroidで新機能が利用可能になってから、Nativescriptプロジェクトで使用できるようになるまでに遅延はないと主張しています。たとえば、彼らは自分のブログに、iOS 11が新しいARKit APIで公式にリリースされた同じ日にARプロジェクトを投稿しました。

Weex

このカテゴリで言及する価値のあるもう1つのフレームワークはWeexです。これはAlibabaによって開発されたプロジェクトであり、現在Apache Sofware Foundation(ASF)でインキュベーションされています。代わりに