Como usar o Realm de forma eficaz em um aplicativo Xamarin.Forms

Ferdinando Papale18 min read • Published Feb 07, 2022 • Updated Sep 09, 2024

Xamarin Realm C#

Avalie esse Artigo

Some features mentioned below will be deprecated on Sep. 30, 2025. Learn more.

Atualmente, é fundamental cuidar da persistência ao desenvolver um aplicativo móvel. Embora a largura de banda da conexão móvel, bem como a cobertura, tenha aumentado constantemente ao longo do tempo, ainda se espera que os aplicativos funcionem off-line e em um ambiente de conectividade limitada.

Isso se torna ainda mais trabalhoso ao trabalhar com aplicativos que exigem um fluxo constante de dados com o serviço para funcionar de forma eficaz, como aplicativos de colaboração.

Armazenar dados em cache provenientes de um serviço é difícil, mas o Realm pode facilitar o trabalho fornecendo uma maneira muito natural de armazenar e acessar dados. Isso, por sua vez, tornará o aplicativo mais responsivo e permitirá que o usuário final trabalhe sem problemas, independentemente do status da conexão.

The aim of this article is to show how to use Realm effectively, particularly in a Xamarin.Forms app. We will take a look at SharedGroceries, an app to share grocery lists with friends and family, backed by a REST API. With this application, we wanted to provide an example that would be simple but also somehow complete, in order to cover different common use cases. The code for the application can be found in the repository here.

Antes de prosseguir, observe que este não é um artigo introdutório ao Realm ou Xamarin.Forms, portanto, espera-se que você tenha alguma familiaridade com ambos. Se você deseja obter uma introdução ao Realm, você pode dar uma olhada na documentação do Realm .NET SDK. A documentação oficial do Xamarin.Forms e doMVVM são recursos valiosos para aprender sobre esses tópicos.

Crie melhores aplicativos móveis com o Atlas Device Sync: o Atlas Device Sync é um backend como serviço móvel totalmente gerenciado. Aproveite a infraestrutura pronta para uso, os recursos de sincronização de dados, o manuseio de rede integrado e muito mais para lançar rapidamente aplicativos móveis de nível empresarial. Comece agora mesmo a construir: Implemente amostras grátis!

A arquitetura

Nesta seção, vamos discutir a diferença entre a arquitetura de um aplicativo apoiado por um banco de dados SQL clássico e a arquitetura de um aplicativo que usa o Realm.

Arquitetura clássica

Em um aplicativo apoiado por um banco de dados SQL clássico, a estrutura do aplicativo será semelhante à mostrada no diagrama, em que as setas representam a dependência entre os diferentes componentes do aplicativo. O modelo de visualização solicita dados de um repositório que pode recuperá-los de uma fonte de dados remota (como um serviço web) quando estiver online e de um banco de dados local, dependendo da situação. O repositório também se encarrega de manter o banco de dados local atualizado com todos os dados recuperados do serviço da Web. Esta abordagem apresenta alguns problemas:

Combinar dados provenientes da fonte de dados remota e da local é difícil. Por exemplo, ao abrir uma exibição em um aplicativo pela primeira vez, é bastante comum mostrar dados armazenados em cache localmente enquanto os dados provenientes de um serviço da Web estão sendo obtidos. Nesse caso, não é fácil sincronizar a recuperação, bem como mesclar os dados provenientes de ambas as fontes para apresentá-los na visualização.
Os dados provenientes da fonte local são estáticos. Os objetos recuperados do banco de dados geralmente são POCOs (objeto de classe antigo simples) e, como tal, não refletem o estado atual dos dados presentes no cache. Por exemplo, para manter os dados mostrados ao usuário o mais atualizados possível, pode haver um processo de sincronização em segundo plano que está continuamente recuperando dados do serviço Web e inserindo-os no banco de dados. No entanto, é bastante complexo disponibilizar esses dados para o usuário final do aplicativo, pois com um banco de dados SQL clássico podemos obter dados atualizados apenas com uma nova consulta, e isso precisa ser feito manualmente, aumentando ainda mais a necessidade de coordenar diferentes componentes do aplicativo.
A paginação é difícil. Os objetos são totalmente carregados do banco de dados após a recuperação, e isso pode causar problemas de desempenho ao trabalhar com grandes conjuntos de dados. Nesse caso, a paginação pode ser necessária para manter o desempenho do aplicativo, mas isso não é fácilde implementar.

