At the moment, the reconnect feature is somewhat glitchy, popping up
multiple reconnect prompts even if a reconnection succeeds, and
occasionally causing crashes. A successful reconnection results in the
conversation history being cleared, which is an annoying outcome when
connected over an unreliable network.
This patch does the following:
* Keep track of whether a reconnect dialog is active, to prevent
multiple dialogs from opening.
* Introduce a new field to the Server object, mayReconnect, which is
used to keep track of whether a reconnection should be attempted in
the event of a disconnection. It's set to "true" when we connect to a
server, and "false" if the user asks for a disconnection.
* Prevent the clearing of active conversations and conversation history
on disconnect, unless the user specifically asked for the disconnect.
* Keep the IRCService running even when no servers are connected, unless
the user has disconnected from all servers herself. This is needed
for reliable auto-reconnects (see next patch), but has the side effect
of keeping conversation history around even if the activity isn't open
when a disconnect happens.
There are at least two significant memory leaks in Yaaic, which cause
the client to force close after a few hours with an
OutOfMemoryException:
(1) The IRCService holds Conversation objects, which contain a
MessageListAdapter, which have references to the ConversationActivity
context. This causes Activity contexts to outlast the Activity, causing
a significant memory leak over time.
Fix this by holding the MessageListAdapter in the ConversationActivity's
DeckAdapter instead of in the Conversation objects. The DeckAdapter's
lifecycle matches that of the Activity, so this prevents the leak.
(2) Every call to DeckAdapter.getView()/renderConversation() creates a
new MessageListView and adds it to the deck. But adding the view to
the deck causes the deck to take a reference to the view, leaking the
MessageListView until the Activity is finished. (This has the effect of
exacerbating the first leak, since the Activity context holds a
reference to the deck.)
Fix this leak by caching MessageListViews in the DeckAdapter, and
returning an existing MessageListView for a Conversation in getView() if
one already exists.
With activity:launchMode = standard, we get duplicated activities
depending on the task the app was started in. In order to avoid
stacking up of this duplicated activities we keep a count of this
root activity and let it finish if it already exists
Launching the app via the notification icon creates a new task,
and there doesn't seem to be a way around this so this is needed
Sebastian Kaspari