共用方式為

  • 發行項

2015 年 9 月

第 30 卷，第 9 期

本文章是由機器翻譯。

連線到雲端的行動應用程式 - 建置具備驗證與 Office 支援能力的 Xamarin 應用程式

由 Kraig Brockschmidt

這兩個部分的系列"建立 Web 服務與 Azure Web 應用程式和 WebJobs"的第一個部分中所述 (msdn.microsoft.com/magazine/mt185572)、 在 8 月號、 許多行動應用程式現在已連線到一或多個 Web 服務提供有趣又實用的資料。雖然很容易就直接進行 REST API 呼叫這些服務和處理程序回應的用戶端中，這種方式可能會大幅降低電池電力、 頻寬和節流不同的服務所加諸的限制。效能也可能會降低在低階硬體上執行。它很合理，然後為我們示範使用"Altostratus"專案卸載工作自訂的後端，我們稍後會討論這篇文章。

Altostratus 後端則討論在第 1 部分定期收集和正規化 「 交談 」 從 StackOverflow 和 Twitter (只是為了使用兩個不同的資料來源) 並將它們儲存在 Microsoft Azure 資料庫。這表示用戶端所需的確切資料可提供，由後端直接讓我們可以容納任何數量的用戶端而不叫用的原始提供者的節流限制的 Azure 中調整後端。利用正規化以符合用戶端所需要的後端上的資料，我們也會最佳化透過 Web API，以節省行動裝置曾經很少資源的資料交換。