Arquitetura de Realm

Ao trabalhar com o Realm, em vez disso, a estrutura do aplicativo deve ser semelhante à do diagrama acima.

Nessa abordagem, o realm é acessado diretamente do modelo de visualização, e não fica oculto atrás de um repositório como antes. Quando as informações são recuperadas do serviço da Web, elas são inseridas no banco de dados, e o modelo de visualização pode atualizar a interface do usuário graças às notificações provenientes do realm. Em nossa arquitetura, decidimos chamar de DataService a entidade responsável pelo fluxo de dados no aplicativo.

Existem várias vantagens para essa abordagem:

Uma única fonte de verdade remove conflitos. Como os dados são provenientes apenas do realm, não há problemas com a mesclagem e sincronização de dados provenientes de várias fontes de dados na interface do usuário. Por exemplo, ao abrir uma visualização em um aplicativo pela primeira vez, os dados provenientes do realm são mostrados imediatamente. Enquanto isso, os dados do serviço da Web são recuperados e inseridos na região. Isso trigger uma notificação no modelo de exibição que atualizará a interface do usuário de acordo.
Objetos e coleções estão ativos. Isso significa que os dados provenientes do reino são sempre os mais recentes disponíveis localmente. Não é necessário consultar novamente o banco de dados para obter a versão mais recente dos dados, como acontece com um banco de dados SQL.
Objetos e coleções são carregados preguiçosamente. Isso significa que não há necessidade de se preocupar com a paginação, mesmo ao trabalhar com grandes conjuntos de dados.
Vinculações. O Realm funciona imediatamente com vinculações de dados no Xamarin.Forms, simplificando muito o uso do padrão MVVM.

Como você pode ver no diagrama, a linha entre o modelo de visualização e o DataService está pontilhada para indicar que é opcional. Como o modelo de visualização mostra apenas dados provenientes do reino, ele não precisa realmente depender do DataService, e a recuperação de dados provenientes do serviço web pode ocorrer de forma independente. Por exemplo, o DataService pode solicitar dados continuamente ao serviço da Web para mantê-los atualizados, independentemente do que esteja sendo mostrado ao usuário em um horário específico. Essa abordagem de solicitação contínua também pode ser usada em uma solução de banco de dados SQL, mas isso exigiria sincronização e consultas adicionais, pois os dados provenientes do banco de dados são estáticos. No entanto, às vezes, os dados precisam ser trocados com o serviço da web em consequência de ações específicas do usuário - por exemplo, com o pull-to-refresh - e, nesse caso, o modelo de visualização precisa depender do DataService.

Aplicativo SharedGroceries

Nesta seção, vamos apresentar nosso aplicativo de exemplo e como executá-lo.

SharedGroceries é um aplicativo colaborativo simples que permite compartilhar listas de compras com amigos e familiares, apoiado por uma REST API. Decidimos usar o REST, pois é uma escolha bastante comum e nos permitiu criar um serviço facilmente. Não vamos nos concentrar muito no serviço da REST API, pois ele está fora do escopo deste artigo.

Vamos dar uma olhada no aplicativo agora. As capturas de tela aqui foram retiradas apenas da versão do aplicativo para iOS, para simplificar:

(a) A primeira página do aplicativo é a página de login, na qual o usuário pode inserir seu nome de usuário e senha para fazer o login.
(b) Após o login, o usuário recebe as listas de compras que está compartilhando no momento. Além disso, o usuário pode adicionar uma nova lista aqui.
(c) Ao clicar em uma linha, ela vai para a página da lista de compras que mostra o conteúdo dessa lista. A partir daqui, o usuário pode adicionar e remover itens, renomeá-los e marcá-los / desmarcá-los quando forem comprados.

