甚麼是前端開發?

(Ref:https://flatironschool.com/blog/front-end-vs-back-end-development/

如果有接觸過網頁開發的讀者,或者會聽過很多不同的專有名詞,其中不少得Front-end (前端) 和 Back-end (後端)這兩個字詞。有一些網站可能只需要設計師和前端開發者,有些則需要後端開發者和測試人員等等,那究竟前端和後端如何分辨?首先,讓我們搞清楚前端開發是什麼一回事。


Front-end 前端開發

(Ref: http://devana.rs/blog/front-end-interaction-designer/

前端包含所有用家能夠見到、繼而互動的畫面,而現今的網頁主要仍是利用HTML、CSS 和 Javascript 來建構這些畫面。

HTML相信即使不是程式員都不陌生,HTML 全名是 Hypertext Markup Language(超文件標示語言),是建立網頁的標準標示語言,簡單來說就是一個網頁的骨幹。早期的網頁,如這個有關WWW萬維網的網站(連結),主要只有文字,充其量會有一些圖像,所以畫面比較乏味,如下面的例子1a)。於是,就有CSS的誕生了。

1a) 只使用HTML的網頁 :https://codepen.io/OnesSoftware/pen/wVKvxx

CSS 於 1998年出現, 全名是 Cascading Style Sheets(層疊樣式表), 一種用來為例如HTML、XML 等這些結構化文件添加樣式的電腦語言,亦即是一個網頁的表皮/裝飾

在CSS 誕生前,要控制網頁如何顯示,就要在HTML檔案內包含顯示的資訊,例如字型的大小和顏色、背景應該是怎樣的、如何排列等等,這些都必須逐一在HTML檔案內列出。有時會因為資訊重複列出而令到網站過份冗長。CSS的出現使開發者可以將大部分這些顯示用的資訊中隔離出來,從而簡化 HTML 的檔案。這些資訊會被放在一個輔助的,用CSS語言寫的檔案中。理想來說, 現在的HTML檔案中應該只包含結構和內容的資訊,而CSS檔案中就包含樣式的資訊,以達致分工的目的。

1b) 使用了 HTML 和 CSS 的網頁: https://codepen.io/OnesSoftware/pen/rXOajM

在上面的例子1b),是將純粹使用HTML作為框架的 1a),加上 CSS 的裝飾,例如文字顏色、 邊框和背景顏色。

網頁的骨幹和表皮都有了,已經可以製作一些漂亮的靜態頁面,但如果要有一些能夠互動的部分,例如持續取得一些即時的資訊、儲存數據,甚至只是按下按鈕時彈出對話框,只用HTML和CSS的話都難以實行。 JavaScript 就正正能夠補充給予網頁「肌肉」並得以「活動」這個角色了。

1995 面世的 JavaScript 主要用作管理網頁的內容以及用戶的操作行為,而由於不同PHP、ASP的伺服器端手稿語言,不需要伺服器的支援也能夠在用戶的瀏覽器上運行,所以的確能夠減少對伺服器的負擔。

1c) 使用 HTML 、CSS 和 JavaScript 的網頁:https://codepen.io/OnesSoftware/pen/WVrwbv

在上面的例子 1c) 中,加了JavaScript 的輔助後,按下按鈕就會彈出「clicked」的對話框。

UI 與 UX 的比較

時至今日,前端的技術不斷轉變, 中間有過Flash、 Silverlight 這類 Web前端應用程式的開發解決方案曾經稱霸多年,卻因為手機平台不支援等因素而被淘汰。反而最基礎的 HTML、JavaScript、CSS不斷改進,以致如播放實時影片、繪圖、動畫等的功能都無須額外方案處理。而現在有不少 framework 和 library,如 ReactJS/Bootstrap 等等,能夠提供規格化的開發資源,使得開發的效率和水準得以大大提升。

