Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
by
Lessons:19Length:2.3 hours
Swift400
  • Overview
  • Transcript

4.6 Abstract the Storage Location of the Reminders

In order to provide sample data for our application, we simply have a function load some sample reminders and stages. While this is fine for testing, it isn't realistic when creating an actual application. In this lesson, we will refactor that sample code into a repository singleton that will allow our WatchKit Extension to not know, or even care, how and where the data is coming from.

4.6 Abstract the Storage Location of the Reminders

One final piece of the puzzle that I want to address before I let you go for this particular course, is bridging the gap between the Apple Watch and the iPhone application itself. Because in most cases when it comes to an application like this, your reminders and your stages are more than likely going to be input via the phone and stored using some sort of mechanism on the actual phone. Whether that be using Core Data, or some other database, or maybe using user defaults, or something like that. But regardless of where those things come from, usually it's gonna be on the phone. So maybe in our reminder table interface controller, this loadSampleReminders is may be not very realistic. So maybe what’s some way that we can abstract this and push it off the actual phone itself, so we can get it from somewhere else? So I’m gonna show you a neat little trick that you can use, not only in this particular instance, but in many other instances when it comes to storing data, and being able to retrieve it. Because really when it comes to data retrieval from your Apple Watch, the watch and the extension itself really shouldn't care where the data is. And it should be as abstracted away as possible, and one of the best ways to do that is usually via a repository. And a repository is just a fancy way to say I wanna create a class whose sole purpose in life is to be able to know how to get, retrieve, and create data that is gonna to be store somewhere. So that anywhere else on the outside of that particular class, mainly within the watch or the watch kit extension, doesn't have to care about that. So basically what I wanna do is I wanna extract, and take this loadSampleReminders functionality and push it off somewhere else. And where I want that to live is probably in RemindMe. So let's go ahead and create a new file here. So we'll do New > File. We'll have this be just a Swift file. And we'll select next. And in here, I want this to be included in both the RemindMe and the extension targets. And we're gonna call this the ReminderRepository. So we'll go ahead and create that. Now this is actually going to follow a mechanism known as a singleton. Now a singleton is really another one of those fancy words for a simple concept. A singleton is nothing more than a class that you can access just about anywhere in your application. And regardless of how or where you access it, you're always gonna get the same instance. So you're always gonna get the same functionality. And really all we have to do to do that is a couple little things. So we're gonna create this as a final class, then we're gonna come in here and the first thing we have to do is we have to create a private initialization function. And the reason that it's private is because we don't want anybody directly instantiating an instance of this repository, because that goes against the concept of a singleton. Then what we're going to have here is a static constant that's going to be called something. You can call it shared, you can call it instance, whatever you want. I tend to call them instance, that's fine. And that's gonna be equal to a new instance of our ReminderRepository, so the only place that I can call this initialization function is within my class. And I'm doing it right here. So then the final thing that I want this class to be able to do is to be able to get my repositories or to get my reminders. And all this is going to be is a simple function called getReminders. Now understand that within this function, I should be able to get data from anywhere. I don't really care where. But this particular implementation is simply going to cheat and use this same functionality right here. So we'll cut that out of here and we'll put it in here. But, like I said, understand that this could be retrieving data from Core Data, from NSUserDefaults, from anywhere you could possibly want. So in this case, I'm not setting any reminders here. I'm simply going to return this data, so I'll go ahead and save that. I can come in here and I no longer need this load function here. Then, I can get rid of this one as well. But I do need to come back to my repository, and I can't return anything here because I haven't specified a return type, and I'm going to return a list of reminders. So let's go ahead and save that. So this here is a singleton that I can get a hold of an instance and it's always gonna be the same instance. And then I can call the getReminders function on it. And this can go and get data from anywhere, but once again, this is just going to be giving me some pre-canned information. So let's come back to our table here, and then in here, we'll simply set our reminders here, equal to our ReminderRepository. And the way that we access this is via the instance property and then we simply call getReminders, just like that. So let's go ahead and save this. And while this seems like it could have been a little more complex, it's really not changing the underlying functionality. It's just removing the ability or removing the explicit getting of the list of reminders from our actual watch kit extension and pushing it off to some other place where it can handle the implementation. And the extension in the Apple Watch itself don't need to worry about it. And as you can see here, our application continues to work. So there you have it. That's just a nifty little trick to be able to call into the iPhone application itself and against some data regardless of whether it'll be in a database or in user default or something like that. But to be able to push all of that into another place and not have to worry about the implementation right here within the Apple Watch.

Back to the top