Para executar o aplicativo, primeiro você precisa executar o serviço da web com a REST API. Para fazer isso, abra o projetoSharedGroceriesWebService e execute-o. Isso deve iniciar o serviço da web em http://localhost:5000 por padrão. Depois disso, você pode simplesmente executar o projetoSharedGroceries que contém o código para o aplicativo Xamarin.Forms. A aplicação já está configurada para se conectar ao serviço web no endereço padrão.

Para simplificar, não abordamos o caso de usuários registrados, e todos eles já são criados no serviço web. Em particular, há três usuários predefinidos —alice, bobe charlie, todos com senha definida como 1234—que podem ser usados para acessar o aplicativo. Algumas listas de compras também já foram criadas no serviço para facilitar o teste do aplicativo.

Realm na prática

Nesta seção, entraremos em detalhes sobre a estrutura do aplicativo e como usar o Realm de forma eficaz. A estrutura segue a arquitetura descrita na seção de arquitetura.

Rest API

Se começarmos da parte inferior do esquema de arquitetura, temos o namespaceRestAPI que contém o código responsável pela comunicação com o serviço web. Em particular, o RestAPIClient está fazendo solicitações HTTP para o SharedGroceriesWebService. Os dados são trocados na forma de DTOs (Data Transfer Objects), objetos simples usados para a serialização e desserialização de dados pela rede. Nesse aplicativo simples, poderíamos evitar o uso de DTOs e usar diretamente nossos objetos de modelo de Realm, mas é sempre uma boa ideia usar objetos específicos apenas para a transferência de dados, pois isso nos permite ter dependência entre o modelo de persistência local e o serviço modelo. Com essa separação, não precisamos necessariamente alterar nosso modelo local caso o modelo de serviço mude.

Aqui está o exemplo de um dos DTOs no aplicativo:

Trecho de código

UserInfoDTO é apenas um container usado para a serialização/deserialização de dados transmitidos nas chamadas de API e contém métodos para converter de e para o modelo local (neste caso, a classeUserInfo).

RealmService

RealmService é responsável por fornecer uma referência a um realm:

Trecho de código

A classe é bastante simples no momento, pois estamos usando a configuração padrão para o reino. No entanto, ter uma classe separada se torna mais útil quando temos uma configuração mais complicada para o reino e queremos evitar a duplicação de código.

Observe que o métodoGetRealmestá criando uma nova instância de realm quando é chamado. Como as instâncias de realm precisam ser usadas no mesmo thread em que foram criadas, esse método pode ser usado em qualquer lugar do nosso código, sem a necessidade de se preocupar com problemas de threading. Também é importante descartar as instâncias de realm quando elas não forem mais necessárias, especialmente em threads em segundo plano.

Data Service

A classeDataService é responsável por gerenciar o fluxo de dados no aplicativo. Quando necessário, a classe solicita dados de RestAPICliente, em seguida, os mantém no domínio. Um método típico desta classe seria assim:

Trecho de código

O método RetrieveUsersprimeiro recupera a lista de usuários (na forma de DTOs) da REST API e depois os insere no realm, após uma conversão de DTOs para objetos de modelo. Aqui você pode ver o uso da declaraçãousing para descartar o realm no final do bloco try.

Modelos do Realm

A definição do modelo para o Realm geralmente é direta, pois é possível usar uma classe C# simples como modelo com pouquíssimos modificações. No trecho a seguir, você pode ver as três classes de modelo que estamos usando em SharedGroceries:

Trecho de código

Os modelos são bem simples e se assemelham estritamente aos objetos DTO recuperados do serviço web. Uma das poucas advertências ao escrever classes de modelo de Realm é lembrar que as collections (listas, conjuntos e dicionários) precisam ser declaradas com uma propriedade somente de obtenção e o tipo de interface correspondente (IList, ISet, IDictionary) , como está ocorrendo com ShoppingList.

