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.
UITextView uses TextKit internally, unlike UILabel, so no additional
code is needed to keep the TextKit and view representations of the text
in sync since they are one and the same. This means that detecting which
character was tapped in a content text view is much more accurate, which
means link handling is substantially imrpoved.
Fixes#20
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
Closes#49
This is a workaround for UIKit's built-in suggested context menu actions
not working as expected, and should be replaced with the system thing if
it becomes possible.
Shadowfacts