前端開發者的主要職責,除了負責網頁的內容如何擺放,亦即所謂的 User Interface(使用者介面),也要照顧到用戶的瀏覽體驗,那就是 User EXperience(使用者體驗),這就要和專門的 UI、UX 設計師合作才得以處理得宜。前端開發者也要和後端開發者處理前後端之間的編程介面(API),使得有需要數據得以儲存、獲取和處理等等。

有興趣理解前端開發者的技術路線圖,可以看:

https://github.com/goodjack/developer-roadmap-chinese/blob/master/chinese-version/images/frontend.png

Ref:

https://zh.wikipedia.org/wiki/HTML

https://zh.wikipedia.org/wiki/%E5%B1%82%E5%8F%A0%E6%A0%B7%E5%BC%8F%E8%A1%A8

https://www.pluralsight.com/blog/film-games/whats-difference-front-end-back-end

https://flatironschool.com/blog/front-end-vs-back-end-development/

更多資訊可以留意 ONES Publication 定期發佈的文章,亦可以聯絡我們,我們的網址是: https://ones.software

ONES Publication
We share what we have learned about app and web development. Find us in ones.software. Email: hello@ones.software

聯絡我們:
主頁: https://ones.software/hk/
電郵地址: hello@ones.software
電話號碼: (+852) 5538 3410
Contact us:
Homepage: https://ones.software/
Email address: hello@ones.software
Phone number: (+852) 5538 3410

]]>

SaaS的多租戶模式(Multi-tenancy)實踐:.NET Core + Entity Framework Core

企業級軟件訂閲服務 (SaaS) 的開發 (2)
多租戶模式 (Multi tenancy)

我們於上一篇提過關於多租戶模式 (Multi tenancy) 的各種好處,今日我們就來談談如何去實際架構出一個多用戶模式的服務器架構,並能實現客戶獨立穩健、容易維護的特點。


多用戶模式的實現方法可以分爲幾種:

  1. 服務器使用同一個域名 (Domain Name),在每一個請求 (Request) 裏面都加上一個 TenantId 的參數作分辨。
  2. 服務器使用同一個域名,然後以不同的用戶ID 來作區分。
  3. 服務器接受不同域名,每個客戶都給予他一個專屬域名,並以域名去區分

這裏會示範實現第三個方案,其優點有:

  • 可以用不同子域名 (Sub-domain) 去分給不同用戶,例如 tenantA.example.com,tenantB.example.com。如果請求裏面加有用戶的名字的話,能夠讓用戶感覺方案是他們專有的服務。
  • 如果客戶自己公司有想用的域名的話,也可以使用。只要在他們的域名服務器 (Domain Name Server)上,把域名指到我們服務器的地址便可。
  • 對服務器來説,只要小心處理,用哪個方案差別都不大,但是在瀏覽器 (Browser)上差別就很大。方案 1 和 2 都是使用同一個域名進入,即使所有客戶不同,他們在瀏覽器上的 Cookie 或者 Local Storage 的空間都是共通。雖然説在實際環境中,同一臺電腦登入不同客戶的情況非常罕見。但一旦登入不同客戶,就很容易發生資料有衝突。這樣的話,就不容易達到客戶獨立這個條件。相反方案 3的話,每一個客戶都使用不同的域名,在瀏覽器上的的存取空間也會是獨立的,就不會發生以上的問題。

閒話休提,要開始實際示範了。這個示範架構的概念是「靠頂端判斷租戶資料,再於末端去進行分類處理」。這裏我們會利用 .Net Core + Entity Framework Core 來實現一個多租戶模式的例子。這個例子要符合三個要求:

  1. 根據不同請求域名 (Request Host Name),返回對應的客戶資料,如名字;
  2. 根據不同域名,存取不同的數據庫 (Database)
  3. 根據不同域名,上載和下載檔案(File) 進去不同的文件夾 (Folder)

實際操作

1.首先打開 Visual Studio,新增一個 .Net Core 的 Project,這裏我們用 2.2版本。