Outra coisa a notar aqui é que GroceryItem é definido como EmbeddedObject, para indicar que ele não pode existir como um objeto de Realm independente (e, portanto, não pode ter um PrimaryKey) e tem o mesmo ciclo de vida do ShoppingList que o contém. Isso implica que GroceryItems são excluídos quando oShoppingListpai é excluído.

Visualizar modelos

Agora, examinaremos os dois principais modelos de visualização do aplicativo e discutiremos os pontos mais importantes. Vamos pular LoginViewModel, pois ele não é particularmente interessante.

ShoppingListsCollectionViewModel

ShoppingListsCollectionViewModel é o modelo de visualização de suporte ShoppingListsCollectionPage, a página principal do aplicativo, que mostra a lista de listas de compras do usuário atual. Vamos dar uma olhada nos principais elementos:

Trecho de código

public class ShoppingListsCollectionViewModel : BaseViewModel
{
    private readonly Realm realm;
    private bool loaded;

public ICommand AddListCommand { get; }
    public ICommand OpenListCommand { get; }

public IEnumerable<ShoppingList> Lists { get; }

public ShoppingList SelectedList
    {
        get => null;
        set
        {
            OpenListCommand.Execute(value);
            OnPropertyChanged();
        }
    }

public ShoppingListsCollectionViewModel()
    {
        //1
        realm = RealmService.GetRealm();
        Lists = realm.All<ShoppingList>();

AddListCommand = new AsyncCommand(AddList);
        OpenListCommand = new AsyncCommand<ShoppingList>(OpenList);
    }

internal override async void OnAppearing()
    {
        base.OnAppearing();

IDisposable loadingIndicator = null;

try
        {
            //2
            if (!loaded)
            {
                //Page is appearing for the first time, sync with service
                //and retrieve users and shopping lists
                loaded = true;
                loadingIndicator = DialogService.ShowLoading();
                await DataService.TrySync();
                await DataService.RetrieveUsers();
                await DataService.RetrieveShoppingLists();
            }
            else
            {
                DataService.FinishEditing();
            }
        }
        catch
        {
            await DialogService.ShowAlert("Error", "Error while loading the page");
        }
        finally
        {
            loadingIndicator?.Dispose();
        }
    }

//3
    private async Task AddList()
    {
        var newList = new ShoppingList();
        newList.Owners.Add(DataService.CurrentUser);
        realm.Write(() =>
        {
            return realm.Add(newList, true);
        });

await OpenList(newList);
    }

private async Task OpenList(ShoppingList list)
    {
        DataService.StartEditing(list.Id);
        await NavigationService.NavigateTo(new ShoppingListViewModel(list));
    }
}

No construtor do modelo de visualização (1), estamos inicializando realm e também Lists. Essa é uma collection consultável de ShoppingList elementos, representando todas as listas de compras do usuário. Lists é definido como uma propriedade pública com um getter, e isso permite vinculá-lo à UI, como podemos ver em ShoppingListsCollectionPage.xaml:

Trecho de código

O conteúdo da página é um ListView cujo ItemsSource está vinculado a Lists (A). Isso significa que as linhas do ListView estão realmente vinculadas aos elementos de Lists (ou seja, uma coleção de ShoppingList). Um pouco mais abaixo, podemos ver que cada uma das linhas do ListView é um TextCell cujo texto está vinculado à variável Name de ShoppingList (B). Juntos, isso significa que esta página mostrará uma linha para cada uma das listas de compras, com o nome da lista na linha.

Um aspecto importante a saber é que, por trás das cortinas, as coleções Realm (como Lists, neste caso) implementam INotifyCollectionChanged e que os objetos Realm implementam INotifyPropertyChanged. Isso significa que a interface do usuário será atualizada automaticamente sempre que houver uma alteração na coleção (por exemplo, adicionando ou removendo elementos), bem como sempre que houver uma alteração em um objeto (se uma propriedade for alterada). Isso simplifica muito o uso do padrão MVVM, pois implementar essas interfaces manualmente é um processo tedioso e sujeito a erros.

