If a status in a conversation view controller creates a work item to
update the timestamp in 1 minute, but the view controller is deinit'd
before that time elapses, the mastodonController instance will be nil,
resulting in a crash.
The DispatchWorkItems's are cancelled by the respective cell deinit
methods. But if the work item has already begun, cancelling it has no
effect, potentially leading to a crash in the conditions described above
are true. Using a weak reference to self fixes this.
Additionally, don't unnecessarily recreate the work items every time.
They don't capture any local variables, only self, so nothing changes.
Notifications that are of the same type but are separated by a groupable
notification of a different type are now considered groupable. For
example:
favorite 1 (status 1)
reblog 1 (status 1)
favorite 2 (status 1)
reblog 2 (status 1)
mention 1
reblog 3 (status 1)
will be grouped into:
favorite 1, 2 (status 1)
reblog 1, 2 (status 1)
mention 1
reblog 3 (status 1)
when opening via a context menu preview.
The constraints for the top controls were being set only once, but when
showing a large image in the contxt menu preview window, the top inset
safe area is 0 and didn't become 44 (the value for notched devices)
until the preview was expanded.
Fixes#86
When loading a draft:
If the draft was created from a different account than the current one:
If the draft was in reply to a status, don't allow it to be loaded.
If the draft was not in reply to a status, prompt the user whether
or not to load the draft.
If the draft was in reply to a different status than the current one:
Prompt the user whether or not to load the draft.
Otherwise, load the draft.
Draft replies created from other accounts can't be loaded from different
accounts because the status for inReplyToID of the draft will have a
different instance-local ID if the two accounts are on different
instances.
See #16
instead of enum
Additional categories can be added, which would cause a crash when
decoding.
As the category isn't used for anything, storing it as an enum value is
not necessary.
The instance timeline controller needs to store a strong reference to
the instance-specific MastodonController since the timeline VC only
holds a weak reference, and unlike normal screens, the scene session
doesn't hold onto the MastodonController for other instances.
The timestamp update work item shouldn't retain a reference to the cell.
It can be unowned because when the cell is deinit'd, the work item will
be cancelled.
Shadowfacts