Continuing from last post, we need that “source of truth” for the real Fabric list that the FabricDataService uses to perform CRUD operations.

To follow along, check out the diff from last post here.

Matt Soucoup has a great write up on using App.Properties in Xamarin.Forms.  App.Properties will be my “source of truth” for my service. I could also use the Settings plugin, but to keep this blog post focused on what the service is doing, I’m going to stick with App.Properties for this blog post.

Note: App.Properties is supposed to persist data across installs (i.e. debugging builds), but I’m running into this issue.  I’ve tried doing await Application.Current.SavePropertiesAsync() but still didn’t persist the fabrics. Moving forward, I’ll switch to the Settings plugin because I don’t want to recreate these fabrics every deploy.

What I learned

• Oh yeah, every time you tab to a new page or open a new page, that page is being created for the first time. I have no idea why I’m so paranoid about saving memory and thinking I need to keep cached versions of these pages around all the time.
• The Settings plug is actually quite simple as well, but for this demo, I wanted to use as few lines of code as possible to demonstrate the service, not the underlying save/persistence mechanism.
• Think of App.Current.Properties as a way of getting the Fabrics from “storage” whether that is from disk (which is what this is doing) or from something else like Settings plugin, or from a cloud service.
• It’s okay that every time you need to get the list of fabrics, it pulls it from “storage”. I have no idea why I want to cache everything so badly.

In the FabricDataService, we now have for GetAllFabrics()

        public static List<Fabric> GetAllFabrics()
        {

            List<Fabric> fabrics = new List<Fabric>();

            if (Application.Current.Properties.Count == 0)
            {
                return fabrics;
            }

            for (int i = 0; i < Application.Current.Properties.Count; i++)
            {
                var fabric = Application.Current.Properties[i.ToString()] as Fabric;
                fabrics.Add(fabric);
            }

            return fabrics;
        }

And AddFabric() becomes

        public async static void AddFabric(Fabric fabric) {

            fabric.Id = Application.Current.Properties.Count;
            Application.Current.Properties.Add(fabric.Id.ToString(), fabric);
            await Application.Current.SavePropertiesAsync();
        }

Next, we have to add UpdateFabric() to the data service for when the user edits an item in the ListView.

        public static void UpdateFabric(Fabric fabric)
        {
            Xamarin.Forms.Application.Current.Properties.Remove(fabric.Id.ToString());

            Xamarin.Forms.Application.Current.Properties.Add(fabric.Id.ToString(), fabric);
        }

Lastly, have DoneEditing() call the DataService.  

        private async void DoneEditing()
        {
            if (isNew) {

               FabricsDataService.AddFabric(this.Fabric);

                MessagingCenter.Send<ItemDetailsViewModel, Fabric>(this, "added", this.Fabric);
            } else {

               FabricsDataService.UpdateFabric(this.Fabric);

            }

            await Navigation.PopAsync();
        }

Now when you run the app, you’ll notice no obvious change in functionality. You can add fabrics and tab between the two pages just as before which is a good test. One thing I had to remind myself is that every time you open a page (whether navigating between two pages or opening the ItemDetailsPage), you are recreating a new instance of the View and ViewModel.

• Xamarin.Forms