Description: Create a Swift iOS application that allows users to create, edit, view, and delete plain text documents that are persisted using Core Data and organized into categories. This version is to use two entities with a relationship: Category and Document with a one to many relationship.

Purpose: This application provides experience in working with the Core Data with a multiple entities that have a relationship in iOS, creating a well-structured application using model-view-controller, and building a user interface with navigation.

Requirements:

Project Name: Documents Core Data Relationships Target Platform: iOS Programming Language: Swift Devices: Universal

This project is to be managed in a public GitHub repository. For the challenge assignment submit the Clone with HTTPS URL for the repository. Do not use the same repo you used to create the versions for saving documents to the file system or Core Data using a single entity.

Create a Swift iOS application that allows users to create, edit, view, and delete plain text documents that are organized into Categories and are saved to Core Data. Category and Document are the entities and Category has a one to many relationship with Document. A Category, for this version, is comprised of only a String that names the Category.

The user is to be able to create, use, update, and delete Categories. Each Document that is created is to be associated with a Category. If a Category is deleted, all the Documents associated with the Category are also to be deleted. Because deletion of a Category can be highly destructive, the user should be prompted (alert dialog or action sheet) to confirm they want to delete the Categoryunless the Category has no Documents associated with it in which case it should be deleted without a confirmation. When a Category name is updated, all the Documents that were previously associated with the Category are to remain associated with the Category by its new name.

The Document entity will need to contain the information for a Document: name, content, size (in bytes), and date modified. When the file-based version was created, the size of each Document was obtained when getting a listing of the files in the Document directory. The file system had this metadata about the files. For the Core Data version, a property for the size should be placed in the entity and when the entity is created or updated the size property is set to the size of the content. You should not query all of the Documents, retrieve them, and count the number of characters in the content of each to have the data to create the Table View that lists the Documents with the name, size, and modification date. Doing this over and over is a bad idea. The size should be a property that gets set in the entity when it is created or updated so that the counting of the characters happens once and not each time the size is needed.

You get decide how you want to organize the user interface. You can follow the model used in the Core Data Relationships - Expenses App with Categories videos or you can do something more interesting (and possibly impressive!)

Goals:

app is well-structured and uses MVC.

names of classes, structs, functions, etc. are well-chosen.

Core Data with a single entity is used.

CRUD (create, read, update, delete) operations on Categorys and Documents are implemented.