Megosztás a következőn keresztül:

A felügyelt ügyfelek használata az Azure Mobile Apps-alkalmazásokhoz

  • Cikk

Áttekintés

Ez az útmutató bemutatja, hogyan hajt végre gyakori forgatókönyveket a felügyelt ügyféloldali kódtár használatával a Azure App Service Mobile Apps és Windows Xamarin-alkalmazásokhoz. Ha még csak most Mobile Apps, érdemes először az Azure Mobile Apps oktatóanyagot . Ebben az útmutatóban az ügyféloldali felügyelt SDK-ra összpontosítunk. Az alkalmazáshoz készült kiszolgálóoldali SDK-król Mobile Apps .NET Server SDK vagy a Node.js Server SDK dokumentációjában talál további információt.

Referenciadokumentáció

Az ügyfélOLDALI SDK referenciadokumentációja itt található: Azure Mobile Apps .NET-ügyfélre vonatkozó referencia. Több ügyfélmintát is találhat az Azure-Samples GitHub tárházban.

Támogatott platformok

A .NET platform a következő platformokat támogatja:

  • Xamarin Android-kiadások az API 19-től 24-ig (KitKat–Nougat)
  • Xamarin iOS-kiadások iOS 8.0-s és újabb verziókhoz
  • Univerzális Windows-platform
  • Windows Phone 8.1
  • Windows Phone-telefon Silverlight-alkalmazások kivételével 8.0-s vagy

A "server-flow" hitelesítés WebView-t használ a bemutatott felhasználói felületen. Ha az eszköz nem tudja bemutatni a WebView felhasználói felületét, akkor más hitelesítési módszerekre van szükség. Ez az SDK tehát nem alkalmas watch típusú vagy hasonlóan korlátozott eszközökhöz.

Beállítás és előfeltételek

Feltételezzük, hogy már létrehozta és közzétette a Mobile App háttérprojektjét, amely legalább egy táblát tartalmaz. A témakörben használt kódban a tábla neve, TodoItem és a következő oszlopokat tartalmazza: Id, Textés Complete. Ez a tábla ugyanaz a tábla, amely az Azure Mobile Apps befejezésekor jött létre.

A C#-ban a megfelelő típusos ügyféloldali típus a következő osztály:

public class TodoItem
{
    public string Id { get; set; }

    [JsonProperty(PropertyName = "text")]
    public string Text { get; set; }

    [JsonProperty(PropertyName = "complete")]
    public bool Complete { get; set; }
}

A JsonPropertyAttribute attribútummal definiálhatja a PropertyName leképezést az ügyfélmező és a táblamező között.

A táblák háttérkiszolgálón való létrehozásáról Mobile Apps .NET Server SDK témakörben vagy a Node.js Server SDK témakörben olvashat. Ha a Mobile App háttéralkalmazást a Azure Portal a gyorsútmutatóval hozta létre, az Egyszerű táblák beállítást is használhatja a Azure Portal.

How to: Install the managed client SDK package (A felügyelt ügyfél SDK-csomag telepítése)

Az alábbi módszerek egyikével telepítheti a nugetről Mobile Apps ügyféloldali SDK-csomagot:

  • Visual Studio kattintson a jobb gombbal a projektre, kattintson a Manage NuGet Packages (NuGet-csomagok kezelése) elemre, Microsoft.Azure.Mobile.Client keresse meg a csomagot, majd kattintson a Install (Telepítés) gombra.
  • Xamarin Studio Kattintson a jobb gombbal a projektre, kattintson az AddAdd>NuGet Packages (NuGet-csomagok hozzáadása) elemre, Microsoft.Azure.Mobile.Client keresse meg a csomagot, majd kattintson a Add Package (Csomag hozzáadása) parancsra.

A fő tevékenységfájlban ne felejtse el hozzáadni a következő using utasítást :

using Microsoft.WindowsAzure.MobileServices;

Megjegyzés

Vegye figyelembe, hogy az Android-projektjében hivatkozott összes támogatási csomagnak azonos verziójúnak kell lennie. Az SDK az Xamarin.Android.Support.CustomTabs Android platformtól függ, így ha a projekt újabb támogatási csomagokat használ, az ütközések elkerülése érdekében közvetlenül a szükséges verzióval kell telepítenie ezt a csomagot.

How to: Work with debug symbols in Visual Studio

A Microsoft.Azure.Mobile névtér szimbólumai a SymbolSource-on érhetők el. A SymbolSource és az alkalmazás integrálásához tekintse meg a SymbolSource Visual Studio.

A Mobile Apps létrehozása

A következő kód létrehozza a MobileServiceClient objektumot, amely a Mobile App-háttéralkalmazás eléréséhez szükséges.

var client = new MobileServiceClient("MOBILE_APP_URL");

Az előző kódban MOBILE_APP_URL cserélje le a helyére a Mobile App háttéralkalmazás URL-címét, amely a mobil-háttéralkalmazás panelén található a Azure Portal. A MobileServiceClient objektumnak egyszeresnek kell lennie.

Táblákkal való munka

A következő szakasz részletesen bemutatja, hogyan kereshet és olvashat be rekordokat, és módosíthatja a táblában található adatokat. A következő témaköröket fedi le:

Útmutató: Táblahivatkozás létrehozása

A háttértáblákban található adatokhoz hozzáférő vagy módosító összes kód függvényeket hív meg az objektumon MobileServiceTable . Szerezzen be egy hivatkozást a táblára a GetTable metódus hívásával az alábbiak szerint:

IMobileServiceTable<TodoItem> todoTable = client.GetTable<TodoItem>();

A visszaadott objektum a típusos szerializálási modellt használja. A nem típusos szerializálási modell is támogatott. Az alábbi példa egy nem típusos táblára hivatkozik:

// Get an untyped table reference
IMobileServiceTable untypedTodoTable = client.GetTable("TodoItem");

A nem típusos lekérdezésekben meg kell adnia a mögöttes OData-lekérdezési sztringet.

How to: Query data from your Mobile App

Ez a szakasz azt ismerteti, hogyan küldhet lekérdezéseket a Mobile App háttéralkalmazásának, amely a következő funkciókat tartalmazza:

Megjegyzés

A kiszolgálóalapú lapméret kényszerítve van, hogy ne ad vissza minden sort. A lapozás megakadályozza, hogy a nagy adatkészletek alapértelmezett kérései negatív hatással vannak a szolgáltatásra. 50-esnél több sor visszaadása érdekében használja a Skip és Take a metódust az adatok visszaadása az oldalakon leírás szerint.

How to: Filter returned data (Hogyan lehet: A visszaadott adatok szűrése)