Retornando a ShoppingListsCollectionViewModel, em OnAppearing, podemos ver como a collection Realm é realmente preenchida. Se a página não tiver sido carregada antes (2), chamamos os métodos DataService.RetrieveUsers e DataService.RetrieveShoppingLists, que recuperam a lista de usuários e as listas de compras do serviço e as inserem no Realm. Devido ao fato de as collections do Realm estarem ativas, Lists notificará a UI de que seu conteúdo foi alterado, e a lista na tela será preenchida automaticamente. Observe que há também alguns elementos mais interessantes aqui relacionados à sincronização de dados locais com o serviço web, mas os discutiremos mais tarde.

Por fim, temos os AddList OpenList métodos e3( ) que são invocados, respectivamente, quando o botãoAdicionar é clicado ou quando uma lista é clicada. O OpenList método apenas passa o clicado list para o ShoppingListViewModel, enquanto AddList primeiro cria uma nova lista vazia, adiciona o usuário atual na lista de proprietários, adiciona-o ao domínio e depois abre a lista .

ShoppingListViewModel

ShoppingListViewModel é o modelo de visualização de apoio ShoppingListPage, a página que mostra o conteúdo de uma determinada lista e nos permite modificá-la:

Trecho de código

public class ShoppingListViewModel : BaseViewModel
{
    private readonly Realm realm;

public ShoppingList ShoppingList { get; }
    public IEnumerable<GroceryItem> CheckedItems { get; }
    public IEnumerable<GroceryItem> UncheckedItems { get; }

public ICommand DeleteItemCommand { get; }
    public ICommand AddItemCommand { get; }
    public ICommand DeleteCommand { get; }

public ShoppingListViewModel(ShoppingList list)
    {
        realm = RealmService.GetRealm();

ShoppingList = list;

//1
        CheckedItems = ShoppingList.Items.AsRealmQueryable().Where(i => i.Purchased);
        UncheckedItems = ShoppingList.Items.AsRealmQueryable().Where(i => !i.Purchased);

DeleteItemCommand = new Command<GroceryItem>(DeleteItem);
        AddItemCommand = new Command(AddItem);
        DeleteCommand = new AsyncCommand(Delete);
    }

//2
    private void AddItem()
    {
        realm.Write(() =>
        {
            ShoppingList.Items.Add(new GroceryItem());
        });
    }

private void DeleteItem(GroceryItem item)
    {
        realm.Write(() =>
        {
            ShoppingList.Items.Remove(item);
        });
    }

private async Task Delete()
    {
        var confirmDelete = await DialogService.ShowConfirm("Deletion",
            "Are you sure you want to delete the shopping list?");

if (!confirmDelete)
        {
            return;
        }

var listId = ShoppingList.Id;
        realm.Write(() =>
        {
            realm.Remove(ShoppingList);
        });

await NavigationService.GoBack();
    }
}

Como verá em um segundo, a página está vinculada a duas collection diferentes, CheckedItems e UncheckedItems, que representam, respectivamente, a lista de itens que foram verificados (comprados) e aqueles que não foram. Para obtê-los, AsRealmQueryable é chamado em ShoppingList.Items, para converter IList em uma query apoiada pelo Realm, que pode ser consultada com LINQ.

O código xaml da página pode ser encontrado em ShoppingListPage.xaml. Aqui está o conteúdo principal:

Trecho de código