2.定義 Tenant (租客),裏面存放了該客戶的資料,如客戶名字數據庫的地址 (ConnectionString),存取檔案的文件夾,和這個客戶接受的所有域名。

3.定義TenantContext,用來緩存當前的Scope現在是哪一個租戶。

4.定義TenantResolver,來根據不同的域名去搜尋自己屬於哪一個租戶。這裏爲了方便示範,所有直接加入了兩個客戶的資料在這裏,但正式應該要讀取一個額外儲存所有租戶資料的檔案,或者是連接到一個遠端的租戶管理服務器,來讀取租戶資料。

這裏的例子,如果是經過 localhost:5000 進來的就是客戶A,localhost:5001進來的就是客戶B。

5. 到這裏爲止,就有了最基本的構成了。然後就是如何去判斷請求是屬於哪一個租戶,這裏使用中間件 (Middleware),來定義一個HttpTenantResolveMiddleware 去判斷。

在 HttpContext 裏面能夠找回當前 Request 的 HostName,並通過TenantResolver 裏是屬於哪一個 Tenant,最後放進去 TenantContext 裏面便可。

6.在 startup.cs,把之前定義的 Class 都加進去依賴注入,TenantResolver 用 Singleton,其他的用 Scope。

這裏有一個巧妙的地方,就是把 TenantContext 裏面的 Tenant 再放進Scope裏面,這樣就可以更直接的在拿到當前 Scope 的租戶。

7.加入 HttpTenantResolveMiddleware 進流水綫 (Pipeline)。判斷 Tenant這個流程,越早階段做越好,所以這裏直接放到第一位。

8. 這楊就可以開始簡單的測試一下。首先在 launchSetting 裏面加上兩個Tenant 的 Url。

定義一個測試的 Controller,裏面直接 注入 (inject) Tenant 進去就可以了。

然後就可以看到測試結果。同一條路徑,同一個服務器,但經過不同域名的請求,返回不同租戶的資料。

到這裏,基本的租戶分類就完成了。


數據庫存取  — Entity Framework Core

接著來示範一些對 Db 的實際操作,這裏用 SqlServer 來做示範。

1.要加入三個 Entity Framework Core 需要的 Nuget Project。

2.我們就定義一個簡單的 TenantDbContext 的數據庫,裏面有一個 Key value pair 的表。

3.在 startup.cs 裏面注入 TenantDbContext。平時的 Entity Framework 教學裏,都會在這裏加入數據庫的地址 (connectionString) 加進去,但我們就不在這裏加。

4. 再來一個小竅門,在 TenantDbContext 也注入 Teannt。覆蓋掉原來的 OnConfiguring,在這裏用 Tenant 裏面的 ConnectionString 去指定數據庫路徑。

5.然而,如果現在直接運行 add-migration 去添加 MIgration 的話,就會發生錯誤。因爲在沒有請求的時候,是不會知道現在是屬於哪個租戶,和應該連去哪個 DB。

但其實這個問題很容易解決。只要加一個 Class 去Implement IDesignTimeDbContextFactory<TenantDbContext> 就可以。在運行 add-migration的時候,就會根據這裏去創建 TenantDbContext,只要在這裏給一個假的住戶資料進去,add-migraiton 的時候就可以靠這個Tenant的數據庫路徑,去計算 Migration。

Migration 成功做出來了!

6.然後就到建立的數據庫的時候。在startup.cs configure 的最後階段,對每一個 Tenant 都創造一個新的 Scope,將該 Tenant 放進 TenantContext,再運行 Migration 就可。

運行完後看一看 SSMS,兩個客戶的數據庫都應能成功創造出來。

7.開始實際測試,做一個測試數據庫的 Controller。如果熟悉 Entity Framework的人就會發現,在這裏對 Entity Framework 的用法和平時的用法沒有任何分別