Az alábbi kód bemutatja, hogyan szűrheti az adatokat egy záradék lekérdezésbe Where való be- és bemutatja. Visszaadja az összes olyan elemet todoTable , amelynek Complete tulajdonsága egyenlő a értékekkel false. A Where függvény sorszűrés predikátumát alkalmaz a tábla lekérdezésére.

// This query filters out completed TodoItems and items without a timestamp.
List<TodoItem> items = await todoTable
    .Where(todoItem => todoItem.Complete == false)
    .ToListAsync();

A háttérnek küldött kérés URI-ját üzenetvizsgálati szoftverrel, például böngészőfejlesztői eszközökkel vagy a Fiddlerrel is megtekintheti. Ha megnézi a kérelem URI-ét, figyelje meg, hogy a lekérdezési sztring módosult:

GET /tables/todoitem?$filter=(complete+eq+false) HTTP/1.1

Ezt az OData-kérést a SQL SDK által lekért lekérdezésekbe fordítja le:

SELECT *
    FROM TodoItem
    WHERE ISNULL(complete, 0) = 0

A metódusnak átadott Where függvény tetszőleges számú feltételt is kaphat.

// This query filters out completed TodoItems where Text isn't null
List<TodoItem> items = await todoTable
    .Where(todoItem => todoItem.Complete == false && todoItem.Text != null)
    .ToListAsync();

Ezt a példát a Server SDK SQL lekérdezéseként fordítja le:

SELECT *
    FROM TodoItem
    WHERE ISNULL(complete, 0) = 0
          AND ISNULL(text, 0) = 0

Ez a lekérdezés több záradékra is felosztható:

List<TodoItem> items = await todoTable
    .Where(todoItem => todoItem.Complete == false)
    .Where(todoItem => todoItem.Text != null)
    .ToListAsync();

A két módszer egyenértékű, és felcserélhető. Az előző lehetőség – több predikátum összefésülése egyetlen lekérdezésben – tömörebb és ajánlottabb.

A Where záradék támogatja az OData részkészletre lefordított műveleteket. A műveletek a következők:

  • Relációs operátorok (==, !=, <, = <, , >, >=),
  • Aritmetikai operátorok (+, -, /, *, %),
  • Szám pontossága (Math.Floor, Math.Ceiling),
  • Sztringf függvények (Length, Substring, Replace, IndexOf, StartsWith, EndsWith),
  • Dátumtulajdonságok (Év, Hónap, Nap, Óra, Perc, Másodperc),
  • Egy objektum tulajdonságainak elérése, és
  • Ezen műveletek bármelyikét kombináló kifejezések.

A Server SDK által támogatott szolgáltatásokkal kapcsolatban érdemes megfontolni az OData v3 dokumentációját.

How to: Sort returned data (Hogyan: A visszaadott adatok rendezése)

Az alábbi kód bemutatja, hogyan rendezheti az adatokat egy OrderBy vagy OrderByDescending függvény lekérdezésbe való beiklével. Elemeket ad vissza a todoTable mező alapján növekvő sorrendbe rendezve Text .

// Sort items in ascending order by Text field
MobileServiceTableQuery<TodoItem> query = todoTable
                .OrderBy(todoItem => todoItem.Text)
List<TodoItem> items = await query.ToListAsync();

// Sort items in descending order by Text field
MobileServiceTableQuery<TodoItem> query = todoTable
                .OrderByDescending(todoItem => todoItem.Text)
List<TodoItem> items = await query.ToListAsync();

How to: Return data in pages (Hogyan lehet: Adatok visszaadása oldalakon)

Alapértelmezés szerint a háttér csak az első 50 sort adja vissza. A visszaadott sorok számát a Take metódus hívásával növelheti . A Take Skip metódussal együtt használva a lekérdezés által visszaadott teljes adatkészlet egy adott "lapját" kérheti le. A következő lekérdezés végrehajtásakor a tábla első három elemét adja vissza.

// Define a filtered query that returns the top 3 items.
MobileServiceTableQuery<TodoItem> query = todoTable.Take(3);
List<TodoItem> items = await query.ToListAsync();

A következő átdolgozott lekérdezés kihagyja az első három eredményt, és visszaadja a következő három eredményt. Ez a lekérdezés az adatok második "lapját" állítja elő, ahol az oldalméret három elem.

// Define a filtered query that skips the top 3 items and returns the next 3 items.
MobileServiceTableQuery<TodoItem> query = todoTable.Skip(3).Take(3);
List<TodoItem> items = await query.ToListAsync();

Az IncludeTotalCount metódus lekérte az összes visszaadott rekord teljes számát, figyelmen kívül hagyva a megadott lapozási/korlátozási záradékokat:

query = query.IncludeTotalCount();

Valós alkalmazásokban az előző példához hasonló lekérdezéseket lapozó vezérlőelemekkel vagy hasonló felhasználói felülettel használhat az oldalak közötti navigáláshoz.

Megjegyzés

Ha felül szeretné bírálni az 50 soros korlátot egy Mobile App-háttéralkalmazásban, az EnableQueryAttribute metódust is alkalmaznia kell a nyilvános GET metódusra, és meg kell adnia a lapozási viselkedést. A metódusra alkalmazva a következő állítja be a visszaadott sorok maximális számát 1000-re:

[EnableQuery(MaxTop=1000)]

How to: Select specific columns (Hogyan lehet: Adott oszlopok kiválasztása)

Egy Select záradék lekérdezéshez való hozzáadásával megadhatja, hogy mely tulajdonságokat foglalja bele az eredményekbe. Az alábbi kód például bemutatja, hogyan választhat ki csak egy mezőt, és hogyan jelölhet ki és formázhat több mezőt:

// Select one field -- just the Text
MobileServiceTableQuery<TodoItem> query = todoTable
                .Select(todoItem => todoItem.Text);
List<string> items = await query.ToListAsync();

// Select multiple fields -- both Complete and Text info
MobileServiceTableQuery<TodoItem> query = todoTable
                .Select(todoItem => string.Format("{0} -- {1}",
                    todoItem.Text.PadRight(30), todoItem.Complete ?
                    "Now complete!" : "Incomplete!"));
List<string> items = await query.ToListAsync();

Az eddig ismertetett összes függvény additív, így tovább láncolhatja őket. Minden láncolt hívás nagyobb hatással van a lekérdezésre. Még egy példa:

MobileServiceTableQuery<TodoItem> query = todoTable
                .Where(todoItem => todoItem.Complete == false)
                .Select(todoItem => todoItem.Text)
                .Skip(3).
                .Take(3);
List<string> items = await query.ToListAsync();

How to: Look up data by ID

A LookupAsync függvény használatával objektumokat lehet keresni az adatbázisból egy adott azonosítóval.

// This query filters out the item with the ID of 37BBF396-11F0-4B39-85C8-B319C729AF6D
TodoItem item = await todoTable.LookupAsync("37BBF396-11F0-4B39-85C8-B319C729AF6D");

