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.
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.
Instead of simply returning the content text view from hitTest(_:with:),
we need to call the super method so that the system still performs its
own checks.
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
When the requested range has no results, no pagination data is returned,
so the existing `newer` request range is replaced with nil. As there
was no new data, the existing request range is still correct and should
not be replaced.
Fixes#75