測試開。預先將設了客戶A的 hello=I’m Tenant A, 然後就可以看到不同的域名拿到的結果是不一樣,兩個數據庫是完全分開的。

檔案存取

1.這個做法也很簡單,做一個 TenantFileService,也是一開始就注入Tenant。這裡都用 Tenant 裏面的 FileDirectory 作爲路徑的基礎。

2. 在startup.cs的加到 Dependency Injection 裏面。

3.實際測試,和數據庫的測試一樣,也是 Controller 注入TenantFileService,直接使用便可。

大家可以看到經過不同的域名上載的檔案,會分別放進不同的文件夾裏面。


總結

上一篇裏面提到過,儘管是在多租戶模式(Multi Tenancy)的環境下, 用戶資料的安全和保密還是最重要的考慮。而這個例子的示範的系統架構,就正正是爲了達到這個目的。

裏面提到過,儘管是在多租戶模式(Multi Tenancy)的環境下, 用戶資料的安全和保密還是最重要的考慮。而這個例子的示範的系統架構,就正正是爲了達到這個目的。

當一個系統不斷開發期間,開發者不可能寫每一個功能的時候,都要顧慮到如何去區分現在是屬於哪個一租戶,因爲這樣很容易會發生人爲錯誤,也會令到代碼混亂,難以維護。

而這個結構的好處是,在最頂端的階段已經確立好這個請求是屬於那個一租戶,然後到了最末端的 IO 的部分,根據最頂端的判斷好的租戶資料去決定如何存取,而中間的邏輯部分就完全不用顧慮到租戶的問題,就當普通的服務器去開發功能便可。

當然實際的多租戶模式的不止這麽簡單,還有很多範圍要顧及,如背景工作 (Background Job)緩存 (Cache)WebSocket日誌文件 (Logging) 等等。但只要牢記這這個例子的概念 「靠頂端判斷租戶資料,再於末端去進行分類處理」,那無論功能如何增加擴大,也能做好維護工作,而不會發生用戶資料混亂的事情發生。

大家可以上我們的Github,去下載這個 project 實際來試試看。 https://github.com/ones-software/dotnet-core-multi-tenancy-sample


ONEs software: https://ones.software/hk/bookings-one/

]]>

軟件可以即要即用?企業級軟件訂閲服務 (SaaS) 的開發 (1)


自從 2006 年 Amazon 推出自家的雲端運算服務 AWS 開始,雲端運算徹底改變了傳統伺服器架構的使用方法。由每一次都要購買或租借一臺伺服器主機,變成想用多少伺服器資源都可以即時得到,並採納按照實際使用時間來計算收費的資源訂閱 (Subscription) 模式,大大提升架構系統的靈活度和資源分配效率。這種伺服器架構上的革命,造就了 Software as a Service (SaaS) 的興起。

在這種交付模式(即 SaaS)中雲端集中式代管軟件及其相關的資料,軟件僅需透過網際網路,而不須透過安裝即可使用。用戶通常使用精簡用戶端經由一個網頁瀏覽器來存取軟件即服務。--維基百科

雲端運算經歷了十餘年的發展,隨著各大科技巨頭如 Microsoft AzureGoogle Cloud 紛紛加入戰團,今時今日雲端運算服務已經發展得非常成熟。雲端運算能提供到一些普通伺服器不容易做到的功能,如專門處理大數據的資料庫 (Big data Database),以及針對地域問題的災難恢復 (Disaster recovery)。這些服務提供極高的彈性,方便了不少軟件開發商去開發新的軟件,而訂閱收費模式亦大大降低了初創企業入場的門檻。

https://www.cio.com/article/2991767/10-tips-for-running-a-profitable-subscription-based-business.html