How to: Execute untyped queries (Hogyan lehet: Nem típusos lekérdezések végrehajtása)

Ha nem típusos táblaobjektummal hajt létre lekérdezést, explicit módon meg kell adnia az OData lekérdezési sztringet a ReadAsync hívásával, az alábbi példában látható módon:

// Lookup untyped data using OData
JToken untypedItems = await untypedTodoTable.ReadAsync("$filter=complete eq 0&$orderby=text");

Olyan JSON-értékeket kap vissza, amelyek tulajdonságos csomagként használhatók. A JToken és a Newtonsoft Json.NET a Json.NET oldalán.

How to: Insert data into a Mobile App backend (How to: Insert data into a Mobile App backend (How to: Insert data into a Mobile App backend

Minden ügyféltípusnak tartalmaznia kell egy Id nevű tag, amely alapértelmezés szerint egy sztring. Ez az azonosító CRUD-műveletek végrehajtásához és offline szinkronizáláshoz szükséges. Az alábbi kód bemutatja, hogyan szúr be új sorokat egy táblába az InsertAsync metódussal. A paraméter tartalmazza a .NET-objektumként beszúrni kívánt adatokat.

await todoTable.InsertAsync(todoItem);

Ha a beszúrás todoItem során nem szerepel egyedi egyéni azonosító érték, a kiszolgáló létrehoz egy GUID azonosítót. A létrehozott azonosítót a hívás visszatérése után megvizsgálva kaphatja meg az objektumot.

Nem típusos adatok beszúrása érdekében a következő előnyöket Json.NET:

JObject jo = new JObject();
jo.Add("Text", "Hello World");
jo.Add("Complete", false);
var inserted = await table.InsertAsync(jo);

Az alábbi példa egy e-mail-címet használ egyedi sztringazonosítóként:

JObject jo = new JObject();
jo.Add("id", "myemail@emaildomain.com");
jo.Add("Text", "Hello World");
jo.Add("Complete", false);
var inserted = await table.InsertAsync(jo);

Azonosítóértékek munkavégzése

Mobile Apps egyéni sztringértékeket támogat a tábla azonosító oszlopához . A sztringértékek lehetővé teszik, hogy az alkalmazások egyéni értékeket, például e-mail-címeket vagy felhasználóneveket használjanak az azonosítóhoz. A sztringek az alábbi előnyöket biztosítják:

  • Az adatbázishoz való adatátteknés nélkül jönnek létre az adatok.
  • A rekordok könnyebben egyesíthetők különböző táblákból vagy adatbázisokból.
  • Az ID-értékek jobban integrálhatók az alkalmazás logikájában.

Ha a sztringazonosító értéke nincs beszúrt rekordban, a Mobile App háttéralkalmazása egyedi értéket hoz létre az azonosítóhoz. A Guid.NewGuid metódussal saját azonosítóértékeket hozhat létre az ügyfélen vagy a háttérben.

JObject jo = new JObject();
jo.Add("id", Guid.NewGuid().ToString("N"));

How to: Modify data in a Mobile App backend (How to: Modify data in a Mobile App backend )How to: Modify data in a Mobile App backend

A következő kód bemutatja, hogyan frissítheti az UpdateAsync metódussal egy meglévő rekordot ugyanazokkal az azonosítóval új információkkal. A paraméter a .NET-objektumként frissíthető adatokat tartalmazza.

await todoTable.UpdateAsync(todoItem);

A nem típusos adatok frissítéséhez az alábbi Json.NET használhatja:

JObject jo = new JObject();
jo.Add("id", "37BBF396-11F0-4B39-85C8-B319C729AF6D");
jo.Add("Text", "Hello World");
jo.Add("Complete", false);
var inserted = await table.UpdateAsync(jo);

A id frissítéshez meg kell adni egy mezőt. A háttér a mező alapján id azonosítja, hogy melyik sort kell frissíteni. A id mező a hívás eredményének eredménye alapján szerezhető InsertAsync be. A ArgumentException érték akkor áll elő, ha az érték megtétele nélkül próbál frissíteni egy id elemet.

How to: Delete data in a Mobile App backend (How to: Delete data in a Mobile App backend )How to: Delete data in a Mobile App backend

Az alábbi kód bemutatja, hogyan használható a DeleteAsync metódus egy meglévő példány törlésére. A példányt a mezője id azonosítja todoItem.

await todoTable.DeleteAsync(todoItem);

A nem típusos adatok törléséhez az alábbi Json.NET használhatja:

JObject jo = new JObject();
jo.Add("id", "37BBF396-11F0-4B39-85C8-B319C729AF6D");
await table.DeleteAsync(jo);

Törlési kérés esetén meg kell adni egy azonosítót. Más tulajdonságokat a rendszer nem ad át a szolgáltatásnak, vagy figyelmen kívül hagyja őket a szolgáltatásnál. A hívás eredménye DeleteAsync általában null. A átadható azonosító a hívás eredményének eredménye alapján szerezhető InsertAsync be. A MobileServiceInvalidOperationException akkor ad vissza értéket, ha a mező megadása nélkül próbál törölni egy id elemet.

How to: Use Optimistic Concurrency for conflict resolution (Az optimista egyidejűség használata ütközésfeloldáshoz)

Két vagy több ügyfél egyszerre írhat módosításokat ugyanabba az elembe. Ütközésészlelés nélkül az utolsó írás felülírná a korábbi frissítéseket. Az optimista egyidejűség-vezérlés feltételezi, hogy minden tranzakció véglegesítésre képes, ezért nem használ erőforrás-zárolást. A tranzakciók véglegesítése előtt az optimista egyidejűség-vezérlés ellenőrzi, hogy más tranzakció nem módosította-e az adatokat. Ha az adatok módosultak, a véglegesítési tranzakció vissza lesz gördülve.

Mobile Apps támogatja az optimista version egyidejűség-vezérlést az egyes elemek változásainak nyomon követésével a Mobile App-háttérrendszer minden táblája számára meghatározott rendszertulajdonság-oszlop használatával. A rekord minden egyes frissítésekor a Mobile Apps új értékre version állítja a rekord tulajdonságát. Az egyes frissítési kérések során version a rendszer összehasonlítja a kérésben szereplő rekord tulajdonságát a kiszolgálón található rekord ugyanazon tulajdonságával. Ha a kéréssel átadott verzió nem egyezik a háttéralkalmazással, akkor az ügyféloldali kódtár kivételt jelent MobileServicePreconditionFailedException<T> . A kivételben szereplő típus a rekord kiszolgálóverzióját tartalmazó háttérből származó rekord. Az alkalmazás ezután ezen információk alapján version eldöntheti, hogy végrehajtja-e újra a frissítési kérést a háttérből származó megfelelő értékkel a módosítások véglegesítéséhez.

Definiálhat egy oszlopot a rendszertulajdonság version táblaosztályán az optimista egyidejűség engedélyezéséhez. Például:

public class TodoItem
{
    public string Id { get; set; }

    [JsonProperty(PropertyName = "text")]
    public string Text { get; set; }

    [JsonProperty(PropertyName = "complete")]
    public bool Complete { get; set; }

    // *** Enable Optimistic Concurrency *** //
    [JsonProperty(PropertyName = "version")]
    public string Version { set; get; }
}

A nem típusos táblákat használó alkalmazások az alábbiak szerint engedélyezik az optimista VersionSystemProperties egyidejűséget.

//Enable optimistic concurrency by retrieving version
todoTable.SystemProperties |= MobileServiceSystemProperties.Version;

Az optimista egyidejűség-engedélyezés MobileServicePreconditionFailedException<T> mellett a kódban is ki kell kapnia a kivételt az UpdateAsync hívása során. Az ütközés feloldásához alkalmazza a megfelelőt version a frissített rekordra, és hívja meg az UpdateAsync metódust a feloldott rekordhoz. Az alábbi kód bemutatja, hogyan oldható fel írási ütközés az észlelés után:

private async void UpdateToDoItem(TodoItem item)
{
    MobileServicePreconditionFailedException<TodoItem> exception = null;

    try
    {
        //update at the remote table
        await todoTable.UpdateAsync(item);
    }
    catch (MobileServicePreconditionFailedException<TodoItem> writeException)
    {
        exception = writeException;
    }

    if (exception != null)
    {
        // Conflict detected, the item has changed since the last query
        // Resolve the conflict between the local and server item
        await ResolveConflict(item, exception.Item);
    }
}


private async Task ResolveConflict(TodoItem localItem, TodoItem serverItem)
{
    //Ask user to choose the resolution between versions
    MessageDialog msgDialog = new MessageDialog(
        String.Format("Server Text: \"{0}\" \nLocal Text: \"{1}\"\n",
        serverItem.Text, localItem.Text),
        "CONFLICT DETECTED - Select a resolution:");

    UICommand localBtn = new UICommand("Commit Local Text");
    UICommand ServerBtn = new UICommand("Leave Server Text");
    msgDialog.Commands.Add(localBtn);
    msgDialog.Commands.Add(ServerBtn);

    localBtn.Invoked = async (IUICommand command) =>
    {
        // To resolve the conflict, update the version of the item being committed. Otherwise, you will keep
        // catching a MobileServicePreConditionFailedException.
        localItem.Version = serverItem.Version;

        // Updating recursively here just in case another change happened while the user was making a decision
        UpdateToDoItem(localItem);
    };

    ServerBtn.Invoked = async (IUICommand command) =>
    {
        RefreshTodoItems();
    };

    await msgDialog.ShowAsync();
}

További információkért lásd az Offline adatszinkronizálás az Azure-ban Mobile Apps témakört.

Útmutató: Mobile Apps kötése egy Windows felhasználói felülethez

Ez a szakasz bemutatja, hogyan jeleníthető meg a visszaadott adatobjektumok felhasználói felületi elemek használatával egy Windows alkalmazásban. Az alábbi példakód a hiányos elemekre vonatkozó lekérdezéssel köti össze a lista forrását. A MobileServiceCollection egy Mobile Apps kötőgyűjteményt hoz létre.

// This query filters out completed TodoItems.
MobileServiceCollection<TodoItem, TodoItem> items = await todoTable
    .Where(todoItem => todoItem.Complete == false)
    .ToCollectionAsync();

// itemsControl is an IEnumerable that could be bound to a UI list control
IEnumerable itemsControl  = items;

// Bind this to a ListBox
ListBox lb = new ListBox();
lb.ItemsSource = items;

A felügyelt futásidő egyes vezérlői támogatják az ISupportIncrementalLoading nevű felületet. Ez a felület lehetővé teszi, hogy a vezérlők további adatokat kérjenek, amikor a felhasználó görget. Ez a felület beépített támogatást nyújt az univerzális Windows-alkalmazásokhoz a MobileServiceIncrementalLoadingCollection használatával, amely automatikusan kezeli a vezérlők hívásait. Használja MobileServiceIncrementalLoadingCollection a Windows alkalmazásokban a következőképpen:

MobileServiceIncrementalLoadingCollection<TodoItem,TodoItem> items;
items = todoTable.Where(todoItem => todoItem.Complete == false).ToIncrementalLoadingCollection();

ListBox lb = new ListBox();
lb.ItemsSource = items;

Ha az új gyűjteményt a 8. Windows Phone-telefon "Silverlight" ToCollection alkalmazásokon is használni, használja a bővítménymetúra-metódusokat a és IMobileServiceTableQuery<T> a alkalmazásbanIMobileServiceTable<T>. Az adatok betöltéséhez hívja meg a hívást LoadMoreItemsAsync().

MobileServiceCollection<TodoItem, TodoItem> items = todoTable.Where(todoItem => todoItem.Complete==false).ToCollection();
await items.LoadMoreItemsAsync();

Ha a vagy a hívása segítségével ToCollectionAsyncToCollectionlétrehozott gyűjteményt használja, a felhasználói felület vezérlőihez kötött gyűjteményt kap. Ez a gyűjtemény lapozást tudó. Mivel a gyűjtemény adatokat tölt be a hálózatról, a betöltés néha meghiúsul. Az ilyen hibák kezeléshez bírálja felül a OnException metódusát MobileServiceIncrementalLoadingCollection a hívásaiból eredő kivételek kezelésével LoadMoreItemsAsync.

Fontolja meg, hogy a táblában sok mező található-e, de csak néhányat szeretne megjeleníteni a vezérlőben. A felhasználói felületen megjelenítendő oszlopok kiválasztásához használhatja az előző , "Megadott oszlopok kiválasztása" című szakasz útmutatását.

Oldalméret módosítása

Az Azure Mobile Apps alapértelmezés szerint legfeljebb 50 elemet ad vissza kérésenként. A lapozás méretét úgy módosíthatja, hogy az ügyfélen és a kiszolgálón is megnöveli a maximális oldalméretet. A kért oldalméret növeléséhez adja meg a értéket PullOptions a használata esetén PullAsync():

PullOptions pullOptions = new PullOptions
    {
        MaxPageSize = 100
    };

Feltéve, hogy PageSize a kiszolgálón belül 100-as vagy annál nagyobb értéket adott meg, egy kérés legfeljebb 100 elemet ad vissza.

Offline táblák használata

Az offline táblák helyi SQLite-tárolót használnak az adatok offline állapotban való tárolására. Minden táblaművelet a helyi SQLite tárolón történik a távoli kiszolgálótároló helyett. Offline tábla létrehozásához először készítse elő a projektet:

  1. A Visual Studio kattintson a jobb gombbal a Megoldás NuGet-csomagjainak > kezelése... megoldásra, majd keresse meg és telepítse a Microsoft.Azure.Mobile.Client.SQLiteStore NuGet-csomagot a megoldásban található összes projekthez.

  2. (Nem kötelező) A Windows támogatásához telepítse az alábbi SQLite-futásidejű csomagok egyikét:

  3. (Nem kötelező). For Windows devices, click References>Add Reference..., expand the Windows folder >Extensions, then enable the appropriate SQLite for Windows SDK along with the Visual C++ 2013 Runtime for Windows SDK. Az SQLite SDK nevei kis mértékben eltérőek lehetnek az egyes Windows platformon.

Táblahivatkozás létrehozása előtt elő kell készíteni a helyi tárolót:

var store = new MobileServiceSQLiteStore(Constants.OfflineDbPath);
store.DefineTable<TodoItem>();

//Initializes the SyncContext using the default IMobileServiceSyncHandler.
await this.client.SyncContext.InitializeAsync(store);

A tároló inicializálása általában közvetlenül az ügyfél létrehozása után történik. Az OfflineDbPath fájlnévnek minden támogatott platformon használhatónak kell lennie. Ha az elérési út egy teljes elérési út (azaz perjellel kezdődik), akkor a rendszer ezt az elérési utat használja. Ha az elérési út nem teljesen minősített, a fájl egy platformspecifikus helyre kerül.

  • iOS- és Android-eszközök esetén az alapértelmezett elérési út a "Személyes fájlok" mappa.
  • A Windows alapértelmezett elérési útja az alkalmazásspecifikus "AppData" mappa.

Táblahivatkozás a metódussal szerezhető GetSyncTable<> be:

var table = client.GetSyncTable<TodoItem>();

Offline tábla használata esetén nem kell hitelesítést végeznie. Csak akkor kell hitelesítenie, amikor a háttérszolgáltatással kommunikál.

Offline tábla szinkronizálása

Az offline táblák alapértelmezés szerint nincsenek szinkronizálva a háttérvel. A szinkronizálás két részre oszlik. A módosításokat az új elemek letöltéstől elkülönítve is lekultálhatja. Példa egy tipikus szinkronizálási módszerre:

public async Task SyncAsync()
{
    ReadOnlyCollection<MobileServiceTableOperationError> syncErrors = null;

    try
    {
        await this.client.SyncContext.PushAsync();

        await this.todoTable.PullAsync(
            //The first parameter is a query name that is used internally by the client SDK to implement incremental sync.
            //Use a different query name for each unique query in your program
            "allTodoItems",
            this.todoTable.CreateQuery());
    }
    catch (MobileServicePushFailedException exc)
    {
        if (exc.PushResult != null)
        {
            syncErrors = exc.PushResult.Errors;
        }
    }

    // Simple error/conflict handling. A real application would handle the various errors like network conditions,
    // server conflicts and others via the IMobileServiceSyncHandler.
    if (syncErrors != null)
    {
        foreach (var error in syncErrors)
        {
            if (error.OperationKind == MobileServiceTableOperationKind.Update && error.Result != null)
            {
                //Update failed, reverting to server's copy.
                await error.CancelAndUpdateItemAsync(error.Result);
            }
            else
            {
                // Discard local change.
                await error.CancelAndDiscardItemAsync();
            }

            Debug.WriteLine(@"Error executing sync operation. Item: {0} ({1}). Operation discarded.", error.TableName, error.Item["id"]);
        }
    }
}

Ha a első argumentuma PullAsync null, akkor a növekményes szinkronizálás nem lesz használva. Minden szinkronizálási művelet lekéri az összes rekordot.

Az SDK implicit műveletet hajt végre PushAsync() a rekordok lehúzása előtt.

Az ütközések kezelése egy metóduson PullAsync() történik. Az ütközéseket ugyanúgy használhatja, mint az online táblákat. Az ütközés akkor keletkezik, PullAsync() ha a beszúrás, frissítés vagy törlés helyett a rendszer a parancs hívatja meg. Ha több ütközés történik, a csomagok egyetlen MobileServicePushFailedException-fájlba vannak csomagolva. Az egyes hibákat külön kezelje.

Egyéni API használata

Az egyéni API-k segítségével olyan egyéni végpontokat definiálhat, amelyek olyan kiszolgálói funkciókat tesz elérhetővé, amelyek nem leképeznek beszúrási, frissítési, törlési vagy olvasási műveletekre. Egyéni API használatával jobban szabályozhatja az üzenetküldést, beleértve a HTTP-üzenetfejlécek olvasását és beállítását, valamint a JSON-on kívül más üzenet törzsformátumának definiálása.

Az egyéni API meghívásához hívja meg az egyik InvokeApiAsync metódust az ügyfélen. A következő kódsor például egy POST kérést küld a háttéren a completeAll API-nak:

var result = await client.InvokeApiAsync<MarkAllResult>("completeAll", System.Net.Http.HttpMethod.Post, null);

Ez az űrlap egy típusos metódushívás, amelyhez meg kell határozni a MarkAllResult visszatérési típust. A típusos és a nem típusos metódusok is támogatottak.

Az InvokeApiAsync() metódus "/api/" előtaggal kezdődik a meghívni kívánt API-hoz, kivéve, ha az API a /előtaggal kezdődik. Például:

  • InvokeApiAsync("completeAll",...) az /api/completeAll hívása a háttéren
  • InvokeApiAsync("/.auth/me",...) a /.auth/me hívása a háttéren

Az InvokeApiAsync használatával bármilyen WebAPI meghívható, beleértve azokat a WebAPI-okat is, amelyek nincsenek definiálva az Azure Mobile Apps. Az InvokeApiAsync() használata esetén a rendszer elküldi a megfelelő fejléceket, beleértve a hitelesítési fejléceket is, a kéréssel együtt.

Felhasználók hitelesítése

Mobile Apps támogatja az alkalmazásfelhasználók hitelesítését és hitelesítését különböző külső identitásszolgáltatók használatával: Facebook, Google, Microsoft-fiók, Twitter és Azure Active Directory. Beállíthatja a táblákra vonatkozó engedélyeket, hogy csak a hitelesített felhasználók számára korlátozza az egyes műveletekhez való hozzáférést. A hitelesített felhasználók identitásával engedélyezési szabályokat is megvalósíthat a kiszolgálói szkriptekben. További információt a hitelesítés alkalmazásokhoz történő hozzáadását ismertető oktatóanyagban találhat.

Két hitelesítési folyamat támogatott: ügyfél által felügyelt és kiszolgáló által felügyelt folyamat. A kiszolgáló által felügyelt folyamat biztosítja a legegyszerűbb hitelesítési felületet, mivel a szolgáltató webes hitelesítési felületére támaszkodik. Az ügyfél által felügyelt folyamat lehetővé teszi az eszközspecifikus képességekkel való mélyebb integrációt, mivel az szolgáltatóspecifikus eszközspecifikus SZOFTVERDK-kra támaszkodik.

Megjegyzés

Javasoljuk, hogy az éles alkalmazásokban ügyfél által felügyelt folyamatot használjon.

A hitelesítés beállításához regisztrálnia kell az alkalmazást egy vagy több identitásszolgáltatónál. Az identitásszolgáltató létrehoz egy ügyfél-azonosítót és egy titkos ügyféltitkot az alkalmazáshoz. Ezek az értékek ezután a háttérkészletben vannak beállítva, hogy engedélyezzék Azure App Service hitelesítést/engedélyezést. További információért kövesse a Hitelesítés hozzáadása az alkalmazáshoz oktatóanyag részletes utasításait.

Ez a szakasz a következő témaköröket tartalmazza:

Ügyfél által felügyelt hitelesítés

Az alkalmazás függetlenül kapcsolatba léphet az identitásszolgáltatóval, majd a visszaadott jogkivonatot a háttéralkalmazással való bejelentkezés során meg tudja adni. Ez az ügyfélfolyam lehetővé teszi, hogy egyszeri bejelentkezést biztosítson a felhasználók számára, vagy további felhasználói adatokat lekérni az identitásszolgáltatótól. Az ügyfélfolyam-hitelesítést inkább a kiszolgálói folyamat használata részesíti előnyben, mivel az identitásszolgáltató SDK natív felhasználói felületét biztosítja, és további testreszabást tesz lehetővé.

Példák a következő ügyfélfolyam-hitelesítési mintákra:

Felhasználók hitelesítése a Active Directory-hitelesítési tár

Az ügyfél Active Directory-hitelesítési tár (ADAL) használatával felhasználói hitelesítést kezdeményezhet az ügyféltől Azure Active Directory hitelesítéssel.

  1. Konfigurálja a mobilalkalmazás háttéralkalmazását AAD bejelentkezéshez a következő oktatóanyag szerint: App Service konfigurálása Active Directory bejelentkezéshez. Mindenképpen a natív ügyfélalkalmazás regisztrálásának opcionális lépését kell végrehajtania.

  2. A Visual Studio vagy Xamarin Studióban nyissa meg a projektet, és adjon hozzá egy hivatkozást a Microsoft.IdentityModel.Clients.ActiveDirectory NuGet-csomaghoz. A kereséskor foglalja bele a kiadás előtti verziókat.

  3. Adja hozzá a következő kódot az alkalmazáshoz a használt platformnak megfelelően. Mindegyikben tegye a következőket:

    • Cserélje le az INSERT-AUTHORITY-HERE helyére annak a bérlőnek a nevét, amelyben az alkalmazást kiépítte. A formátumnak a következőnek kell lennie: https://login.microsoftonline.com/contoso.onmicrosoft.com. Ezt az értéket a tartomány tartománylapja Azure Active Directory a Azure Portal.

    • Cserélje le az INSERT-RESOURCE-ID-HERE helyére a mobilalkalmazás háttéralkalmazásának ügyfél-azonosítóját. Az ügyfél-azonosítót a portálon, a portál Azure Active Directory Gépház speciális lapján szerezheti be.

    • Cserélje le az INSERT-CLIENT-ID-HERE helyére a natív ügyfélalkalmazásból másolt ügyfél-azonosítót.

    • Cserélje le az INSERT-REDIRECT-URI-HERE helyére a webhely /.auth/login/done végpontját a HTTPS-séma használatával. Ennek az értéknek a következőhez hasonlónak kell lennie: https://contoso.azurewebsites.net/.auth/login/done.

      Az egyes platformokhoz szükséges kód a következő:

      Windows:

      private MobileServiceUser user;
private async Task AuthenticateAsync()
{

   string authority = "INSERT-AUTHORITY-HERE";
   string resourceId = "INSERT-RESOURCE-ID-HERE";
   string clientId = "INSERT-CLIENT-ID-HERE";
   string redirectUri = "INSERT-REDIRECT-URI-HERE";
   while (user == null)
   {
       string message;
       try
       {
           AuthenticationContext ac = new AuthenticationContext(authority);
           AuthenticationResult ar = await ac.AcquireTokenAsync(resourceId, clientId,
               new Uri(redirectUri), new PlatformParameters(PromptBehavior.Auto, false) );
           JObject payload = new JObject();
           payload["access_token"] = ar.AccessToken;
           user = await App.MobileService.LoginAsync(
               MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, payload);
           message = string.Format("You are now logged in - {0}", user.UserId);
       }
       catch (InvalidOperationException)
       {
           message = "You must log in. Login Required";
       }
       var dialog = new MessageDialog(message);
       dialog.Commands.Add(new UICommand("OK"));
       await dialog.ShowAsync();
   }
}

      Xamarin.iOS

      private MobileServiceUser user;
private async Task AuthenticateAsync(UIViewController view)
{

   string authority = "INSERT-AUTHORITY-HERE";
   string resourceId = "INSERT-RESOURCE-ID-HERE";
   string clientId = "INSERT-CLIENT-ID-HERE";
   string redirectUri = "INSERT-REDIRECT-URI-HERE";
   try
   {
       AuthenticationContext ac = new AuthenticationContext(authority);
       AuthenticationResult ar = await ac.AcquireTokenAsync(resourceId, clientId,
           new Uri(redirectUri), new PlatformParameters(view));
       JObject payload = new JObject();
       payload["access_token"] = ar.AccessToken;
       user = await client.LoginAsync(
           MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, payload);
   }
   catch (Exception ex)
   {
       Console.Error.WriteLine(@"ERROR - AUTHENTICATION FAILED {0}", ex.Message);
   }
}

      Xamarin.Android

      private MobileServiceUser user;
private async Task AuthenticateAsync()
{

   string authority = "INSERT-AUTHORITY-HERE";
   string resourceId = "INSERT-RESOURCE-ID-HERE";
   string clientId = "INSERT-CLIENT-ID-HERE";
   string redirectUri = "INSERT-REDIRECT-URI-HERE";
   try
   {
       AuthenticationContext ac = new AuthenticationContext(authority);
       AuthenticationResult ar = await ac.AcquireTokenAsync(resourceId, clientId,
           new Uri(redirectUri), new PlatformParameters(this));
       JObject payload = new JObject();
       payload["access_token"] = ar.AccessToken;
       user = await client.LoginAsync(
           MobileServiceAuthenticationProvider.WindowsAzureActiveDirectory, payload);
   }
   catch (Exception ex)
   {
       AlertDialog.Builder builder = new AlertDialog.Builder(this);
       builder.SetMessage(ex.Message);
       builder.SetTitle("You must log in. Login Required");
       builder.Create().Show();
   }
}
protected override void OnActivityResult(int requestCode, Result resultCode, Intent data)
{

   base.OnActivityResult(requestCode, resultCode, data);
   AuthenticationAgentContinuationHelper.SetAuthenticationAgentContinuationEventArgs(requestCode, resultCode, data);
}

Egyetlen Sign-On Facebook- vagy Google-jogkivonat használatával

Az ügyfélfolyamot a Facebookhoz vagy a Google-hoz ebben a kódrészletben látható módon használhatja.

var token = new JObject();
// Replace access_token_value with actual value of your access token obtained
// using the Facebook or Google SDK.
token.Add("access_token", "access_token_value");

private MobileServiceUser user;
private async Task AuthenticateAsync()
{
    while (user == null)
    {
        string message;
        try
        {
            // Change MobileServiceAuthenticationProvider.Facebook
            // to MobileServiceAuthenticationProvider.Google if using Google auth.
            user = await client.LoginAsync(MobileServiceAuthenticationProvider.Facebook, token);
            message = string.Format("You are now logged in - {0}", user.UserId);
        }
        catch (InvalidOperationException)
        {
            message = "You must log in. Login Required";
        }

        var dialog = new MessageDialog(message);
        dialog.Commands.Add(new UICommand("OK"));
        await dialog.ShowAsync();
    }
}

Kiszolgáló által felügyelt hitelesítés

Miután regisztrálta az identitásszolgáltatót, hívja meg a LoginAsync metódust a [MobileServiceClient] szolgáltatáson a szolgáltató MobileServiceAuthenticationProvider értékével. Az alábbi kód például a Facebook használatával kezdeményezi a kiszolgálói folyamatba való bejelentkezést.

private MobileServiceUser user;
private async System.Threading.Tasks.Task Authenticate()
{
    while (user == null)
    {
        string message;
        try
        {
            user = await client
                .LoginAsync(MobileServiceAuthenticationProvider.Facebook);
            message =
                string.Format("You are now logged in - {0}", user.UserId);
        }
        catch (InvalidOperationException)
        {
            message = "You must log in. Login Required";
        }

        var dialog = new MessageDialog(message);
        dialog.Commands.Add(new UICommand("OK"));
        await dialog.ShowAsync();
    }
}

Ha a Facebooktól különböző identitásszolgáltatót használ, módosítsa a MobileServiceAuthenticationProvider értékét a szolgáltató értékére.

A kiszolgálói folyamat Azure App Service OAuth-hitelesítési folyamatot a kiválasztott szolgáltató bejelentkezési oldalának megjelenítésével kezeli. Miután az identitásszolgáltató visszatért, a Azure App Service létrehoz egy App Service hitelesítési jogkivonatot. A LoginAsync metódus egy MobileServiceUser értéket ad vissza, amely A hitelesített felhasználó UserId azonosítóját és a MobileServiceAuthenticationToken jogkivonatot is JSON webes jogkivonatként (JWT) adja meg. Ez a token gyorsítótárazható, és újra felhasználható, amíg le nem jár. További információ: Caching jogkivonat használata.

A Xamarin (Android vagy iOS) használata esetén a rendszer a Xamarin.Essentials WebAuthenticatort használja. Az alapértelmezett környezetet (Android) vagy az UIViewControllert (iOS) át kell adni a metódusnak LoginAsync . Emellett önnek kell kezelnie a webes hitelesítőtől származó visszaküldést. Android rendszeren ez a rendszeren belül van kezelve MainActivity.cs:

public override void OnResume()
{
    base.OnResume();
    Xamarin.Essentials.Platform.OnResume();
}

iOS-ben ez az AppDelegate.cs fájlban van kezelve:

public override bool OpenUrl(UIApplication app, NSUrl url, NSDictionary options)
{
    if (client.ResumeWithURL(app, url, options))
        return true;
    return base.OpenUrl(app, url, options);
}

Caching hitelesítési jogkivonat használata

Bizonyos esetekben a bejelentkezési módszer hívása elkerülhető az első sikeres hitelesítés után, ha a szolgáltatótól származó hitelesítési jogkivonatot tárolja. Microsoft Store és UWP-alkalmazások a PasswordVault használatával gyorsítótárazhatja az aktuális hitelesítési jogkivonatot a sikeres bejelentkezés után, az alábbiak szerint:

await client.LoginAsync(MobileServiceAuthenticationProvider.Facebook);

PasswordVault vault = new PasswordVault();
vault.Add(new PasswordCredential("Facebook", client.currentUser.UserId,
    client.currentUser.MobileServiceAuthenticationToken));

A UserId értéke a hitelesítő adat UserName értékeként lesz tárolva, a jogkivonat pedig jelszóként. A későbbi indítások során a PasswordVaultban ellenőrizheti a gyorsítótárazott hitelesítő adatokat. Az alábbi példa gyorsítótárazott hitelesítő adatokat használ a megtaláláskor, és egyéb esetben megpróbálja ismét hitelesíteni magát a háttéradatokkal:

// Try to retrieve stored credentials.
var creds = vault.FindAllByResource("Facebook").FirstOrDefault();
if (creds != null)
{
    // Create the current user from the stored credentials.
    client.currentUser = new MobileServiceUser(creds.UserName);
    client.currentUser.MobileServiceAuthenticationToken =
        vault.Retrieve("Facebook", creds.UserName).Password;
}
else
{
    // Regular login flow and cache the token as shown above.
}

Amikor kijelentkeztet egy felhasználót, a tárolt hitelesítő adatokat is el kell távolítania az alábbiak szerint:

client.Logout();
vault.Remove(vault.Retrieve("Facebook", client.currentUser.UserId));

A Xamarin-alkalmazások a Xamarin.Auth API-kat használják a hitelesítő adatok biztonságos tárolására egy Fiók objektumban . Az API-k használatának példájért tekintse meg az AuthStore.cs kódfájlt a ContosoMoments fényképmegosztási mintában.

Ügyfél által felügyelt hitelesítés használata esetén gyorsítótárazhatja a szolgáltatótól, például a Facebooktól vagy a Twittertől kapott hozzáférési jogkivonatot is. Ez a jogkivonat a következőképpen kérhető le új hitelesítési jogkivonat a háttérből:

var token = new JObject();
// Replace <your_access_token_value> with actual value of your access token
token.Add("access_token", "<your_access_token_value>");

// Authenticate using the access token.
await client.LoginAsync(MobileServiceAuthenticationProvider.Facebook, token);

Leküldéses értesítések

A következő témakörök a leküldéses értesítéseket fedik le:

How to: Register for Push Notifications

A Mobile Apps ügyfél lehetővé teszi, hogy regisztráljon leküldéses értesítésekre az Azure Notification Hubs. A regisztrációkor beszerez egy leírót, amely a platformspecifikus leküldéses értesítési szolgáltatásból (PNS) szerezhető be. Ezt az értéket a regisztráció létrehozásakor adja meg a címkékkel együtt. A következő kód regisztrálja a Windows leküldéses értesítésekhez a Windows Notification Service (WNS) szolgáltatásban:

private async void InitNotificationsAsync()
{
    // Request a push notification channel.
    var channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();

    // Register for notifications using the new channel.
    await MobileService.GetPush().RegisterNativeAsync(channel.Uri, null);
}

Ha a WNS-nek ad le adatokat, akkor be kell szereznie egy Microsoft Store biztonsági azonosítót. További információ a Windows alkalmazásokról, beleértve a sablonregisztrációkra való regisztrációt: Leküldéses értesítések hozzáadása az alkalmazáshoz.

A címkék ügyféltől való lekért kérése nem támogatott. A címkekérések csendesen el vannak dobva a regisztrációból. Ha címkékkel szeretné regisztrálni az eszközt, hozzon létre egy egyéni API-t, amely a Notification Hubs API-val végzi el a regisztrációt az Ön nevében. A metódus helyett hívja meg a Custom API-t RegisterNativeAsync() .

How to: Obtain a Microsoft Store package SID

A leküldéses értesítések alkalmazásokban való engedélyezéséhez csomag biztonsági Microsoft Store van szükség. A csomag biztonsági azonosítóját úgy fogadhatja, ha regisztrálja az alkalmazást a Microsoft Store.

Az érték beszerzéséhez:

  1. A Visual Studio Megoldáskezelő kattintson a jobb gombbal a Microsoft Store projektre, és kattintson az ÁruházAlkalmazás>társítása az Áruházhoz... elemre.
  2. A varázslóban kattintson a Tovább gombra, jelentkezzen be a Microsoft-fiók, adja meg az alkalmazás nevét az Új alkalmazásnév lefoglalása területen, majd kattintson a Foglalás gombra.
  3. Az alkalmazásregisztráció sikeres létrehozása után válassza ki az alkalmazás nevét, kattintson a Tovább, majd a Társítás elemre.
  4. Jelentkezzen be a Windows Fejlesztői központ Microsoft-fiókjával. A Saját alkalmazások kattintson a létrehozott alkalmazásregisztrációra.
  5. Kattintson azAlkalmazáskezelésAlkalmazásidentitás> elemre, majd görgessen le a csomag biztonsági azonosítójára.

A csomag biztonsági azonosítóját számos felhasználása URI-ként kezeli, ebben az esetben az ms-app:// kell használnia sémaként. Jegyezze fel a csomag biztonsági azonosítóját, amely ennek az értéknek az előtagként való összefésülése által jött létre.

A Xamarin-alkalmazásokhoz további kódra van szükség az iOS- vagy Android-platformokon futó alkalmazások regisztrálása érdekében. További információért tekintse meg a platformhoz kapcsolódó témakört:

How to: Register push templates to send cross-platform notifications (A leküldéses sablonok regisztrálása platformfüggetlen értesítések küldése)

Sablonok regisztráláshoz használja a metódust RegisterAsync() a sablonokkal az alábbiak szerint:

JObject templates = myTemplates();
MobileService.GetPush().RegisterAsync(channel.Uri, templates);

A sablonoknak típusoknak JObject kell lennie, és több sablont is tartalmazhatnak a következő JSON formátumban:

public JObject myTemplates()
{
    // single template for Windows Notification Service toast
    var template = "<toast><visual><binding template=\"ToastText01\"><text id=\"1\">$(message)</text></binding></visual></toast>";

    var templates = new JObject
    {
        ["generic-message"] = new JObject
        {
            ["body"] = template,
            ["headers"] = new JObject
            {
                ["X-WNS-Type"] = "wns/toast"
            },
            ["tags"] = new JArray()
        },
        ["more-templates"] = new JObject {...}
    };
    return templates;
}

A RegisterAsync() metódus másodlagos csempéket is elfogad:

MobileService.GetPush().RegisterAsync(string channelUri, JObject templates, JObject secondaryTiles);

A biztonsági regisztráció során minden címke el lesz különvetve. Ha címkéket szeretne hozzáadni a telepítésekhez vagy a telepítések sablonjaihoz, tekintse meg a következőt: [Az Azure Mobile Apps-hez készült .NET háttérkiszolgálói SDK Mobile Apps].

Ha értesítéseket küld a regisztrált sablonok használatával, tekintse meg a Notification Hubs API-kat.

Egyéb témakörök

How to: Handle errors

Ha hiba történik a háttéralkalmazásban, az ügyfélOLDALI SDK a következőt fogja ki: MobileServiceInvalidOperationException. Az alábbi példa bemutatja, hogyan kezelhetők a háttér által visszaadott kivételek:

private async void InsertTodoItem(TodoItem todoItem)
{
    // This code inserts a new TodoItem into the database. When the operation completes
    // and App Service has assigned an Id, the item is added to the CollectionView
    try
    {
        await todoTable.InsertAsync(todoItem);
        items.Add(todoItem);
    }
    catch (MobileServiceInvalidOperationException e)
    {
        // Handle error
    }
}

A hibafeltételek kezelésére egy másik példát a fájlminta Mobile Apps talál. A LoggingHandler példa egy naplózási delegáltkezelőt biztosít a háttérnek küldött kérések naplózása számára.

How to: Customize request headers (A kérésfejlécek testreszabása)

Előfordulhat, hogy az adott alkalmazás forgatókönyvének támogatásához testre kell szabni a Mobile App háttéralkalmazással való kommunikációt. Előfordulhat például, hogy egyéni fejlécet szeretne hozzáadni minden kimenő kérelemhez, vagy módosítani szeretné a válaszok állapotkódját. Az alábbi példában használt egyéni DelegatingHandlert is használhatja:

public async Task CallClientWithHandler()
{
    MobileServiceClient client = new MobileServiceClient("AppUrl", new MyHandler());
    IMobileServiceTable<TodoItem> todoTable = client.GetTable<TodoItem>();
    var newItem = new TodoItem { Text = "Hello world", Complete = false };
    await todoTable.InsertAsync(newItem);
}

public class MyHandler : DelegatingHandler
{
    protected override async Task<HttpResponseMessage>
        SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        // Change the request-side here based on the HttpRequestMessage
        request.Headers.Add("x-my-header", "my value");

        // Do the request
        var response = await base.SendAsync(request, cancellationToken);

        // Change the response-side here based on the HttpResponseMessage

        // Return the modified response
        return response;
    }
}