<ContentPage.Content>
    <ScrollView>
        
        <StackLayout Orientation="Vertical" Margin="20" Spacing="10">
            
            <Editor Text="{Binding ShoppingList.Name}" HorizontalOptions="Fill"
                    Placeholder="Shopping List Name"/>
            
            <StackLayout BindableLayout.ItemsSource="{Binding UncheckedItems}">
                <BindableLayout.ItemTemplate>
                    <DataTemplate>
                        
                        <StackLayout Orientation="Horizontal">
                            
                            <CheckBox IsChecked="{Binding Purchased}" VerticalOptions="Center"  />
                            
                            <Entry Text="{Binding Name}"
                                    Keyboard="Email"
                                    HorizontalOptions="FillAndExpand"
                                    VerticalOptions="Center"/>
                            
                            <Button Text="X" FontSize="Title"
                                Command="{Binding Path=BindingContext.DeleteItemCommand, Source={x:Reference page}}"
                                CommandParameter="{Binding .}"/>
                        </StackLayout>
                    </DataTemplate>
                </BindableLayout.ItemTemplate>
            </StackLayout>
             
            <Button Text="+ Add Item" Command="{Binding AddItemCommand}"/>
             
            <BoxView Color="Gray" HeightRequest="1"/>
            <Label Text="{Binding CheckedItems.Count, StringFormat='{0} ticked'}"/>
            
            <StackLayout BindableLayout.ItemsSource="{Binding CheckedItems}">
                <BindableLayout.ItemTemplate>
                    <DataTemplate>
                        <StackLayout Orientation="Horizontal">
                            <CheckBox IsChecked="{Binding Purchased}" VerticalOptions="Center"  />
                            <Label Text="{Binding Name}" TextDecorations="Strikethrough"
                                    HorizontalOptions="FillAndExpand"
                                    VerticalOptions="Center"/>
                            <Button Text="X" FontSize="Title"
                                Command="{Binding Path=BindingContext.DeleteItemCommand, Source={x:Reference page}}"
                                CommandParameter="{Binding .}"/>
                        </StackLayout>
                    </DataTemplate>
                </BindableLayout.ItemTemplate>
            </StackLayout>
        </StackLayout>
    </ScrollView>
</ContentPage.Content>

Esta página é composta por um StackLayoutexterno (A) que contém:

(B) Um Editor cujo Text está vinculado a ShoppingList.Name. Isso permite ao usuário ler e, eventualmente, modificar o nome da lista.
(C) Um StackLayoutvinculável que está vinculado a UncheckedItems. Essa é a lista de itens que precisam ser comprados. Cada uma das linhas de StackLayout está vinculada a um elemento de UncheckedItems e, portanto, a um GroceryItem.
(D) Um Button que nos permite adicionar novos elementos à lista.
(E) Um separador (o BoxView) e um Label que descrevem quantos elementos da lista foram marcados, graças à vinculação com CheckedItems.Count.
(F) Um vinculável vinculado StackLayout a CheckedItems. Essa é a lista de itens que já foram comprados. Cada uma das linhas do StackLayout está vinculada a um elemento CheckedItems e, portanto, a GroceryItem.

Se focarmos nossa atenção no DataTemplate do primeiro StackLayoutvinculável, podemos ver que cada linha é composta por três elementos:

(H) Um Checkbox que está vinculado a Purchased de GroceryItem. Isso nos permite marcar e desmarcar itens.
(I) Um Entry que está vinculado a Name de GroceryItem. Isso nos permite alterar o nome dos itens.
(J) Um Button que, quando clicado, executou o comandoDeleteItemCommand no modelo de visualização, com GroceryItem como argumento. Isso nos permite excluir um item.

Observe que, para simplificar, decidimos usar um StackLayoutvinculável para exibir os itens da lista de compras. Em um aplicativo de produção, pode ser necessário usar uma visualização que ofereça suporte à virtualização, como ListView ou CollectionView, dependendo da quantidade esperada de elementos na collection.

Um aspecto interessante a ser observado é que todos os vínculos são, na verdade, bidirecionais, ou seja, vão do modelo de visualização para a página e da página para o modelo de visualização. Isso, por exemplo, permite que o usuário modifique o nome de uma lista de compras, bem como marque e desmarque itens. Os elementos de visualização são vinculados diretamente aos objetos e collection do Realm (ShoppingList, UncheckedItems e CheckedItems) e, portanto, todas essas alterações são automaticamente mantidas no realm.

