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.
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.
dependency injection
The places still using the .shared property are cases where there is no
view controller from which to (easily) get the appropriate instance,
such as user activity and X-Callback-URL handling. These uses will need
to be revisited once there are multiple MastodonControllers.
See #16
Also, copy the state between screens, so e.g. expanding a status in the
timeline and then opening that conversation already has that status
expanded.
This intentionally doesn't store the sensitive attachment visibility
state, since showing text when not necessary is less dangerous than for
images. (Possibly a preference for this in the future?)
Closes#55
Shadowfacts