Application Editor appearance

[AlexWills37]

Currently, the application editor appears as a rounded rectangle just overlaying on the screen. The original vision is to have this be like the contacts app when you create a new contact, where it slides up from the bottom, ending with a visible cutoff at the top, but overflowing past the bottom.

[AlexWills37]

This is a sheet modal! First, I will try to make it work as a sheet modal when you create a new application.

Then, like the contacts app, I'd like to separate a "detailed view" when you tap on an application (push) from the same editor view when you click an "edit" button. This editor will still be a modal, but now it will be a fullscreen cover, also like the contacts app!

[AlexWills37]

On the creation of the "DetailedView":
I'd like to have the ability to make quick edits, such as Status, Notifications, and Deletion.
Then, the user will also be able to hit an "edit" button to pull up the full editor.

For quick edits, it makes sense to simply create an instance of the editor VM alongside the detailed view's VM, and to use public functions with the editor.
Right now, the editor works as follows;

• Create proxy values for the Application that the user can edit.
• Upon cancellation, do nothing.
• Upon saving, update the Application model, then save those changes to the database.

In this way, the Application object remains an accurate representation of the database's state (Notifications are handled outside of the database layer). Technically, the Application object is "outdated" as soon as it is fetched (external modifications to the database are not reflected in any fetched models), but if we only work with a single instance of the model object, we should be able to ensure consistency between references and save actions.

It is in the ApplicationList where we retrieve new instances of the model objects upon any database changes; however, since these instances are not able to influence the database (by opening another editor instance) when the detailed view is present, we should not have to worry about our "older" instance not accurately reflecting the database.

[AlexWills37]

The Application object is a struct, not a class! So when the instance of the Application is modified via the editor, the original instance stored in the DetailedViewModel is indeed outdated. Some options are now:

• Re-obtain the Application model from the database after any edits.
• Manually sync the values (tight coupling between view models)
  • Reimplement quick edit features?
  • Copy back the Application from the editor?
• Make the Application a class

  I'm not entirely sure if this is feasible with GRDB. It probably is, but I think re-obtaining the model from the database would be fine as well.

[AlexWills37]

The editor is successfully a modal. From the application list screen, users can click "New Application" to pull up the editor modal. Alternatively, users can click an individual application to pull up a detailed view, and from there users can pull up the editor modal by clicking an edit button.

Now, I need to make the detailed view look better. I'd like to start with a dedicated view for the status selector, which I want to reuse between the editor and the detailed view, so users can quickly edit the status of their application without too many actions.