You will learn to develop sophisticated user interfaces for iOS, with a focus on user interface design best practices, UI animations, and responsive design. You will learn about the key UI widgets, mapping interfaces and view restoration.
Case Study: To Do List Part 7
Loading...
来自 University of California, Irvine 的课程
iOS 用户界面设计最佳实践
181 个评分
University of California, Irvine
181 个评分
课程 3（共 6 门，Specialization iOS Development for Creative Entrepreneurs）
从本节课中
Table Views, Core Data and User Interface Integration
In week 4, we will look at table views, core data, and user interface integration. We will cover table views, table views plus core data, and you will finally learn how to put it all together. We will end the course with a peer review assignment called To Do Manager.
与讲师见面
Don PattersonAssociate Professor
Informatics and Computer Science
Sam KaufmanPartner at Gradient
[MUSIC]
Okay so we're going to just do a walk through of the code to make sure that we
understand everything that's happening.
We have done a pretty good job.
When you get all these different pieces together you've got a lot of interacting
and moving parts, and understanding how the code is flowing,
how the information is flowing, how the views are flowing is really important.
And so for your peer review assignment, what we're going to ask you to do is
to duplicate this process that we've gone through, but what we'd like you to do is
instead of using due date and details would like you to add something else.
We like your, each of your due date entities to have rtitles.
But we like you to have other fields that you keep in track of associated
with your due dates.
It could be anything, it could be people that are signed, locations,
materials, whatever you're interested in.
And you can also change the aesthetic look of it if you'd like, but we want to
make sure that you have these three view controllers but present as a master and
detail view, which you have created kind of from scratch, the way that we have.
And we'd like you to implement the adding button and the sorting and
the trash can all that.
The details are written in peer review.
But the place for you to get creative is in the aesthetics of it and
in choosing what you want in your to do entity items.
And then we want to see you be able to put all of these pieces together.
So, what we want to do is we just kind of want to review the overall system.
Let's just take a look at the code and
we'll start from the bottom of the view hierarchy and move our way up.
All right, so let's start at the view controller and we look at the header.
We remind ourselves that, oh yeah, this is an element that handles
manage object context and manages ToDo entity which means that at some point,
it gets called with an incoming managed object context and
an incoming to do entity is our view controller, our detail controller.
So those things are important for being able to edit the detail.
If we start at the top, we keep track of the managed object context locally.
We keep track of the to do entity that we're editing and working with locally.
We have a connection to the title field in our UI
with a connection to the details view on our UI and the due date filter on our UI.
Remember we had one problem where I had incorrectly assigned this title field,
not to the text field but to the label.
So I had to break the connection and rebuild that.
We're keeping track of whether the reason why we're going back was because we were
deleted or not.
Because if we are deleted, we don't want to save
an empty ToDoEntity item over the one the one that was just deleted.
All right, so in contrast to other views, we're not doing anything on load,
and we don't do anything with this receive memory warning.
And we have written this helper function called save my to do entity which
saves the scratchpad by using the managed object context here.
That's just used by us locally.
If someone finishes ending the text view,
if we get the notification that the text view has been done editing, we save that
information from our user interface into our entity, and then we save our entity.
Actually, I think maybe what I want to do is for clarity,
it kind of makes sense to talk about the viewWillAppear first.
Let's just move did up here, viewDidLoad is called once,
but viewWillAppear gets called several times.
And, so we're going to initialize our view controller at this point.
We're going to say the reason we don't want to start off thinking that we were
deleted so we're not deleted.
We want to set up the fields that we're going to be looking at.
So we set up the title field in the UI is going to be equal to whatever our local
entity is.
The point which were called here.
Remember, prepare for segue was called before view will appear.
So, prepare for segue was responsible for
passing in the local to do entity before we got to this point.
We're going to set the details field, and down here,
we're going to set the due date field.
So, that's setting up the form.
And then we're going to detect edit
ends of text views by notification.
Here's our helper function which is to save our entity.
So if we get that notification that our text view did enter and
we are the ones that hosted the text view, then we're going to go ahead and
set our to do entity equal to the details of our UI then we're going to save it.
Let's see, I guess that makes more sense at this point to have the code for
the other things I can edit it too.
Let's move those up here.
So if our title field is edited, we take our local entity and
we set it equal to whatever the user entered and we save it.
If our due date gets edited, we get the due date picker and we save it.
If the trash can is tapped, we say well, turns out we were deleted.
In that case, we want to delete our object from the scratch pad.
We want to save our scratch pad, that could probably be
titled better because we're not necessarily saving my to do entity.
We're saving the state, because we've deleted the object and so
we're not actually saving the entity, we're just saving the state.
And then because when you hit the trashcan, you want to go back.
We manually say okay, tell our navigation controller we want to go back to the top.
That's going to cause view will disappear to get called.
If view will disappear gets called, and as long as the reason we're going back
isn't because we were deleted, we're going to grab all of the UI elements.
We're going to put them into our entity, and
we're going to do one last save to make sure we capture everything.
And then we're going to take ourselves off of the notifications for
changes to the text field.
All right, this is code we didn't use,
we don't have any segues that leave our view controller, so we don't need this.
And then lastly, we have the two methods that were implemented in order
to satiate the protocol, so we had to implement it.
Okay, so that's the lowest level of our view hierarchy, that was pretty clear.
Now, if we go up one and we look at the table view controllers, we say, okay,
our table view controllers, it only received managed object contacts.
It never had to receive a to do entity,
because it was the one that is sending to do entities down the hierarchy.
It only receives a managed object context from above.
And within our TableView controller, we start at the top.
We say okay, this is something that manages our TableView data source Delegate
and FetchResultsController.
So this is connecting us to core data and the results there.
Our manage object context is so
that we can keep track of our core data connection.
And our results controller is our active query that's giving us
updates about our underlying changes.
When we first load our view controller we go ahead and initialize our query.
We never do anything with our received memory warning, so we can get rid of that.
We take care of the things that are required for
our UI table view delegate function.
So we say we're doing not grouping, so we're returning one group at all times.
And the number of rows in our section doesn't vary based on section.
It's always the number of objects for our entire query.
So this section could be hard coded to zero, but we didn't.
When we need to set up the cell for a given row,
we go ahead and we pull out the particular ToDoEntity from our query that corresponds
to the section and row that our user interface is asking for.
We create a new cell by asking for
a cell from our pool associated with our prototype cells.
And then when we do that we say okay we know it's a my UI table view cell,
we set that in the user interface.
So we're going to set all the internal fields based on the to do
item that's associated with this.
So we're going to set in the prototype cell we're going to set the label for
the title and the due date.
We're going to keep a copy of the ToDo entity, so that on prepare for segue.
We can use that on the way down.
All right, and then down here,
when we initialize, this is called immediately after view did load here.
We initialized our set result controller,
this is setting up the query that we're going to keep live while we're running.
You know what, next time I want to run this, actually want to change this so
it's not to do title, but I want to sort by due date.
I think that, kind of makes more sense.
And then we go ahead and we launch our first one, and after that,
we're just going to get live updates.
And the updates that we get, will be that something has changed, in which case,
we begin an animation.
We get information about what did changed and how it changed and
we execute the appropriate swaps.
Then finally when we're done with all of our changes, we end the lock and
we execute all of those animations.
So on the way down, as we are going form our table view down to our detail
controller, we say okay, well on the way down, we need to
pass down the managed object context, so the detail controller can save the state.
So we're going to pull out the child from our segue by asking for
the segue's destination view controller.
We're going to cast it to an object that implements these two.
And we need it to implement these two, because we're going to call
receiveMOC here, which is associated with DPHandlesMOC here.
We're going to call receive to do entity item which is associated
with DPHandles to do entity item there.
Because there are two ways that a segue can be initiated
from our table view controller.
One is from our add button,
we check to see if it's being generated by something af a UI button bar class.
And if it is, we create a brand new to do entity item.
If it's not, then it must be that we want to edit one.
In which can then we need to get the current cell that we are working from,
that's our sender.
We need to cast it so that it's our class.
And then we're going to set the item that we're going to pass down to our
child to be this one that we're editing rather than a new one.
And then we pass it down to the child that we're editing.
This is all code we didn't use.
Then finally we receive a managed object context from our parent as well.
All right, let's take a break for a second and let's look at sorting by due date.
So I changed that one thing in our Fetch Results controller.
And now all of our items get sorted by due date.
These happen to have the same due date, so that's no fun.
Let's add a new one.
Let's say, January 5th.
And you can see January 5th gets dropped in there, but
let's add one that's earlier.
Let's also give it a Z so it's not alphabetically the same.
Let's go back in time.
It doesn't makes much sense to have a due date in the past but
we can see that we're ordering by due dates now instead, so that's kind of neat.
Okay, so our UI table view controller contain UI table view cells.
And the main thing about this was just encapsulating the presentation of
the prototype cells.
And locally, it was keeping track of the entity that it was representing.
And it was keeping track of a connection to the label and the UI and
the connection to the due date label and the UI.
And it implemented this field that when the fetch results controller and
the table view delegates needed to build a table prototype cell.
You just pass up the entity that you want to use to build the cell and then this set
internal field is responsible for building the UI based on that to do entity item.
Okay and then as we go back up one more to that navigation controller.
This is the top root view controller in our hierarchy.
We see that mostly the only thing we needed here was we needed the ability
to pass down our managed object contacts.
And when we received a managed object contacts from our parent.
Then what we did here, is we kept
track of it locally and then because this is a navigation view controller,
it doesn't do a segue in order to initiate the table view presentation.
So we just immediately as soon as we receive it we capture the connection
to the table view, and
we immediately pass that manage objects down to the table view.
And then finally, as we go to the top in the app delegate,
the only thing we added to the app delegate's template was this initial
process of passing down the managed object context down the view hierarchy.
And that was all represented here in the main storyboard.
Okay, so that's really nice.
Again the thing that you're going to do differently in the pure view is your
going to change the aesthetic and editing process.
And you're going to change which editing felids,
which elements are in your core data entity.
All right that really was very fun.
I really am very satisfied with the end result of this product and
I hope that you guys do too.
And maybe you might even find that this is an application that you
are interested in using personally.
Maybe you can add something else to it to make it the world's best
to do list manager.
My personal theory is that it's not the to do list manager that needs to be better
is that we need less to-do's.
Just saying.
All right, thanks for your attention.
See you in our next video.
[MUSIC]