Para fazer um exemplo mais completo sobre o que está acontecendo, vamos nos concentrar em verificar/desmarcar itens. Quando o usuário verifica um item, a propriedade Purchased de um GroceryItem é definida como true, graças às ligações. Isso significa que esse item não faz mais parte de UncheckedItems (definido como a coleção de GroceryItem com Purchased definido como false na consulta (1)) e, portanto, desaparecerá da lista superior. Agora o item fará parte de CheckedItems (definido como a coleção de GroceryItem com Purchased definido como true na consulta (1)), e como tal aparecerá na lista inferior. Dado que o número de elementos em CheckedItems foi alterado, o texto em Label (E) também será atualizado.

Voltando ao modelo de exibição, temos os métodosAddItem, DeleteIteme Delete (2) que são invocados, respectivamente, quando um item é adicionado, quando um item é removido e quando toda a lista precisa ser removida. Os métodos são bastante diretos e, em sua essência, basta executar uma transação de gravação modificando ou excluindo ShoppingList.

Edição e sincronização

Nesta seção, discutiremos como a edição da lista de compras é feita no aplicativo e como sincronizá-la de volta ao serviço.

Em um aplicativo móvel, geralmente há duas maneiras diferentes de abordar a edição:

Botão Salvar. O usuário modifica o que precisa no aplicativo e, em seguida, pressiona um botão salvar para persistir suas alterações quando estiver satisfeito.
Salvamento contínuo. As alterações feitas pelo usuário são salvas continuamente pelo aplicativo, portanto, não há necessidade de um botão de salvamento explícito.

Em geral, a segunda opção é mais comum em aplicativos modernos e, por esse motivo, é também a abordagem que decidimos usar em nosso exemplo.

A edição principal em SharedGroceries acontece no ShoppingListPage, onde o usuário pode modificar ou excluir listas de compras. Como discutimos anteriormente, todas as alterações feitas pelo usuário são automaticamente persistidas no domínio graças às ligações bidirecionais e, portanto, a próxima etapa é sincronizar essas alterações de volta ao serviço Web. Mesmo que as alterações sejam salvas à medida que acontecem, decidimos sincronizá-las com o serviço somente depois que o usuário terminar de modificar uma determinada lista e sair do ShoppingListPage. Isso nos permite enviar toda a lista atualizada para o serviço, em vez de uma série de atualizações individuais. Esta é uma escolha que fizemos para manter o aplicativo simples, mas obviamente, os requisitos podem ser diferentes em outro caso.

Para implementar o mecanismo de sincronização que discutimos, precisamos acompanhar qual lista de compras estava sendo editada em um determinado momento e quais listas de compras já foram editadas (e, portanto, podem ser enviadas para o serviço da Web). Isso é implementado nos seguintes métodos da classeDataService:

Trecho de código

public static void StartEditing(Guid listId)
{
    PreferencesManager.SetEditingListId(listId);
}

public static void FinishEditing()
{
    var editingListId = PreferencesManager.GetEditingListId();

if (editingListId == null)
    {
        return;
    }

//1
    PreferencesManager.RemoveEditingListId();
    //2
    PreferencesManager.AddReadyForSyncListId(editingListId.Value);

//3
    Task.Run(TrySync);
}

public static async Task TrySync()
{
    //4
    var readyForSyncListsId = PreferencesManager.GetReadyForSyncListsId();

//5
    var editingListId = PreferencesManager.GetEditingListId();

foreach (var readyForSyncListId in readyForSyncListsId)
    {
        //6
        if (readyForSyncListId == editingListId)  //The list is still being edited
        {
            continue;
        }

//7
        var updateSuccessful = await UpdateShoppingList(readyForSyncListId);
        if (updateSuccessful)
        {
            //8
            PreferencesManager.RemoveReadyForSyncListId(readyForSyncListId);
        }
    }
}

