0 1 00:00:01,120 --> 00:00:07,430 Now, we still have a rather fundamental problem with our app. And that's when we open up a new app, 1 2 00:00:07,450 --> 00:00:10,440 we didn't get anything loaded up in our table view. 2 3 00:00:10,660 --> 00:00:16,420 Despite the fact that when we add items, we're actually able to save it successfully into our persistent 3 4 00:00:16,420 --> 00:00:17,370 container. 4 5 00:00:17,470 --> 00:00:22,480 So let's fix that by targeting the next word in CRUD which is read. 5 6 00:00:22,720 --> 00:00:27,310 So how can we load up items from our system container? 6 7 00:00:27,340 --> 00:00:32,360 So let's go into our load item's function and let's uncomment it. 7 8 00:00:32,590 --> 00:00:37,750 But we're going to delete everything that's inside because we're using something that's completely different 8 9 00:00:37,750 --> 00:00:39,560 from encoding and decoding. 9 10 00:00:39,970 --> 00:00:46,870 But instead, we're going to create a new constant called request and we're going to specify its data 10 11 00:00:46,870 --> 00:00:55,090 type as NSFetchRequest that is going to fetch results in the form of items. 11 12 00:00:55,150 --> 00:01:02,670 So in Swift, there's very few cases where you actually need to specify the data type. 12 13 00:01:02,770 --> 00:01:08,980 In most cases, you specify the data type because it helps you with the programmer or people on your team 13 14 00:01:09,250 --> 00:01:13,100 to be able to easily see what is going on in your code. 14 15 00:01:13,330 --> 00:01:19,960 But in the majority of cases, Swift is clever enough to figure out what is the data type just based on 15 16 00:01:19,960 --> 00:01:21,630 the value that you give it. 16 17 00:01:21,940 --> 00:01:23,740 But in this case, it's a little bit different. 17 18 00:01:23,740 --> 00:01:25,960 You actually have to specify the data type. 18 19 00:01:25,960 --> 00:01:30,040 And most importantly, the entity that you're trying to request. 19 20 00:01:30,340 --> 00:01:33,310 So we're going to say let request be of data type 20 21 00:01:33,340 --> 00:01:38,980 NSFetchRequest, that's going to fetch a whole bunch of items. And then we're going to tap into our 21 22 00:01:38,980 --> 00:01:44,590 Item class or Item entity and we're going to make a new fetchrequest. 22 23 00:01:44,590 --> 00:01:50,710 And, of course, as always, our application have to speak to the context before we can do anything with 23 24 00:01:50,710 --> 00:01:52,420 our persistent container. 24 25 00:01:52,420 --> 00:02:01,690 So we have to say context.fetch. And the fetch that we want to make is our current request which is 25 26 00:02:01,720 --> 00:02:06,910 basically just a blank request that pulls back everything that's currently inside our persistent container. 26 27 00:02:06,910 --> 00:02:12,740 Now, the problem with this is that similar to context.save, context.fetch can also throw an error. 27 28 00:02:12,820 --> 00:02:18,560 So we need to market with a try and then we have to make it happen inside a do catch block. 28 29 00:02:19,530 --> 00:02:27,160 And if there were errors, then we'll print "Error fetching data from context" 29 30 00:02:27,160 --> 00:02:31,350 and the issue will be printed using error. 30 31 00:02:31,480 --> 00:02:37,210 And finally, you can see that this method actually has an output and the returns NSFetchRequest 31 32 00:02:37,210 --> 00:02:40,320 result which we know to be an array of items. 32 33 00:02:40,390 --> 00:02:45,250 So, as you can see, there's quite a lot of logic to trace, and that's why Swift tells you that you must 33 34 00:02:45,340 --> 00:02:47,230 specify the data type here. 34 35 00:02:47,380 --> 00:02:53,250 If you don't and you try to run your app, then you're going to get an error that says, "Ambiguous use of 35 36 00:02:53,250 --> 00:02:57,670 'fetchRequest()' which, to be honest, is quite an ambiguous error by itself. 36 37 00:02:57,670 --> 00:03:01,960 But just remember that you need to specify what is the data type of the output. 37 38 00:03:01,960 --> 00:03:09,020 So we know that the output for this method is going to be an array of items that is stored 38 39 00:03:09,100 --> 00:03:09,730 in our persistent container. 39 40 00:03:09,790 --> 00:03:12,960 So what have we been using to store all of those items in the interim? 40 41 00:03:12,970 --> 00:03:22,880 Well, of course, our item array. So we can say itemArray = try using the current context to fetch 41 42 00:03:23,000 --> 00:03:27,090 this broad request that basically ask for everything back. 42 43 00:03:27,290 --> 00:03:33,950 And once you do, then you're going to save the results inside our itemArray which is what we used to 43 44 00:03:33,950 --> 00:03:36,020 load up our table view data source. 44 45 00:03:36,020 --> 00:03:42,320 So before we run, let's make sure that we uncomment this loadItems inside viewDidLoad and let's run 45 46 00:03:42,320 --> 00:03:42,980 our app. 46 47 00:03:42,980 --> 00:03:48,980 So as you can see, when our app loads up, it's already fetching all of the items inside our database. 47 48 00:03:49,340 --> 00:03:56,300 And if we go into our database and we do something, say, let's just delete the last entry, hit the minus 48 49 00:03:56,300 --> 00:03:56,880 button, 49 50 00:03:58,060 --> 00:03:58,830 Delete Row. 50 51 00:03:58,840 --> 00:03:59,870 Yes. 51 52 00:04:00,130 --> 00:04:04,330 And now if we terminate our app and open it again to reload 52 53 00:04:04,360 --> 00:04:09,010 viewDidLoad, then you can see that it's reflected over here as well. 53 54 00:04:09,010 --> 00:04:14,200 Now, the reason why it doesn't update automatically is because we manipulate the data inside the database 54 55 00:04:14,230 --> 00:04:15,370 directly. 55 56 00:04:15,370 --> 00:04:19,830 There's no way for us to be able to reload the data in the table view because we can't call 56 57 00:04:19,830 --> 00:04:22,270 tableView.reloadData from the database, 57 58 00:04:22,270 --> 00:04:22,740 right? 58 59 00:04:22,750 --> 00:04:28,020 And later on, we'll talk about deleting items, then we can look at how we can update that automatically. 59 60 00:04:28,060 --> 00:04:34,690 But for now, we've assured ourselves that our loadItem function works and it fetches all of the results 60 61 00:04:34,780 --> 00:04:38,890 that our items from our permanent stores through our context. 61 62 00:04:38,890 --> 00:04:44,390 So the next thing that we might think about addressing is the"U" in crud, right? Updating. 62 63 00:04:44,410 --> 00:04:47,640 How do we update data inside our database? 63 64 00:04:47,650 --> 00:04:49,620 So that's what we'll do on the next lesson.