使用React、React Native和Firebase在2020年快速建構應用程式
使用現代跨平台技術，例如 React、React Native 和 Firebase 開發人員現在能夠比以往更快地構建複雜的移動應用程序和網站。
作為一家機構，我們正在為初創企業推出 MVP iOS 和 Android 應用程序；並在幾周而不是幾個月內為設計合作夥伴和 SaaS 客戶提供快速的產品創新。
自 2008 年 Apple 首次推出 App Store 以來，在構建應用程序方面發生了很大變化 - 從那時起我就一直參與應用程序構建遊戲，所以你必須相信我的話！
我在 Tenten 領導移動應用程序開發中心。我們專門從事 React 和 React Native 前端開發。過去構建的應用程序只能在 Apple 設備上使用 Objective-C 和 Swift 進行原生編碼。當 App Store 首次推出時，這是唯一的選擇。你必須選擇 - 蘋果或谷歌，或者如果你有很多錢和資源的話。
一次編寫，到處運行
Apple 鼓勵開發人員使用 Objective-C 或 Swift 編寫應用程序代碼。這些應用程序只能在 Apple 設備（iPhone 或 iPad）上運行。同樣，谷歌為開發人員提供了使用 Java 或 Kotlin 編寫代碼的工具，以僅發布 Android。但是還有第三種方法。我們現在可以選擇使用近年來發展和成熟的中間件技術編寫一次，隨處運行。領先的選項是：
- React Native（開源，最初由 Facebook 構建）
- Flutter（閉源，由谷歌構建）
- Xamarin（由微軟維護）
- Ionic（以前是 PhoneGap）
五年前，我和許多其他原生的單平台開發人員會爭辯說，在這些中間件框架中構建的應用程序不如構建原生的和純的。我們有一個觀點——中間件應用程序不會像本地應用程序那樣高效，即滾動和屏幕轉換會很緩慢，並且對用戶來說感覺不對。用戶界面的一般外觀和感覺永遠不會與原生 Android 或 iOS SDK UI 完全匹配。
###你為什麼要聽我的
但我的核心觀點是，我不僅僅是一名開發人員。我是創始人。我看到了業務方面以及代碼純度。作為一名僅限 iOS 的開發人員，我的聽眾總是僅限於 iPhone 用戶。幾年前，我決定切換到 React Native，這意味著我的應用程序也可以在 Android 手機上運行，但有一個主要的缺點——我必須重新訓練！這可能是阻止大多數有經驗的本地編碼人員切換的主要障礙。
但是，如果您是原生 iOS 或 Android 開發人員，並且想實現飛躍，我強烈建議您盡快這樣做！您在特定本機平台上的所有專業知識都不會浪費。這些中間件框架中_一個_的偉大之處在於，您還可以在共享 RN 框架代碼的同時編寫本機代碼。這就是為什麼 React Native 得到了我的投票，我繼續把我的職業生涯押在這匹馬上！
在 React Native 中重新訓練
React Native 是一個 JavaScript 移動應用程序開發庫，使開發人員能夠編寫一個代碼庫並部署到 iOS 和 Android 移動設備。
從商業角度來看，這是一個明智的選擇。您基本上是在將潛在市場擴大一倍，並減少開發成本和時間。
性能不再是反對使用中間件移動框架的有效理由。React Native 和替代品已經成熟，手機現在速度更快、功能更強大，現在幾乎不可能發現任何性能差異。編寫自定義 UI 代碼也非常容易 - 我發現 React Native 中的 flexbox 比 [自動佈局](https://developer.apple.com/ library/archive/documentation/UserExperience/Conceptual/AutolayoutPG/index.html) 在 iOS 中，因此，我可以比僅使用本機更快地敲定自定義用戶界面，當然我可以免費獲得 Android 應用程序（ish！ )
簡而言之，我選擇 React Native 的主要原因是：
1\。成熟
React Native 自 2014 年以來一直存在，並由活躍的社區和 Facebook 開發人員不斷改進和維護。
2\。基礎 - 它建立在 React 之上
React Native 依賴於 React。React 是最流行的 Web 應用程序開發框架。如果您要從原生移動開發轉向 React Native，我建議您首先掌握 React。了解應用程序狀態和用戶界面生命週期/渲染的工作原理是您首先需要了解的核心概念。或者，如果您是一名希望轉入 React Native 的 Web 開發人員，您可能已經掌握了 React for web 的樂趣。對我來說，首先學習 React 帶來了巨大的額外好處——我現在也可以超快地編寫 Web 應用程序！
3\。在本機代碼中混合
必要時，我可以將本機 iOS 或 Android 代碼添加到我的 React Native 應用程序中。例如，在某些情況下，由於前台 javascript 橋的限制，應用程序可能需要在 React Native 層中不容易工作的後台功能，因此我有時不得不編寫一個在 React Native 層中運行的本地模塊背景並在我的應用程序回到前台時將數據傳回主 React Native UI。
4\。發展速度
老實說，如果我今天被要求從頭開發一個 iOS-only 應用程序，我肯定會選擇 React Native 而不是原生 Swift！
我們如何快速構建應用程序
在技術上做出錯誤的選擇可能會非常昂貴並且對企業造成損害。有如此多的選擇，很容易在選擇中迷失方向。
儘管我們在 Tenten 是一個專注 DevOps 的開發團隊，但我們選擇通過 100% 專注於 React、React Native 和 Firebase 來微調我們的專業知識，它們的結合使我們能夠在步伐。
以下是我們使用這三種技術來快速開發出色應用程序的一些方法。
1\。React Native 中的單一代碼庫
維護多個代碼庫已成為過去。使用 React Native Cli，我們將創建一個新項目，該項目將在其中自動生成 ios 和 android 子項目。因此，從一開始，作為原生 iOS 開發人員，您會發現您可以直接從原生 iOS 模擬器中的 Xcode 或您選擇的模擬器中的 Android Studio 直接測試和運行您的新項目。來自原生背景，這對我來說比使用 React Native 的 Expo 選項更可取，我覺得後者更針對 Web 開發人員。
通過使用 React Native Cli 作為項目的起點，如果我需要深入研究本機代碼，我會保持開放的選擇。我們最近開發的六個應用程序幾乎需要編寫零本地自定義代碼。這是非常重要的一點——在我開始動手使用 React Native 之前，我聽說過有人需要編寫多達 30% 的額外條件代碼——也就是說，如果這是 Android 運行此代碼或 iPhone 運行此。我完全沒有發現這種情況——也許是因為我們在我們的應用程序中使用了最新、最穩定的 React Native 版本。另外，我認為我們在應用程序中使用的第 3 方 React Native 代碼庫做出了很好的選擇，它們通常會為您處理很多繁重的工作，並且很高興與您合作 - 這裡’
2\。JavaScript 的樂趣 - 一種語言可以統領一切！
如果您是 JavaScript 的新手並且已經熟練掌握 Swift、Java 或 Kotlin 等嚴格類型的語言，您會發現 JavaScript 的使用非常靈活——例如，您幾乎可以將任何舊的隨機屬性添加到 JavaScript 對象沒有得到任何編譯器錯誤😬 - 可怕！我們使用 TypeScript，它基本上是嚴格的 JavaScript，其中有接口和明確定義的屬性。您仍然可以向對象添加隨機的意外屬性，但是您方便的 TypeScript linter 將突出顯示任何狡猾的代碼問題 - 嗚呼！
我發現 JavaScript 是一種非常容易學習的語言。我在基於 JavaScript 的 Node.js 中編寫了很多服務器端代碼，所以沒花太長時間就學會了。我還強烈建議您查看 Dan Abramov 的 這個免費 JavaScript 課程 - 無論您是新手還是經驗豐富的 JavaScript 開發人員，他都是 React 背後的大腦之一。
通過在 JavaScript/TypeScript 方面對我們的團隊進行專業化和培訓，我們正在建立一支強大的開發人員隊伍，他們可以將他們的 JavaScript 技能應用到技術堆棧的所有領域：
- 使用 React 進行網站開發的 JavaScript
- 使用 React Native 為 iOS 和 Android 移動應用程序開發 JavaScript
- Node.js 中用於服務器端代碼的 JavaScript（通常創建 Firebase 雲函數）。
- 用於使用 Appium 編寫自動化測試的 JavaScript
3\。模板和可重用代碼
如果您想使用 TypeScript 開始一個全新的 React Native 項目，如此處突出顯示，您可以從一個最小的 React Native TypeScript 模板開始您的項目：
npx react-native init AwesomeTSProject --template react-native-template-typescript
但是你知道你可以構建自己的入門 React Native 模板嗎？那是強大的。它使我們能夠發展出一個很棒的內部起始模板，可以將其重複用於我們從事的幾乎所有新移動應用程序項目。有多少移動應用程序需要推送通知？有多少需要導航？閃屏？多語言支持？我們已經建立了自己很棒的起始模板，因此我們不會浪費時間為每個客戶一次又一次地編寫相同的核心功能。這是一個嚴重的節省時間。
4\。Firebase：後端即服務
大多數應用程序都需要某種遠程數據庫。他們可能需要這些應用程序的用戶能夠登錄、註冊、通過共享數據或消息傳遞相互通信。這些是一些需要“後端”服務器端應用程序的常見功能示例。
許多公司會選擇構建自己的自定義後端，並且需要聘請服務器端開發人員——通常會付出高昂的代價——來實現這一目標。除了構建自定義服務器端應用程序和 API 的費用之外，採用這種方式還可能存在很大的風險。
大多數科技企業家都會有關於他們的網站崩潰或數據庫被擦除的恐怖故事 - 哎喲！現在我並不是說 Firebase 100% 免受攻擊。但我建議谷歌的頂級開發人員花費多年時間開發一系列出色的服務器端工具，這些工具使 Firebase 成為可能，如果他們提出建議，他們可能會比任何自由職業者或外包機構做得更好編寫自定義後端！Firebase 於 2011 年推出，由 Google 擁有並積極維護。它是一套強大的服務器端工具，可以管理您的數據庫、應用程序和服務器之間的數據同步、推送通知、用戶身份驗證等等。
我們對一切都使用 Firebase。甚至主持。對於大多數客戶來說，這是完美的後端解決方案。一旦設置了客戶的 Google 帳戶，我們就可以構建他們夢想的應用程序和/或網站，並從他們自己的 Firebase 項目中為後端提供支持。我們可以訪問和開發項目，客戶可以完全訪問服務器端應用程序中的所有統計信息和數據。
Firebase 從免費套餐開始，這意味著我們可以構建您的網站或應用程序，該網站或應用程序具有免費託管和可擴展性，只有在它大受歡迎時您才會開始付費！
5\。自動化測試
測試是我們為客戶提供的一項重要服務: 自動化測試模仿應用程序或網站中的用戶流程。因此，例如，您可能有一個測試可以自動執行應用程序的全新用戶註冊新帳戶所需的步驟。使用 Appium 運行此測試將首先重置 iOS 或 Android 模擬器，清除所有緩存數據，然後創建應用程序的全新安裝。然後它將自動點擊按鈕或模擬用戶手勢導航到註冊屏幕，在註冊表單中輸入文本，點擊註冊按鈕，並等待成功創建新帳戶。如果任何步驟失敗，則測試失敗。我們可以將這些測試設置為在雲中自動運行，這在捕獲諸如破壞應用程序更新不向後兼容等問題時非常寶貴。
我們還編寫了我們自己的輕量級模擬服務器，該服務器自動設置為返回錯誤或模擬超時，以便測試團隊可以檢查開發人員是否涵蓋了所有基礎。
6\。AppCenter：在雲中構建和部署
我們工作流程中經常使用的另一個工具是 AppCenter。AppCenter 最初是 HockeyApp，並於 2014 年被 Microsoft 收購，是一款非常棒且價格合理的工具，我們在團隊中開發應用程序時使用它來自動構建和部署。
AppCenter 使我們能夠設置自動獨立的 iOS 和 Android 構建，並在開發過程中向客戶分發更新。它與 Github 和 Gitlab 完美集成，我們通常會設置暫存和迭代分支，以便在合併新功能時自動構建，發布代碼審查批准。
幾個案例研究
希望這能讓您對我們正在使用的技術有一點頂層的了解，但這裡有幾個客戶案例研究說明了其中一些技術已付諸實踐。
Teeth.app • 非接觸式牙科之旅
Kirei App 是我們的一位初創客戶的天才創意，他們正在努力實現牙科行業的現代化，並幫助牙科診所在目前正在適應 Covid-19 影響的新世界中恢復業務。
願景
我們的客戶 KireiCare 帶著構建應用程序來解決 2 個主要痛點的願景來到我們這裡：
- 使牙科診所能夠通過應用程序（如數字候診室）進行遠程和非接觸式管理預約和登記患者。
- 使患者能夠在附近的任何牙科診所搜索牙科預約。
MVP
我們以精益創業的心態處理了這份簡報，並為我們的客戶構建了一個 MVP（最小可行產品）應用程序。我們交付的應用程序實際上是五個應用程序合二為一：
- iOS 上的牙醫應用程序
- Android 上的牙醫應用程序
- iOS 上的患者應用程序
- Android 上的患者應用程序
- 後端儀表板 Web 應用程序。
預算非常緊張，起初，我認為我們無法按照他們的意願建造它們。但我們實現了不可能並交付：
- 設計和發現的迭代
*所有應用程序的屏幕設計 - 所有 5 個 MVP 應用程序的開發
技術
- React Native - 一個代碼庫有四個目標（應用程序）
- Firebase - 身份驗證、推送通知、實踐和約會數據庫、託管和雲功能。
快樂的客戶，快樂的團隊
與大多數企業一樣，成功的數字代理商將是讓客戶滿意並跟踪客戶滿意度的代理商。這些機構將贏得經常性工作並發展壯大，從那些滿意的客戶的推薦中獲得新客戶。容易吧？！
我們會在短短一到兩週的迭代中為我們的客戶提供定期的應用程序構建更新。在每次迭代開始時，我們使用敏捷過程來計劃和估計我們打算在該迭代中交付的工作。這對我們的客戶來說是完全透明的。在每次迭代之後，我們都會跟進滿意度反饋客戶調查。
這不僅讓我們始終保持客戶滿意度之上，還有一個額外的好處，即整個團隊都會為超級滿意的客戶獲得經濟獎勵。
如果您想成為我們的客戶，請聯繫我們。