Gli Azure Mobile Service sono il supporto preferenziale, da parte di Azure, quando dobbiamo realizzare backend per applicazioni mobile. Grazie al client e al server SDK, infatti, possiamo dotare le nostre app di funzionalità avanzate (quali push notification, offline synchronization e security) con pochissimo sforzo.
Si tratta però di una piattaforma legacy: i Mobile Service, infatti, non supportano le nuove peculiarità di Azure, come la gestione dei Resource Group, la possibilità di essere installati in una Virtual Network o, più semplicemente, l'utilizzo di Application Insights.
Esiste già una controparte integrata con gli App Service, chiamata Mobile App Service. Purtroppo, però, l'SDK non è altrettanto maturo e, in ogni caso, il porting verso questa piattaforma potrebbe richiedere una revisione importante a livello di codice.
Fortunatamente, rinunciando solo a qualche finezza sul portale, possiamo comunque installare un Mobile Service su App Service: in fin dei conti, infatti, si tratta di un normalissimo progetto .NET.
Il primo passo da fare, quindi, è scegliere di effettuare il deploy su una Web App, e selezionare (o creare) quella di destinazione.
Affinché tutto funzioni correttamente, tuttavia, dobbiamo inserire alcune chiavi di configurazione. In particolare:
- MS_MobileServiceName è il nome della Web App. Per esempio, se l'URL è myapp.azurewebsites.net, dobbiamo usare myapp;
- MS_MobileServiceDomainSuffix deve essere invece impostata con la restante parte dell'URL. Secondo l?esempio precedente, sarà azurewebsites.net;
- MS_ApplicationKey e MS_MasterKey sono le due chiavi usate nelle chiamate e condivise tra server e client. Possono essere valorizzate in qualsiasi modo, per esempio con un GUID;
Se la nostra applicazione sfrutta l'accesso ai dati, la connection string e lo schema del database devono essere configurati rispettivamente su MS_TableConnectionString (nella sezione connection strings) e MS_TableSchema (tra gli app settings).
In maniera analoga, per abilitare il supporto a notification hub dobbiamo impostare MS_NotificationHubConnectionString e MS_NotificationHubName per specificare rispettivamente connection string e nome dell'hub.
L'ultimo aspetto riguarda l'autenticazione: ogni provider ha infatti le sue chiavi di configurazione predefinite. Per esempio, se usiamo Facebook, dovremo impostare App Key e App Secret su MS_FacebookAppID e MS_FacebookAppSecret. Una lista completa di queste chiavi può essere recuperata dalla classe ServiceSettingsKeys contenuta nell'SDK, ispezionandone il contenuto con un tool di decompilazione come Reflector o dotPeek.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Eseguire query verso tipi non mappati in Entity Framework Core
What's new in Azure Functions and Extensions
Migliorare la sicurezza dei prompt con Azure AI Studio
Autenticarsi in modo sicuro su Azure tramite GitHub Actions
Ordine e importanza per @layer in CSS
Creare una libreria CSS universale: Clip-path
Estrarre dati randomici da una lista di oggetti in C#
Sfruttare i KeyedService in un'applicazione Blazor in .NET 8
Implementare l'infinite scroll con QuickGrid in Blazor Server
Eseguire i worklow di GitHub su runner potenziati
Hosting di componenti WebAssembly in un'applicazione Blazor static
Proteggere le risorse Azure con private link e private endpoints
I più letti di oggi
- Visualizzare contenuti Fullscreen con HTML5
- Leggere e scrivere su cookie tramite Blazor
- Richiamare programmaticamente le operazioni di aggiornamento, eliminazione e inserimento di FormView, DetailsView e GridView
- Realizzare siti sicuri con ASP.NET Web Pages
- Il web control DropDownList di ASP.NET
- Un helper method per replicare un template per ogni proprietà con ASP.NET MVC
- Operazioni di selezione su una DataTable
- Dependency injection in ASP.NET MVC 5 con Ninject
- Aumentare la scalabilità di ASP.NET Core Web API con caching client side
- Accedere con ASP.NET ad un documento XML creato dall'oggetto recordset di ADO e ASP