在本文中我們將討論用戶端應用程式的詳細資料 (請參閱 [圖 1)。我們將開頭應用程式的架構來設定整體的內容，然後移到我們使用 Xamarin 及 Xamarin.Forms，驗證的後端的建置離線快取中，並使用 Team Foundation Server (TFS) 和 Visual Studio Online 上的 Xamarin 建置。

Xamarin 行動應用程式上執行 Android 平板電腦 (左)、 Windows Phone (中間) 和 iPhone (右)
[圖 1 Xamarin 行動應用程式上執行 Android 平板電腦 (左)、 Windows Phone (中間) 和 iPhone (右)

用戶端應用程式架構

用戶端應用程式有三個主要網頁或檢視表: 組態、 首頁和項目，其類別共用這些名稱 (請參閱 [圖 2)。次要登入頁面沒有 ui，只是 OAuth 提供者 Web 網頁的主機。使用基本的 Model View ViewModel (MVVM) 結構，除了登入每個主頁面有相關聯的檢視模型類別處理繫結之間的關聯性的檢視和資料模型類別代表的項目、 類別和組態設定 (包括驗證提供者的清單)。

Altostratus 用戶端應用程式中顯示的主要類別的名稱所涉及的架構 (在專案中的檔案表示除非符合這些類別名稱)
[圖 2] Altostratus 用戶端應用程式中顯示的主要類別的名稱所涉及的架構 (在專案中的檔案表示除非符合這些類別名稱)

(附註： 開發人員通常想要分成不同的檢視模型和其他的類別、 可攜式類別庫 [PCL] 的 [XAML] 檢視可讓設計人員獨立使用 Blend 等工具檢視。我們沒有做出的區隔來簡化專案結構，以及因為 Blend 並不適用於 Xamarin.Forms 中的控制項這一次。)

資料模型永遠會填入這些物件從已預先填入的應用程式的第一次執行本機 SQLite 資料庫。同步處理後結束，這剛好也在資料模型中，會擷取新的資料 (盡可能降到最低的網路流量) 的簡單程序更新資料庫與清除任何舊的資料和指示要重新整理其物件的資料模型的資料。這會觸發更新 UI，由於檢視模型與資料繫結。

不同的事件數目，稍後討論，觸發同步處理： 重新整理] 按鈕在 UI 中，變更組態，驗證與後端 (它會擷取先前儲存的設定)，至少 30 分鐘之後繼續執行應用程式等等。同步處理與後端透過它的 Web API 的主要通訊當然但後端還提供 API 來註冊使用者、 擷取已驗證的使用者設定及更新這些設定時已驗證的使用者變更設定。

跨平台用戶端的 Xamarin.Forms

隨著您可能已經閱讀 MSDN magazine 》、 Xamarin 可讓您使用 C# 和 Microsoft.NET Framework 針對 Android、 iOS 及 Windows，包含大量的平台之間共用的程式碼建置應用程式。(我們的開發組態的概觀，請參閱後面的章節 「 建置利用 Xamarin TFS 和 VSO。 」)Xamarin.Forms framework 增加這個數量進一步的通用 UI 解決方案提供 XAML / C#。使用 Xamarin.Forms，Altostratus 專案會共用單一 PCL 在其程式碼的 95%以上。只有平台特定程式碼專案中的其實是來自專案範本處理 Web 瀏覽器控制項和幾行程式碼預先填入的 SQLite 資料庫複製到本機儲存體中的適當讀寫位置登入頁面的轉譯器用於啟動的位元。

請注意 Xamarin 專案也可以設定要使用的共用的專案而不是 PCL。不過，Xamarin 建議使用 PCL，而且與 Altostratus 的主要好處是我們 Win32 主控台應用程式中使用相同的 PCL 來建立預先填入的資料庫。這表示我們不重複的資料庫中的任何程式碼用於此用途和初始設定式程式一定會與其餘的應用程式的同步處理。

留意共用程式碼更不會減少徹底測試每個目標平台; 上的應用程式所需的投入時間只要您寫下每個應用程式原生一樣大約要該流程的一部分。此外，由於 Xamarin.Forms 是相當新，您可能會發現平台特定 bug 或其他您需要在程式碼中處理的行為。我們發現撰寫 Altostratus 時, 的一些詳細資訊請參閱我們張貼的 bit.ly/1g5EF4j。

如果您碰到奇怪的問題，您應該先 Xamarin bug 資料庫 (bugzilla.xamarin.com)。如果您沒有看到您那里討論的問題，您將問題或張貼問題 Xamarin 論壇上 (forums.xamarin.com)、 您可以在其中找到 Xamarin 部門的人員相當有回應。

話雖如此，處理這些個別的問題是最少的工作比學習每個個別平台 UI 層的詳細資料。而且因為 Xamarin.Forms 是相當新，尋找這類問題有助於變得越來越強大的架構。

平台特定的調整

內 Xamarin.Forms，有時候會需要進行調整的一個平台或另一個，例如微調版面配置。(請參閱 Charles Petzold 絕佳書 」 程式設計行動應用程式與 Xamarin.Forms"[bit.ly/1H8b2q6]，將多個範例。) 您可能也需要處理行為的不一致性，例如網頁檢視項目時就會引發其第一個巡覽事件 (同樣地，如我們所遇到的一些看到我們張貼 bit.ly/1g5EF4j)。

基於此目的，Xamarin.Forms 有 API Device.OnPlatform < T > (iOS_value，Android_value，Windows_value)，並將比對的 XAML 項目。您可以猜到了，OnPlatform 會傳回目前的執行階段根據不同的值。例如，下列 XAML 程式碼隱藏在 Windows Phone 上的 [組態] 頁面的登入控制項因為 Xamarin.Auth 元件還不能支援該平台，讓我們永遠執行未經驗證 (configuration.xaml):

<StackLayout Orientation="Vertical">
  <StackLayout.IsVisible>
    <OnPlatform x:TypeArguments="x:Boolean" Android="true" iOS="true"
      WinPhone="false" />
  </StackLayout.IsVisible>
  <Label Text="{ Binding AuthenticationMessage }" FontSize="Medium" />
  <Picker x:Name="providerPicker" Title="{ Binding ProviderListLabel }"
    IsVisible="{ Binding ProviderListVisible }" />
  <Button Text="{ Binding LoginButtonLabel}" Clicked="LoginTapped" />
</StackLayout>

談到的元件，本身的 Xamarin 主要是內建的抽象的原生的平台，其中有許多自封 Xamarin.Forms ui 的常見功能的元件。其中某些元件內建 Xamarin，而其他人，包括社群投稿從取得 components.xamarin.com。除了 Xamarin.Auth，Altostratus 會使用此連線的外掛程式 (tinyurl.com/xconplugin) 顯示指標和裝置離線時停用重新整理] 按鈕。

我們發現永遠會有一些之間的延遲 (隨插即用中的 IsConnected 屬性中所反映) 裝置上變更連線時以及當外掛程式會引發其事件。這表示可能有幾秒鐘的時間之間離線裝置並重新整理] 按鈕變更為停用狀態。為了處理這個我們可以使用 [重新整理命令事件來檢查隨插即用 IsConnected 狀態。如果是離線，我們立即停用按鈕但設定旗標，告訴恢復連線後自動啟動同步處理的 ConnectivityChanged 處理常式。

Altostratus 也會使用 Xamarin.Auth (tinyurl.com/xamauth) 來處理透過我們稍後會討論一下 OAuth 驗證的詳細資料。必須注意的是元件目前支援 iOS 和 Android 和不 Windows Phone 和不在我們的專案解決該特定的缺點的範圍內。所幸，用戶端應用程式只是順利執行未經驗證的認證，這只是表示使用者的設定不在雲端中維護並不完全最佳化與後端的資料交換。當元件取得更新來支援 Windows 中時，我們只需要移除 OnPlatform 標記中稍早所示顯示登入控制項的 XAML。

與後端驗證

在整個 Altostratus 應用程式，我們想要示範將某些使用者專屬的喜好設定儲存在後端後, 端可以自動套用這些喜好設定處理 HTTP 要求時所涉及的機制。這個特定的應用程式當然我們可以達成相同的結果只是 URI 參數使用要求，但這類範例不會做為更複雜的案例的基礎。將喜好設定儲存在伺服器上也能讓他們在所有使用者的裝置間漫遊。

若要使用任何一種使用者專屬資料表示驗證該唯一的使用者。這是提醒您，與授權不同。驗證是識別使用者和驗證的方式都是這些宣稱。授權相反地，與任何特定的使用者 (例如系統管理員與來賓與一般使用者) 所擁有的使用權限。

進行驗證，我們使用透過如 Google 和 Facebook、 協力廠商的社交登入而不實作我們自己的認證系統 (和後端的用戶端應用程式會透過此擷取組態] 頁面上 UI 的提供者清單的 API)。社交登入的主要優點是我們沒有處理認證或其服務員安全性和隱私問題。後端儲存只是電子郵件地址做為使用者名稱，及用戶端管理只存取權杖執行階段。否則提供者會苦差事，包括電子郵件驗證、 擷取密碼等等。

當然不是每個人都有與社交登入提供者的帳戶和某些使用者不想要使用社交媒體帳戶基於隱私原因。此外，社交登入不可能適用於特定業務應用程式。這種情況下我們建議 Azure Active Directory。針對本文目的，不過，它是邏輯的選擇因為我們只需要某些方法來驗證個別使用者。

一旦驗證、 授權使用者在後端儲存喜好設定。如果我們想要實作其他層級的授權 (例如修改其他使用者的喜好設定) 後, 端可以檢查權限的資料庫使用者名稱。

使用 ASP.NET Web API 中的社交登入的 OAuth2 OAuth2 (bit.ly/1SxC1AM) 是一種授權架構，可讓使用者授與存取權的資源，而不會共用他們的認證。它會定義數個"認證流程 」 指定認證各實體之間的傳遞方式。ASP.NET Web API 會使用所謂 「 隱含授與流程 」 在其中行動裝置應用程式不會收集認證也不會儲存任何機密資料。工作由 OAuth2 提供者和 ASP.NET 識別程式庫 (asp.net/identity) 分別。

若要啟用社交登入，您必須與每個透過其開發人員入口網站的登入提供者註冊您的應用程式。(「 應用程式 」 在此內容中的表示所有用戶端體驗，包括行動和 Web 和特別並沒有連到行動裝置應用程式)。註冊之後，提供者可讓您用唯一的用戶端識別碼和密碼。請參閱 bit.ly/1BniZ89 的一些範例。

我們使用這些值來初始化 ASP.NET Identity 中介軟體中所示 [圖 3。

[圖 3 初始化 ASP.NET 識別的中介軟體

var fbOpts = new FacebookAuthenticationOptions
{
  AppId = ConfigurationManager.AppSettings["FB_AppId"],
  AppSecret = ConfigurationManager.AppSettings["FB_AppSecret"]
};
fbOpts.Scope.Add("email");
app.UseFacebookAuthentication(fbOpts);
var googleOptions = new GoogleOAuth2AuthenticationOptions()
{
  ClientId = ConfigurationManager.AppSettings["GoogleClientID"],
  ClientSecret = ConfigurationManager.AppSettings["GoogleClientSecret"]
};
app.UseGoogleAuthentication(googleOptions);

像是"FB_AppID"字串是指向 Web 應用程式的環境和組態設定的金鑰儲存實際的識別碼和密碼。這可讓您不需要重建和重新部署應用程式更新它們。

使用 Xamarin.Auth 處理認證流動整體來說，社交驗證程序包含各種不同的應用程式、 後端和提供者之間的交握。幸好 Xamarin.Auth 元件 (適用的 Xamarin 元件存放區中) 處理大部分的應用程式。這包括使用瀏覽器控制項並提供回呼攔截讓應用程式可以回應完成授權時。

根據預設，Xamarin.Auth 有執行授權舞，這表示應用程式會儲存用戶端識別碼和密碼的某些部分用戶端應用程式。這是與 ASP.NET 流程稍有不同但 Xamarin.Auth 構造良好類別階層架構。Xamarin.Auth.OAuth2Authenticator 類別衍生自 WebRedirectAuthenticator，提供我們需要和要求我們編寫只有少量 (因為 Xamarin.Auth 還不能支援 Windows) 在 Android 和 iOS 專案中的 LoginPageRenderer.cs 檔案中找到的其他程式碼的基本功能。如需我們要的詳細資訊，請參閱我們的部落格文章， tinyurl.com/kboathalto。

然後，用戶端應用程式只需要了衍生自基底 ContentPage 的 Xamarin.Forms，讓我們可以瀏覽那里 LoginPage 類別。這個類別會公開兩個方法、 CompleteLoginAsync 和 CancelAsync，根據使用者的動作中提供者的 Web 介面 LoginPageRenderer 程式碼呼叫。

傳送驗證要求 後成功登入用戶端應用程式有一個存取權杖。若要讓已驗證的要求，它只包含該權杖就像這樣的授權標頭中:

GET http://hostname/api/UserPreferences HTTP/1.1
Authorization: Bearer I6zW8Dk...
Accept: */*
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko

"Bearer"，表示使用持有者權杖的授權之後這是長而不透明的語彙基元字串。

我們將驗證標頭加入至每個要求使用 System.Net.Http.HttpClient 程式庫的所有其餘要求與自訂訊息處理常式。訊息處理常式是外掛程式元件可讓您檢查和修改 HTTP 要求和回應訊息。若要深入了解，請參閱 bit.ly/1MyMMB8。

訊息處理常式類別 AuthenticationMessageHandler (webapi.cs) 中實作和建立 HttpClient 執行個體時安裝：

_httpClient = HttpClientFactory.Create(
  handler, new AuthenticationMessageHandler(provider));

ITokenProvider 介面只是從應用程式 (這類別所實作的 UserPreferences model.cs 中) 取得存取語彙基元處理常式。SendAsync 呼叫每個 HTTP 要求。做為 [圖 4 顯示，它會將權杖提供者是否要使用一個加入的授權標頭。

[圖 4 新增授權標頭

public interface ITokenProvider
{
  string AccessToken { get; }
}
class AuthenticationMessageHandler : DelegatingHandler
{
  ITokenProvider _provider;
  public AuthenticationMessageHandler(ITokenProvider provider)
  {
     _provider = provider;
  }
  protected override Task<HttpResponseMessage>
    SendAsync(HttpRequestMessage request,
    System.Threading.CancellationToken cancellationToken)
  {
    var token = _provider.AccessToken;
    if (!String.IsNullOrEmpty(token))
    {
      request.Headers.Authorization =
        new System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", token);
    }
    return base.SendAsync(request, cancellationToken);
  }
}

在後端中所述的本文中，第 1 部分語彙基元可能會收到要求，如果語彙基元會用來擷取該使用者的喜好設定和自動套用到其餘的要求。比方說，如果使用者設定交談限制為 25，而不是預設值是 100，然後最多 25 個項目將會傳回與要求，節省網路頻寬。

專為後端資料建置離線快取

行動裝置應用程式透過行動網頁的最大好處是支援離線使用的彈性。行動裝置應用程式，根據定義，則一律存在使用者的裝置上並可用於各種不同的資料儲存選項，例如 SQLite 維護離線資料快取而不需依賴瀏覽器為基礎的機制。

Altostratus 行動用戶端 UI 其實只是適用於本機 SQLite 資料庫中維護的資料讓應用程式而沒有連線功能完整。連線時，背景處理程序會從後端以更新資料庫擷取目前的資料。這樣會更新坐上方的資料庫會透過資料繫結會觸發 UI 更新的資料模型物件 (您可以看到此回 [圖 2)。在這種方式是在第 1 部分持續 webjobs 其中收集、 正規化和 SQL Server 資料庫中儲存資料，如此 Web API 可以服務直接從該資料庫的要求所討論的後端非常類似的架構。

離線支援 Altostratus 牽涉到三個不同的工作：

  • 將預先填入的資料庫檔案放置直接在應用程式套件不需要連線提供立即第一次執行工作的資料。
  • 在 UI 中實作取得呈現資料模型的每個部分的單向同步處理程序: 交談 (項目)、 類別、 驗證提供者和使用者喜好設定。
  • 連結到適當的觸發程序在 UI 中的 [重新整理] 按鈕之外的同步處理。

讓我們再看看每一種。

建立預先填入資料庫 也可讓使用者安裝應用程式從線上商店但不是執行直到稍後當裝置已離線。但問題是想說 「 抱歉，我們不能執行有用除非您在線上嗎? 」 的應用程式 或您想以智慧方式處理這種情況下您的應用程式嗎?

為了示範第二種方法，Altostratus 用戶端會直接在其上 (位於每個平台專案的資源/raw 資料夾) 的每個平台的應用程式套件中包含預先填入的 SQLite 資料庫。第一次執行用戶端將此資料庫檔案複製到裝置上的讀寫位置並再使用它從該處以獨佔方式。因為檔案複製程序是以每個平台唯一的我們會使用 Xamarin.Forms.DependencyService 功能來解決我們會定義介面的特定實作稱為 ISQLite，在執行階段。這是從 DataAccessLayer 建構函式 (DataAccess.cs) 中所示然後呼叫來擷取平台特定位置複製的讀寫資料庫檔案的 ISQLite.GetDatabasePath [圖 5。

[圖 5 擷取平台特定資料庫檔案的位置

public DataAccessLayer(SQLiteAsyncConnection db = null)
{
  if (db == null)
  {
    String path = DependencyService.Get<ISQLite>().GetDatabasePath();
    db = new SQLiteAsyncConnection(path);               
    // Alternate use to use the synchronous SQLite API:
    // database = SQLiteConnection(path);               
  }
  database = db;
  _current = this;
}

若要建立的初始資料庫，Altostratus 方案會包含呼叫 DBInitialize 小 Win32 主控台應用程式。它會使用相同的共用的 PCL 與應用程式使用資料庫，所以永遠不會有第二個、 不相符的程式碼基底的問題。DBInitialize，但是並不需要使用 DependencyService: 它只可以直接建立檔案並開啟連接：

string path = "Altostratus.db3";
SQLiteAsyncConnection conn = new SQLiteAsyncConnection(path);
var dbInit = new DataAccessLayer(conn);

從這裡 DBInitialize 呼叫 DataAccessLayer.InitAsync 以建立資料表 (某樣東西應用程式完全不需要使用預先填入資料庫)，並使用其他 DataAccessLayer 方法從後端取得資料。請注意與非同步呼叫 DBInitialize 只使用。就是間諜。因為它是主控台應用程式並不需要擔心 UI 回應性:

DataModel model = new DataModel(dbInit);
model.InitAsync().Wait();
model.SyncCategories().Wait();
model.SyncAuthProviders().Wait();
model.SyncItems().Wait();

授與使用者去看看，它會使用計時器將點放在螢幕上每半秒。

請注意您要一律檢查 SQLite DB 瀏覽器之類的工具在預先填入的資料庫 (bit.ly/1OCkm8Y) 之前提取至專案。可以針對一或多個 Web 要求失敗案例資料庫不是有效。您可以到 DBInitialize 建置此邏輯以便刪除的資料庫並顯示錯誤。在本例中，我們只再次監看錯誤訊息和執行程式，如有需要。

您可能會問，「 不會預先填入資料庫的內容移過期起來相當快嗎? 我可不希望我的應用程式的使用者看到第一次執行的真正過時的資料! 」 如果您不定期更新您的應用程式，這當然會是大小寫。因此您會想要認可到包含以合理目前的資料 (取決於您資料的本質) 資料庫的定期的應用程式更新。

如果使用者已安裝的應用程式，更新不會有任何影響，因為複製封裝的資料庫檔案的程式碼會檢查是否讀寫複本已經存在，而且只會使用該。不過，如果檔案存在是只有這類檢查，尚未執行一段時間的應用程式的使用者最後可能會啟動應用程式與較舊的資料比實際更最近已更新封裝中。您可以檢查快取資料庫的時間戳記是否舊中封裝以外並以較新的複本覆寫快取。這不是我們實作中 Altostratus，不過，因為我們還需要保留現有的資料庫的使用者喜好設定資訊。

與後端同步處理離線快取 Altostratus 用戶端如之前所述，一定會執行對其快取資料庫。所有的 Web 要求 (除了上傳新的使用者喜好設定) 的後端會發生同步處理快取的內容中。此機制是做為資料模型類別的一部分實作尤其是透過 sync.cs 中的四個方法: (這會將委派給在 model.cs Configuration.ApplyBack endConfiguration) SyncSettings、 SyncCategories、 SyncAuthProviders 和 SyncItems。清楚地群的主力 SyncItems，但我們將討論如何觸發所有這些下一節中。

請注意 Altostratus 同步處理資料僅針對單一方向從本機快取後端。此外，因為我們知道我們感興趣的資料不會變更所有快速 (指定的排程後端 webjobs)，我們關心只與後端資料存放區而不是更新順序分鐘或秒鐘的最終一致性。

每個同步處理程序基本上都一樣： 從後端擷取目前的資料、 使用新值更新本機資料庫、 從資料庫移除任何舊值和然後再重新填入要觸發 UI 更新的資料模型物件。

項目，沒有多一點的工作因為 SyncItems 可以叫用從 UI，而且我們想要防止過度興奮重複按下按鈕的使用者。私用 DataModel.syncTask 屬性會指出是否使用中的項目同步處理。如果 syncTask 為非 null，SyncItems 會忽略重複的要求。此外，由於項目要求可能會花一段時間且牽涉到較大的資料集，我們想要能夠取消項目同步處理裝置離線。若要這樣做，我們會儲存 System.Threading.CancellationToken 工作。

中顯示的私用 SyncItemsCore 方法 [圖 6, ，是處理程序的核心。它會從資料庫擷取的上次同步時間戳記和包含該與 Web 要求。

圖 6 私用 SyncItemsCore 方法

private async Task<SyncResult> SyncItemsCore()
{
  SyncResult result = SyncResult.Success;
  HttpResponseMessage response;
  Timestamp t = await DataAccessLayer.Current.GetTimestampAsync();
  String newRequestTimestamp =
    DateTime.UtcNow.ToString(WebAPIConstants.ItemsFeedTimestampFormat);
  response = await WebAPI.GetItems(t, syncToken);
  if (!response.IsSuccessStatusCode)
  {
    return SyncResult.Failed;
  }
  t = new Timestamp() { Stamp = newRequestTimestamp };
  await DataAccessLayer.Current.SetTimestampAsync(t);
  if (response.StatusCode == System.Net.HttpStatusCode.NoContent)
  {
    return SyncResult.NoContent;
  }
  var items = await response.Content.ReadAsAsync<IEnumerable<FeedItem>>();
  await ProcessItems(items);
  // Sync is done, refresh the ListView data source.
  await PopulateGroupedItemsFromDB();
  return result;
}

這樣的後端會傳回給定的時間是新的或更新這些項目。如此一來，用戶端取得真正需要的資料、 可能節省使用者的限制資料計劃。這也表示用戶端處理的資料較少的工作會從每個要求，也節省電池電力和網路流量降至最低。雖然這聽起來不像是很多，處理每個類別而不是五個交談說 50，與每個要求是減少 90%。在 20 至 30 每天同步處理這可以輕易地在一個月只是一個應用程式中加入多達數百 mb。簡單地說，您的客戶一定會喜歡您對好讓流量最佳化工作!

一旦要求恢復 ProcessItems 方法會將所有這些項目加入資料庫進行小小的標題 (例如移除智慧型引號) 清除和擷取的主要清單中顯示的描述主體的前 100 個字元。標題清除是我們反而進行後端可能會在用戶端上儲存一點點的處理時間。我們選擇要保留在用戶端因為其他案例可能需要執行平台特定的調整。我們也可以建立 100 個字元描述，這就是儲存的小小的用戶端處理但增加的網路流量的後端。我們正在使用此資料，可能是偶數的缺點和因為 UI 最終是用戶端的責任，似乎比較好控制執行此步驟中的保留用戶端使用。(如需有關這和一些其他 UI 考量的詳細資訊，請參閱我們的部落格文章 tinyurl.com/kboathaltoxtra。)

一旦我們已經將項目新增至資料庫、 資料模型群組會透過 PopulateGroupedItemsFromDB 重新整理。以下是一定要了解資料庫可能有更多使用者的目前交談限制設定為必要項。PopulateGroupedItemsFromDB 帳戶這藉由套用該限制直接對資料庫查詢。

不過，經過一段時間，我們不想要保留藉由保留一大堆將永遠不會再次顯示的項目展開的資料庫。為此，SyncItems 會呼叫的方法 DataAccessLayer.ApplyConversationLimit 到選出從資料庫的舊項目之前的項目數目符合指定的限制。由於 Altostratus 資料集內的任何個別項目的大小是相對較小，我們使用 100 不論使用者的目前設定的最大的交談限制。如此一來，如果使用者就會引發該限制，我們不必再次從後端要求資料。如果我們有更大的資料項目，不過，它可能會更具意義積極選出資料庫並在需要時再次要求項目。

同步處理觸發程序 重新整理] 按鈕在 UI 中的顯然是主要方式的項目同步處理發生時，但其他同步處理序何時會發生嗎? 以及是否有項目同步的其他觸發程序吗？

因為所有呼叫同步 * 方法會都發生在一個地方，HomeViewModel.Sync 方法是有點難回答這些問題的程式碼。不過，這個方法和次要的進入點 HomeViewModel.CheckTimeAndSync，是從各種不同的其他地方呼叫。當位置和方式呼叫同步處理會參數化 SyncExtent 列舉的值如下的摘要:

  • 在啟動時會 HomeViewModel 建構函式會呼叫 Sync(SyncExtent.All)，以便在同步處理會完全在幕後使用防火牆和忘記的模式。模式就是從非同步方法的傳回值儲存到一個本機變數來隱藏有關未使用的編譯器警告 await 這裡。
  • 內部連線隨插即用中的 ConnectivityChanged 事件處理常式中，我們會呼叫同步如果裝置已離線 (然後要求使用相同的範圍) 進行前一次呼叫時。
  • 如果使用者造訪 [組態] 頁面並進行變更為作用中的類別目錄或交談的限制，或登入後端，因此適用於從後端設定，這件事是，記住 DataModel.Configuration.HasChanged 旗標。當使用者回到首頁時，HomePage.OnAppearing 處理常式會呼叫 HomeViewModel.CheckRefresh 檢查 HasChanged 並視需要呼叫 Sync(SyncExtent.Items)。
  • 時間長度已暫止應用程式根據 App.OnResume 事件 (app.cs) 呼叫 CheckTimeAndSync，適用於某個邏輯來決定應該進行同步處理。很明顯地，這些條件是取決於您的資料和後端作業的本質。
  • 最後，重新整理] 按鈕會呼叫 CheckTimeAndSync 一定要至少一個項目同步處理的旗標。因為可能會重新整理] 按鈕會使用 CheckTimeAndSync — 雖然相當罕見 — 使用者可能會保留應用程式執行前景中多個半小時或甚至一天，在此情況下重新整理] 按鈕也應當依照其他同步跟我們繼續時。

將所有項目合併成 HomeViewModel.Sync 的優點是它可以在適當的時間設定公用 HomeViewModel.IsSyncing 屬性。這個屬性是資料繫結至的 IsVisible 和 IsRunning Xamarin.Forms.ActivityIndicator Home.xaml 中的屬性。設定這個旗標的簡單動作控制該指標的可見性。

使用 Xamarin 建置在 TFS 和 Visual Studio Online

讓我們 Altostratus 專案的使用是有點常見的跨平台工作的開發環境: Windows PC 模擬器和共用連線的裝置對 Android 和 Windows Phone 和 iOS 模擬器和共用連線的 iOS 裝置的本機 Mac OS X 電腦 (請參閱 [圖 7)。您可以使用這類安裝程式，進行所有的開發與直接在 PC、 Mac OS X 電腦使用遠端 iOS 組建和偵錯上的 Visual Studio 內偵錯工作。存放區專用 iOS 應用程式可以再也從提交 mac 有關。

A 通用跨平台的開發環境 Xamarin 專案以及那些使用 Visual Studio 工具等其他技術的 Apache Cordova
[圖 7 A 通用跨平台的開發環境 Xamarin 專案以及那些使用 Visual Studio 工具等其他技術的 Apache Cordova

我們運用 Visual Studio Online 小組共同作業與原始檔控制和設定為連續整合組建後端和 Xamarin 用戶端。我們必須立即啟動這個專案，我們就能夠使用最新的 Visual Studio Online 建置系統來建置 Xamarin 應用程式直接在裝載的組建控制器。您可以找出從我們的部落格文章，取得更多 tinyurl.com/kboauthxamvso。稍早在 2015年但是裝載的組建控制器還沒有這項支援。幸運的是，它就很簡單 — 老實說!--若要使用 Visual Studio online 組建控制器執行 TFS 的本機電腦。在該伺服器上我們要安裝免費 TFS Express edition 以及 Xamarin 的必要 Android 和 Windows 平台 Sdk，並確認其 c:\android-sdk 組建帳戶無法存取此位置中放置 Android SDK。(它的安裝程式預設會將 SDK 中目前使用者的儲存體組建帳戶沒有權限)。 這會討論 Xamarin 文件、 「 設定 Team Foundation Server 的 Xamarin，" bit.ly/1OhQPSW。

一旦完全設定組建伺服器，下列步驟會建立連接至 Visual Studio Online (請參閱 「 部署和設定組建伺服器 」，網址 bit.ly/1RJS4QL):

  1. 開啟 TFS 管理主控台。
  2. 在左側導覽窗格中，展開伺服器名稱並選取組建組態。
  3. 按一下 [組建服務屬性] 以開啟 [組建服務屬性] 對話方塊。
  4. 按一下 [停止服務] 對話方塊的頂端。
  5. 通訊] 下提供的組建服務專案集合底下的方塊中輸入您的 Visual Studio Online 集合，例如 https://<your 帳戶的 URL >.visualstudio.com/defaultcollection。
  6. 按一下 [重新啟動服務] 對話方塊底部的 [開始] 按鈕。

這就是它只要 ！ 當您建立組建定義 Visual Studio Team 總管] 中時，連接至 Visual Studio Online 的 TFS 機器會出現在可用的組建控制器清單。藉由選取的選項，您從 Visual Studio 或排入佇列的組建會排入佇列時簽入將會路由至 TFS 機器。

總結

我們希望您喜歡這次我們討論 Altostratus 專案您可以找到程式碼幫助您自己行動、 雲端連接應用程式。同樣地，此專案中，我們的目的是明顯的範例的跨平台行動裝置應用程式提供自訂的後端可以執行大量工作代表用戶端來最佳化必須這麼做在用戶端直接的工作。藉由一律執行回代表所有的用戶端結束收集資料，我們能大幅降低用戶端產生網路流量 (及資料計劃及其後續對影響) 數量。透過標準化不同來源的資料，我們最小化節省曾經重要的電池電力用戶端所需的資料處理量。而且藉由驗證與後端的使用者，我們示範了如何就能夠儲存有使用者喜好設定，並讓它們自動套用到用戶端互動的後端再次最佳化網路流量和處理需求。我們了解我們的特定需求可能會有更簡便的方法來達到相同的效果，但我們想要建立範例會調整為更複雜的案例。

我們很希望聽到您對此專案的想法。讓我們知道!

Azure 的離線同步處理

實作離線快取的替代方案是 Azure 離線同步對於資料表而言也就是 Azure 行動服務的一部分。這就不需要任何同步處理程式碼撰寫，並從用戶端的變更推送至伺服器的運作方式。因為它會使用資料表儲存體，但是它並不提供關聯式資料模型 SQLite 一樣。

Kraig Brockschmidt 擔任 Microsoft 的資深內容開發人員和致力於跨平台的行動應用程式。他是 「 HTML、 CSS 及 JavaScript 程式設計 Windows 市集應用程式 」 的作者 (兩個版本) 從 Microsoft Press 和部落格上的 kraigbrockschmidt.com。

Mike Wasson 是 microsoft 的內容開發人員。多年來，他記錄了 Win32 的多媒體 Api。他目前撰寫有關 Microsoft Azure 和 ASP.NET。

Rick Anderson 擔任 Microsoft 著重在 ASP.NET MVC、 Microsoft Azure 和 Entity Framework 的資深程式設計作家。您可以依照他在 Twitter 上 twitter.com/RickAndMSFT。

Erik Reitan 是 microsoft 的資深內容開發人員。他擅長 Microsoft Azure 和 ASP.NET。在 Twitter 上追隨他 twitter.com/ReitanErik。

Tom Dykstra是將焦點放在 Microsoft Azure 和 ASP.NET 的 microsoft 的資深內容開發人員。

衷心感謝以下技術專家對本文的審閱: Michael Collier、 Brady Gaster、 John de Havilland、 Ryan Jones、 Vijay Ramakrishnan 和 Pranav Rastogi