移動應用程序解決方案架構（Android開始，多平臺）

Question

我一直負責構建業務的移動應用程序平臺。我在android中使用傳遞json的REST API構建了一個測試應用程序，但我不確定這是否是最佳解決方案。

的應用程序最終在iPhone，Windows Mobile的，黑莓和Android運行。還有一些業務規則讓我猶豫整體架構應該如何。

首先，讓我解釋一個小術語。 A 客戶是一個實際上是我們的客戶之一的業務。客戶不瞭解彼此。 超級用戶可以做所有客戶的一切，也是我們的員工。 管理員可以爲特定客戶端做所有事情，並由客戶端使用。 最終用戶是客戶的客戶。最終用戶可能會與我們的客戶之一或可能不止一個客戶做生意。但他們無法知道這一點（我無法向他們展示所有客戶的名單，並讓他們選擇與他們聯繫的客戶）。

目前，我們有一個Web應用程序，其中從客戶端的網站的鏈接是指誰最終用戶與相關聯。然後他們使用他們的帳號與該客戶端將他們的客戶數據附加到他們的網站帳戶。

因此，我需要開發幾個不同的應用程序，我認爲我已經將它定位到2.一個管理應用程序和一個最終用戶應用程序。如果超級用戶登錄管理應用程序，他們將被允許選擇他們正在處理的客戶。如果常規管理員登錄，他們將只能與他們關聯的客戶端一起工作。

最終用戶的應用程序是事情變得撲朔迷離。我必須知道他們正在與哪個客戶合作，然後獲得他們的帳號來附上他們的客戶詳細信息（一旦我知道他們正在使用什麼客戶，這很容易）。最初的想法是爲每個希望將其提供給用戶的個人客戶（或給他們的源代碼）發佈一個應用程序版本，然後將每個版本硬連線到該客戶端。但是，這似乎是一個巨大的羣體維護。我必須處理的另一個警告是允許應用程序具有主題化和品牌化。

而這正是我不能在架構決定。我是否應該像對待其他應用那樣做，並在移動平臺上擁有UI，並通過服務傳遞數據，還是應該將移動應用作爲Web託管應用的webview門戶？兩者都有優點和他們自己的一套問題，都沒有解決必須將最終用戶附加到客戶端的問題。我正在尋找來自在多個平臺上從事移動解決方案工作的人員的建議。

Answer 1

我沒有任何構建移動解決方案的經驗，但我立即想到的是，我寧願第一個選項：「有在移動平臺上的用戶界面，並通過服務傳遞的數據」。

我的理由是用戶體驗。我使用的是Windows Mobile（WP7），我非常喜歡本地用戶界面，它非常吸引人並且高效（最重要）。相比之下，瀏覽網絡應用程序並不令人愉快或容易。

如果你想創建一個應用程序，人們想用（這隻能對您的業務產生積極的影響），那麼你會希望採取原生UI的路線。

另外我沒有看到架構選項是相互排斥的;你可以實現一個堅實的服務基礎，這反過來又可以被基於服務器的Web UI和移動UI所使用。