由於雲端運算採取了訂閲收費,軟件的收費模式亦跟隨著由一次性 (one-off) 收費趨向以訂閲收費的形式來供客戶選擇。這個顯然是整個軟件業界的發展方向,例如 Microsoft 和 Adobe, 都將旗下歷史悠久的 Microsoft Office 和 Adobe Photo 分別轉為 Office 365Creative Cloud 這種訂閲式收費軟件。 新的訂閲模式的娛樂服務如 Netflix / Disney+ / Apple TV + 也不斷興起,而Google 最近發佈的 Stadia 更是企圖用訂閲收費的模式,來衝擊整個遊戲業界。

Every customer interaction is a marketing opportunity. If you go above and beyond on the customer service side, people are much more likely to recommend you. — — Stewart Butterfield, co-founder of Slack


雖然說軟件訂閲是一個大趨勢,但如何去建立一個成功的系統,就需要相當多軟件工程上的學問。和對普羅大衆的軟件不同,企業對軟件的要求會更加嚴格,因爲整個服務會影響到他們自身的日常商業運作,所以在建立這種系統時,需要注意的項目就比平時更多。今後我會在這裡和大家由以下的方向出發,去探討怎樣去建立一個穩健的軟件訂閲服務。

  1. 系統架構 (System architecture)
  2. 可擴展性 (Scalability)
  3. 高可用性 (High availability)
  4. 安全性 (Security)
  5. 監察與維護 (Monitoring and Maintenance)
  6. 持續發展 (Continuous development)

那麼,讓我首先講解一下系統架構所需要留意的事項。


系統架構 (System architecture)

建立軟件系統的第一步是設計好適合的系統架構,根據不同的商業需求 (Business Requirement) 所設計出的系統架構也會不同。但歸納起來,訂閲服務的系統架構的可以分爲兩大類:單一租戶模式 (Single tenancy) 多租戶模式 (Multi-tenancy)


單一租戶模式 (Single tenancy)

單一租戶模式 是為各個客戶設立一套獨立的軟件系統,他們會有獨立的數據庫、服務器、文件存儲空間等等。

安全且穩定: 絕大部分企業都會重視資料的安全和保密。單一租戶模式的好處在於每個客戶都有完全獨立的系統,不會有用戶之間資料發生衝突的情況發生,也不會因爲其他客戶的使用量增加而影響到自身的系統。單一租戶對於企業來説會是一個極具說服力的方案。

有彈性及易於管理:所有數據庫備份、系統還原的工作,或者其他的定制服務,單一租戶模式都能夠提供給予客戶。系統也能夠根據客戶的要求更改域名,或者安裝在客戶指定的雲端服務上面。而因為每個服務器都是獨立運作的,用戶可以選擇在不影響業務的時間帶,來進行系統更新。

單一租戶模式是一個直觀的方案,和傳統的系統分別其實不大,只是將系統由傳統的數據中心轉移到雲端服務之上,而雲端服務的成本也就轉化為系統的訂閲收費。


租戶模式 (Multi-tenancy)

和單一租戶模式不同,多租戶模式是以共用系統資源爲主,多個用戶會同時使用同一套系統

經濟實惠:在商業角度來看,價錢是相當重要的考慮因素,多租戶模式就能通過分享各個用戶的用量,來分攤成本。這就能將現有的資源得到充分利用,以避免服務器資源上的浪費。按照不同服務的性質而有差別,但採取多租戶模式的話,往往就能夠將伺服器的成本降至一成以下

迅速提供服務:訂閲服務講求的是能否迅速提供服務,使客戶在短時間内就開始使用是重中之重。 單一住戶模式可能需要數天的設立時間,並對系統進行整合測試 (Integration test)、負載測試 (Load test)等等的測試,才能確保實際運行穩定。而多租戶模式則是在已經運行中的系統中,添加新的租戶 (Tenant) 給予客戶。添加用戶往往只要數分鐘便完成,而且系統的穩健程度就得到確保。

容易監察、維護及更新:完善系統的監察亦是確保服務質素的重要一環。在多租戶模式下,開發者只需要監測一組伺服器的狀態,便可知道所有客戶是否能正常使用系統。而當要修正系統時,只要將修正配置到一組伺服器上就能解決問題,不需要針對個別客戶進行修正。

