Improve item detail fields

[mvasilak]

• Doesn't show empty fields when editing an item of attachment type.
• Properly ends item details editing if no changes have occured when Done is pressed.
• Updates date modified for each saved item details change.
• Fixes issues that reloaded previous collection view values during editing.
• Delays item field edits processing in the action handler, instead of debouncing the cell text fields observation, so the view model is always up to date, even if the Done is pressed to quickly.

[michalrentka]

Some comments for ItemDetailState.Data struct:

• isAttachment in Data should probably a constant? "Normal" item can't become an attachment, so that flag won't ever change.
• creators and creatorIds can be converted to OrderedDictionary too.
• maxFieldTitleWidth, maxNonemptyFieldTitleWidth don't see to be used anymore, can they be deleted?
• should attributedTitle maybe be exluded from equatability of this struct? If for example font size changes (from iOS accessibility settings), the NSAttributedString would differ even if title never changed? It's quite an edge case, but no need to compare attributed string when we already compare the original.

What happens, if the user starts editing, the RItem.changesSyncPaused flag is set to true and then the user crashes at some point while editing? When they open the app, that RItem's sync is still disabled, right? Maybe on app launch/activation we should reset all of these flags to false?

I also noticed a UI bug. When you edit some field and quickly tap "Done", the field change is debounced and since we tap "Done" before the debounce triggers, our UI then shows old state. It's stored in database and synced properly.

[mvasilak]

@michalrentka

Some comments for ItemDetailState.Data struct:

isAttachment in Data should probably a constant? "Normal" item can't become an attachment, so that flag won't ever change.

Changed in e7309d4

creators and creatorIds can be converted to OrderedDictionary too.

Changed in 0ad0e2d

maxFieldTitleWidth, maxNonemptyFieldTitleWidth don't see to be used anymore, can they be deleted?

Changed in d0bfd3c

should attributedTitle maybe be exluded from equatability of this struct? If for example font size changes (from iOS accessibility settings), the NSAttributedString would differ even if title never changed? It's quite an edge case, but no need to compare attributed string when we already compare the original.

Changed in 5bad313

What happens, if the user starts editing, the RItem.changesSyncPaused flag is set to true and then the user crashes at some point while editing? When they open the app, that RItem's sync is still disabled, right? Maybe on app launch/activation we should reset all of these flags to false?

This would apply only to newly created items, as editing existing items is fully live-updating now. In theory there should be only one such entry, but just to be safe, assuming they could be more, we could offer an alert with choices to the user:

• Go to the edit screen (available only when there is one such item)
• Delete all such pending items
• Save all such pending items

I also noticed a UI bug. When you edit some field and quickly tap "Done", the field change is debounced and since we tap "Done" before the debounce triggers, our UI then shows old state. It's stored in database and synced properly.

This should be fixed in 20126a8

[michalrentka]

What happens, if the user starts editing, the RItem.changesSyncPaused flag is set to true and then the user crashes at some point while editing? When they open the app, that RItem's sync is still disabled, right? Maybe on app launch/activation we should reset all of these flags to false?

This would apply only to newly created items, as editing existing items is fully live-updating now. In theory there should be only one such entry, but just to be safe, assuming they could be more, we could offer an alert with choices to the user:

• Go to the edit screen (available only when there is one such item)
• Delete all such pending items
• Save all such pending items

Right, I didn't notice that changesSyncPaused is only used when creating a new item. In that case EndItemDetailEditingDbRequest could probably be renamed to something like EndItemCreationDbRequest and call it only when we're actually create an item in ItemDetailActionHandler.endEditing.

The whole ItemDetailActionHandler.endEditing can be changed a lot. We don't even need to compare snapshot to data at this point, everything has been stored already. Just always call the thing which is in guard else now and then call EndItemDetailEditingDbRequest for item creation so that syncing is allowed and nothing else is needed. The whole endEditing has leftovers from when we had Cancel + Save buttons, but it's unnecessary now. Am I misunderstanding something?

[mvasilak]

The whole ItemDetailActionHandler.endEditing can be changed a lot. We don't even need to compare snapshot to data at this point, everything has been stored already. Just always call the thing which is in guard else now and then call EndItemDetailEditingDbRequest for item creation so that syncing is allowed and nothing else is needed. The whole endEditing has leftovers from when we had Cancel + Save buttons, but it's unnecessary now. Am I misunderstanding something?

Indeed, check e183a07 & 8e54ace