O método StartEditing é chamado ao abrir uma lista em ShoppingListsCollectionViewModel:

Trecho de código

Esse método persiste no disco do Id da lista que está sendo editada no momento.

O método FinishEditing é chamado em OnAppearing em ShoppingListsCollectionViewModel:

Trecho de código

Esse método é chamado quando ShoppingListsCollectionPage aparece na tela e, em seguida, o usuário possivelmente retornou do ShoppingListsPage após terminar a edição. Esse método remove o identificador da lista de compras que está sendo editada (se existir)(1) e o adiciona à coleção de identificadores para listas que estão prontas para serem sincronizadas (2). Finalmente, ele chama o método TrySync (3) em outro thread.

Finalmente, o método TrySync é chamado em DataService.FinishEditing e em ShoppingListsCollectionViewModel.OnAppearing, como vimos antes. Este método se encarrega de sincronizar todas as alterações locais de volta ao serviço web:

Primeiro, ele recupera os IDs das listas que estão prontas para serem sincronizadas (4) e, em seguida, o ID da lista (final) que está sendo editada no momento (5).
Em seguida, para cada um dos identificadores das listas prontas para serem sincronizadas (readyForSyncListsId), se a lista estiver sendo editada agora (6), ele simplesmente pulará essa iteração do loop. Caso contrário, ele atualiza a lista de compras no serviço (7).
Por fim, se a atualização tiver sido bem-sucedida, ela removerá o identificador da collection de listas que foram editadas (8).

Este método também é chamado em OnAppearing de ShoppingListsCollectionViewModel se esta for a primeira vez que a página correspondente é carregada. Fazemos isso porque precisamos sincronizar os dados de volta com o serviço quando o aplicativo for iniciado, caso tenha ocorrido problemas de conexão anteriormente.

Em geral, essa é provavelmente uma abordagem muito simplificada da sincronização, pois não consideramos vários problemas que precisam ser resolvidos em um aplicativo de produção:

O que acontece se o serviço não estiver acessível? Qual é a nossa política de novas tentativas?
Como resolvemos conflitos no serviço quando os dados estão sendo modificados por vários usuários?
Como respeitamos a consistência dos dados? Como podemos garantir que as alterações provenientes do serviço Web não estejam substituindo as alterações locais?

Esses são apenas parte dos possíveis problemas que podem surgir ao trabalhar com sincronização, especialmente em aplicativos de colaboração como o nosso.

Conclusão

Neste artigo, mostramos como o Realm pode ser usado de forma eficaz em um aplicativo Xamarin.Forms, graças a notificações, vinculações e objetos ativos.

O uso do Realm como fonte da verdade para o aplicativo simplificou muito a arquitetura do SharedGroceries e as vinculações automáticas, juntamente com as notificações, também simplificaram a implementação do padrão MVVM.

No entanto, a sincronização em um aplicativo participativo como o SharedGroceries ainda é difícil. Em nosso exemplo, cobrimos apenas parte dos possíveis problemas de sincronização que podem surgir, mas você já pode ver a quantidade de esforço necessária para garantir que tudo permaneça sincronizado entre o aplicativo móvel e o serviço da Web.

Em um artigo a seguir, vamos ver como podemos usar o Realm Sync para simplificar muito a arquitetura do aplicativo e resolver nossos problemas de sincronização.

Avalie esse Artigo

Relacionado

Tutorial

Create a RESTful API With .NET Core and MongoDB

Sep 11, 2024 | 8 min read

Tutorial

Projetar uma estratégia para desenvolver um jogo com Unity e MongoDB

Apr 02, 2024 | 7 min read

Tutorial

Consulte seus dados com o ASP.NET Core, o OData e o provedor do MongoDB Entity Framework Core

Jul 08, 2024 | 7 min read

Tutorial

Interaja com o MongoDB Atlas em uma função do AWS Lambda usando C#

Jan 23, 2024 | 5 min read