用戶回饋和產品發展:多租戶模式往往可以使得產品有更高速的成長速度。每當新功能完成並配置到系統上,所有租戶也能即時受惠。而功能亦能啓發用戶提出新的需求,開發者能根據這衆多的用戶回饋去分析和開發新的功能。

雖然多租戶模式下的系統是分享了各種資源並降低成本,但要注意的是用戶的資料是必須做好區分。例如可以使用同一個數據庫伺服器,但每個客戶的數據庫必須分開。文件存儲亦是同等狀況,每個客戶儲存文件的文件夾必須分開。即使在資源共享的情況下,數據的安全和保密還是最重要的考慮。


如何取捨?

Photo by Victoriano Izquierdo on Unsplash

兩種都各有優點,但實際要建立一個系統的時候,到底應該如何取捨呢?恕我直言,我是傾向支持開發多租戶模式,原因是多租戶模式本身是可以作爲單一租戶模式來使用。

不同的客戶對系統會有不同的要求。如果有客戶提出必須有一個完全獨立的系統時,你可以爲一個客戶另外設立一組伺服器。這組伺服器只是爲了服務這客戶而設,並限制只有該客戶才能使用這個環境,不會添加新的租客。這樣多住戶模式就能簡單地變成單一租戶模式來使用,各取優點。

總結

現在多租戶模式的應用是大勢所趨,Slack、Office 365 ,這些軟件都是採用這種系統架構。這樣才可以控制成本,以維持市場上的競爭力。

多租戶模式似乎有絕對的優勢,但實際上做出一個穩健的多租戶模式系統並不容易,對開發者的系統架構能力也有很高的要求。而系統有任何問題也會影響到全部的客戶。例如系統如不採取一個有效的方法,去將用戶的流量分流到不同的數據庫的話,極有可能會令到系統本身出現混亂,往後亦難以作出維護。

我們之後會和大家介紹多租戶模式的實踐,由原始碼的層面出發,去看看如何做出一個穩健的多租戶模式架構。更多資訊可以留意 ONES Publication 定期發佈的文章,亦可以聯絡我們,
我們很樂意提供相關的專業意見:https://ones.software/hk/bookings-one/


ONEs software。香港軟件開發團隊,提供專業的軟件開發服務。包括手機應用程序開發,網頁開發和定制軟件開發。 https://ones.software/zh-hk

]]>

到了2019,企業還需要哪種手機應用程式?

Photo by Yura Fresh on Unsplash

由2008年 iOS App Store 開張至今,十多年間手機應用程式的數量,不論是Android 還是 iOS 的平臺上,都已經達致200 萬個以上。今天,都市人每日都透過手機上網去做各種各樣的事,網上理財、Facebook IG、打機拍片、買賣交易。有些人可以忘記帶錢包出街,但不能不帶手機出街。所以對於大小企業來說,不論對外的客戶還是對內的員工,手機應用程式還是一種不可或缺的重要媒介。

Your mobile device has quickly become the easiest portal into your digital self. — — Phil Nickinson, Editor of Android Central

手機應用的開發也風靡一時,在2012年前後,開發到一個便利易用的手機應用程式,近乎等同掘到第一桶金。時至今天,手機應用開發逐漸衍生出不同的類型,客戶能夠按照自己不同的需要、資源、開發時間等等,去選擇適合該企業手機應用的開發類型。以下就讓我介紹一下各種應用程式的開發類型,好使大家能夠找出合適的應用程式。


原生應用(Native App)

