使用 React Native 與 Amazon Cognito 實作 Google & Facebook 登入的功能

Standard

最近開始接觸 React Native 的專案了,能用前端技術跟知識同時開發 iOS/Android App 滿新奇的!雖然缺乏原生 App 的知識讓我踩了不少坑,其中不少還是非常低能的坑 XD!

這次實作的任務是要在 App 加上 Google/Facebook 登入的功能,而會員系統是建構在 Amazon Cognito 上面的,再加上 React Native 的相關套件 – react-native-facebook-loginreact-native-google-signin 來實作 App 中的登入功能。其中有些設定上的眉角讓我花了不少時間嘗試,所以整理成本篇的筆記備忘囉~


本文大綱

本篇文章滿長的,所以先整理大綱在此,了解一下會介紹到的部份:

  • 本文的套件版本
  • AWS SDK React Native 與 Amazon Cognito
  • react-native-facebook-login
  • react-native-google-signin
  • 繼續未完的 Amazon Cognito 設定
  • 前端程式
  • 疑難排解
  • 用 Amazon Lambda 來做 Serverless API
  • Amazon API Gateway
  • 在 App 端補上註冊(register)的 function
  • Source Code
  • 參考資料

繼續閱讀…

淺談使用 Appium 進行 React Native 雙平台(iOS & Android)App 的 E2E 自動化測試

Standard

前言

先前在公司的產品流程中導入了單元測試的部份,而最近手上的任務是為 App 產品導入 E2E 測試(End-to-End Test)。由於目前的公司團隊沒有 QA 人員,因此每次產品新版 release 前都必須仰賴工程師自己與產品 Owner 等成員自行手動測試(Manual Testing),隨著產品功能越來越龐大,這個過程越來越曠日費時,也無法確保每次都能測到所有的項目,因此才會有導入 E2E 測試的想法。

本篇文章視角是給像我一樣的非 App 工程師(例如從沒接觸過原生 App 開發、準備踏入 React Native 開發的前端工程師)的經驗分享,又因公司 App 產品是用 React Native 寫的,所以也會提到一些 React Native 在搭配 Appium 測試時需要注意的一些部分(一點點啦)。這也是我首次嘗試 E2E 的測試,著墨不深,有不精確或誤導之處,一樣請偷偷告訴我以便修正文章囉 :)

自動化測試中的 E2E 測試與比重

自動化測試(Unit test、Integration Test、E2E Test)能為產品的品質帶來更多信心,E2E 測試更是貼近真實使用者的情境下進行整體性的操作測試,「專注在真實使用者情境」--嗯,聽起來 E2E 是很值得投資的事情!不過 Google Testing Blog 曾在 2015 年的 Just Say No to More End-to-End Tests 中提出一些不同的思路。

繼續閱讀…

關於 AppLinks 兩三事

Standard

App Links

前言

在行動裝置時代,使用者更常停留在 App 中瀏覽資訊(像是 Facebook),而相對地在 Web 的停留時間就降低了。過去我們在 Web 上透過超連結搭起不同網站之間的橋,而在 App 與 App 之間又如何做到這件事呢?

當然,我們可以透過 URL Scheme 開啟應用程式,但我們並無法得知世上每個 App 的 URL Scheme,甚至是應用程式某個頁面 Deep Link 的 Scheme,而且萬一哪天增修了那又該如何?

我最近一部分的工作就在研究如何加強 App 於 Mobile Web 上的連結體驗,其實各大廠早提出了自己的構想及標準,例如 Google 提出的 App Indexing,以及 Facebook 提出的 App Links。

今天就 App Links 的部份做個簡單筆記與實作參考。App Indexing 等下次有空再寫文介紹囉。

繼續閱讀…

[Web][JavaScript] 有安裝 App 便開啟 App (透過 App URL scheme),若無則導去下載 (Google Play/App Store) 的 workaround

Standard

前言

製作案件上遇到的需求,若使用者有安裝 App 便開啟 App (透過 App URL scheme),若無則導去下載 (Google Play/App Store)。

在 App 內這件事應該是可掌控的(在自己做的 App 中攔截特定網址做處理),但在網頁上要做到這件事就有點麻煩了。一般常見的作法是擺個 Smart Banner,不過只有 iOS Safari 原生就支援,其他的得靠 jQuery Smart Banner(前陣子我也貢獻了修正 Windows Phone 相關錯誤的 pull request :P) 這類的第三方 plugin。

但 Smart Banner 和案件的需求還是有些差異,得靠其他方法解決,在實作的過程中遇到一些小問題與相應的 workaround,特此記錄。

實測環境

跟公司 QA 部門借了幾台機器,以及測試的瀏覽器分別是:

  • iPhone 5S(iOS 8.1.0) – Safari
  • LG G3(Android 5.0) – 內建瀏覽器、Chrome Android 43.0.2357.93、Facebook inapp browser(核心為 Chrome 30.0.0.0)
  • ASUS ZenFone 5 – 內建瀏覽器、Chrome Android 40.0.2214.89
  • SONY Z3(Android 5.0.2) – Chrome Android 43.0.2357.93

服用本文前請注意:也許瀏覽器版本更新後,本文的方法就失效了,所以請作為參考就好哦。

實作與問題

之前在案件中,使用下面這段程式碼作為 workaround:

setTimeout(function() {
  window.location = scheme_link;
}, 25);
window.location = download_link;

註:其中 scheme_link 是 app 的 scheme,可以是單純開啟 App,或是直接進入 App 的某一個畫面。而 download_link 是下載 App 的 URL 連結,像是 Google Play 或是 App Store 的連結。

之前實測時,在裝置上大部分情況都能如預期的運作,但仍有特殊情況(如特定版本的 Chrome、Android Stock Browser)有點小問題。

而隨著瀏覽器版本更新,這次案件再實測似乎就會出現更詭異的情況了,例如同時打開 App 與 Google Play/App Store 的連結。

於是再度至 stackoverflow.com 尋找其他解決方案,找到 一個 2014 年 8 月左右被更新的解答

我針對該解答再做些微調後的 workground 整理說明如下:

繼續閱讀…