(來源自:http://uatblog.nubizsol.com/index.php/2018/12/24/hybrid-mobile-app-development-by-nubiz-specific-to-the-time-and-customer-needs/

原生應用(Native App),意指用該手機系統原生的程式去編寫應用程式。由最早期 iOS 的 ObjectiveCSwift,或者 Android 的 Java 到 Kotlin ,都是最直接的開發方法。而理論上,原生應用理應可以最有效地利用到手機的所有性能,而達至最佳的手機用戶體驗。

原生應用可以緊隨著手機系統的升級而改變,所以它能夠比其他類型的應用程式,更能盡用手機本身的功能。例如這幾年相當流行的機器學習(Machine Learning),還是擴增實境(Augmented Reality/AR),這些功能都是原生應用可以第一時間使用得到。

但相反地,原生應用的弊處在於開發成本較大。在 iOS / Android 各據市場一方,有時甚至要顧及 Windows 用家的時候,除非在特殊的要求下,否則基本上是必須同時支援兩個平臺以上的用家。在多個平臺都要分別開發的情況下,開發的成本與時間翻兩倍亦屬平常。

原生應用程式的例子有:Camera+, iCalender


混合應用(Hybrid App)→ 跨平臺應用(Cross-platform App)

當原生應用其時間和開發成本上的問題越趨明顯,市場自然有相對的解決方案應運而生,而這就是混合應用(Hybrid App)

混合應用的基本概念是在手機裏面放置一個網頁瀏覽器,透過這個瀏覽器就可以去開啓一個模擬手機應用的網站。因爲瀏覽器在手機來説是共通的,所以把主要能夠共用的程式,都以網頁的形式呈現。而網頁未能實現的功能,就用該平臺的原生程序去編寫。以同時推出 Android、iOS 兩個平臺的應用程式為例,混合應用能以大概1.5倍的開發成本和時間,就能做到原生應用兩倍的效果

在2015年,使用 AngularJS + Cordova 作爲根基的 Ionic 曾經瘋魔一時,以 Ionic 編寫的應用程式大量湧現。然而當時混合應用的核心問題,在於用戶介面表現的效能。當時的 Android、iOS 的瀏覽器性能上都非常有限,在用戶體驗上,混合應用會較原生應用差得多。有經驗的手機用家,也許一眼就能看出哪個應用程式是否混合應用。企業形象亦有機會因為其混合應用程式的用戶體驗較其他遜色,而有所減損。

為了減省開發成本,而又不放棄用戶體驗各個手機應用程式公司不斷摸索,其中跨平臺應用(Cross-platform App)可說是混合應用的後繼者。和混合應用的最大不同之處,在於它們針對用戶介面體驗上進行的改善,不再使用網頁和瀏覽器,而是提供一套共同的用戶介面開發框架,給開發人員去編寫出原生的用戶介面,這樣大大改善了混合應用在用戶體驗上的不足。Facebook 的 React native, Microsoft 的 Xamarin,Google 的 Flutter 或者 Vue Native,這些都是跨平臺應用的開發框架。

不過,這些開發框架雖然都聲稱自己是原生應用的開發工具,而它們在用戶體驗/性能上也和原生應用相當相近。但跨平臺應用往往需要至少幾個月的時間,才能支援最新的手機功能,始終不如原生應用來得快。企業如需要追求應用程式能夠使用最新手機功能的話,就要留意應否採用跨平臺應用的開發模式。

即使如此,跨平臺應用依然能達到現在超過 9成以上用戶的需求。大家經常接觸到的手機應用程式,包括 Instagram, Evernote, UBER, Twitter, Netflix 等等,都是屬於跨平臺應用,可見跨平臺應用已是今天開發模式的主流。


網頁應用(Web App)→ 漸進式網絡應用程式 PWA(Progressive Web Application /PWA)

(來源自: https://developers.google.com/web/progressive-web-apps/)

網頁應用(Web App)講白了就是單純的一個網頁,不過這種網頁多用所謂單頁應用 (Single page Applications/SPA)的框架來建立。隨著這幾年手機上的瀏覽器發展越來越進步,網頁應用已能夠給予用戶相當接近手機應用的感覺。

在效能層面上,現在的瀏覽器下網頁應用的效能已經比幾年前進步不少,但當然還是遜色於上文提到的兩者。以功能方面來看,網頁應用也有很多未能做到的功能,例如讀取 QR Code、藍牙裝置信息等等,亦無法利用如 Apple Store/Play Store 的付費功能。但如果企業的應用程式只是如購物網般以文字、圖片等簡單數據為主的話,網頁應用絕對是一個不錯的選擇。

基於網頁應用的優勢,iOS 和 Android 亦作出相應的性能強化,於是 就有漸進式網絡應用程式(Progressive Web App/PWA)的出現。當你使用 iOS 的 Safari 或者是 Android 的 Chrome 去瀏覽網頁時,用戶可以選擇添加該網頁到手機桌面上,這樣網頁就會以一個類似手機應用的模樣出現。對於一般用戶而言,PWA 看上去和其他手機應用程式沒有分別。而這些應用程式還可以用到很多原生應用程式才有的功能,如推送信息、讀取坐標、相機拍照、運用手機指南針等等。

網頁應用/ PWA 還有一個相當突出的優點,就是不用透過 App store 下載就能直接使用。現在用戶拒絕下載手機程式的原因有很多,譬如上網流量有限、電話容量不足、手機已經安裝過多應用程式等等。而網頁應用/ PWA 就是省卻這些用戶的顧慮,用戶可以簡單到只要掃描一下QR Code,又或者在 Google 搜索一下就可以開始使用。這種快捷的體驗,對宣傳新產品來説,是相當有效。

最重要的是,網頁應用的開發成本和時間是各種開發模式之中最短的,用最低的成本,就可以支援近乎所有的手機平臺,甚至電腦桌面都能同步使用,很適合一些如網絡購物、預約房間等等不需要用到手機很多功能的服務使用。不妨嘗試用手機去Starbucks 的網頁 https://app.starbucks.com, 來試一試 PWA 的威力。

PowerApps

除了面對大衆的應用程式外,現在很多公司都積極尋求給予内部員工使用的應用程式,例如員工申報開支、請假等等,以方便公司内部管理和運作,而Microsoft 的PowerApps正正就符合這些功能。

PowerApps 其實是附屬 Microsoft Office 365 的應用程式,員工只需要上 Apple store/Play store 下載 PowerApps 並登入,PowerApps 就能提供一個比較簡單的用戶界面,管理人員可以在 PowerApps 上放置各種小型應用程式,員工可以透過這些應用程式去處理日常公司事項。PowerApps 也會和 Office 365 的 OneDrive / SharePoint / Power BI 等等有互相的聯動,以構成一個一體化的系統,管理人員則能透過 PowerApps 所產生的各類報告以得知公司的運作。

( 來源自:https://powerapps.microsoft.com/en-us/blog/powerbi-powerapps-visual/)

固然,PowerApps 的開發成本是普通應用程式的 20% 而已,但其主要成本反而來自 Microsoft Office 365 定期的訂閱收費,皆因每個使用 PowerApps 的用戶,都要有其 Office 365 的賬號才能使用,成本自然不菲。但如果閣下的企業本身已經使用 Office 365 的服務,而又想利用一些應用程式去方便公司日常運作的話,PowerApps 還是一個不錯的選擇。


遊戲開發引擎

Unity和虛幻引擎(Unreal engine),這些開發引擎都是專門開發遊戲用的。它們所支持的平臺不局限於手機應用,甚至可以於 PlayStation / Switch / Steam 等遊戲平臺實現。現在常見的跨平臺遊戲很多都是以這類型開發的,這類型的應用強項在於 3D 的表現和遊戲運算,不論遊戲開發,還是一般手機應用程式亦能使用到。如 MinecraftPUBG 這些膾炙人口的遊戲,都是用 Unity / 虛幻引擎來開發的。


總結

手機應用程式開發類型比較 (2019)


ONEs software: https://ones.software/hk/bookings-one/

]]>