If a conversation disappears while the activity is paused (e.g. if the
user is kicked from a channel, or if another client attached to an
irssi-proxy has chosen to leave that channel), we currently aren't
removing the view from the DeckAdapter when we resume. This results in
leaking a Conversation object until the user explicitly asks for the
conversation to be closed or the activity finishes, and is also
confusing because the user may not receive any indication that the
channel was parted in the first place.
There's a good case for leaving the MessageListView in place, with a
note indicating that the user has been kicked or parted from the
channel, but for that to work, we need to keep the Conversation object
in the server's list of conversations -- otherwise the behavior will
differ depending on whether the user left the activity via the Back
button or the Home button, which is counterintuitive.
For now, just remove the stale view from the DeckAdapter, which fixes
the leak and the potential user confusion.
Currently, when the user opens a ConversationActivity, goes off to do
something else without closing it, and then comes back to the activity,
conversations started since the ConversationActivity was paused (e.g. by
an incoming private message) will not appear in the ConversationGallery;
this is because we never check for new conversations in the onResume()
path.
Fortunately, this is an easy fix: we're already looping over all the
conversations in onResume() in order to add new messages to the
MessageListViews, so just look out for the new conversations and add
them to the ConversationGallery when we see them.
I thought this was removed when we moved the setImeOptions() further
down in onCreate(), but it's still here somehow. This causes the Send
key on the keyboard to disappear when fullscreen IMEs are disabled.
When an activity sets FLAG_FULLSCREEN on its window, Android assumes
that the window size will always be the same as the screen size. This
causes the window to scroll instead of resizing when the soft keyboard
comes up, which (according to a quick Google search) isn't the behavior
most developers are expecting.
This patch implements an ugly workaround: extend the root element of the
layout (in our case, a LinearLayout) to hook into the onMeasure()
callback, which is called when the window size changes, so that we can
resize ourselves when the window size changes.
The current auto-reconnection implementation will only try reconnecting
once, immediately after the server is disconnected. This will of course
almost always fail if the network is down or otherwise unavailable, so
as it stands, enabling auto-reconnect isn't particularly useful.
This patch implements multiple retries for auto-reconnect, with the
frequency of retries controlled by a preference. The Android alarm
infrastructure is used to schedule reconnection attempts; if the phone
misses a scheduled attempt while it's asleep, the reconnection will be
attempted the next time the phone wakes up.
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.
When the user asks for a disconnect from the ConversationActivity, there
is a race between the IRCConnection, which is waiting for the server to
acknowledge the QUIT before calling onDisconnect(), and the IRCService,
which will invoke dispose() on the IRCConnection when
checkServiceStatus() is called during the activity shutdown. If the
dispose() wins, the thread running the onDisconnect() is terminated,
leading to the cleanup being unfinished. This causes the disconnect
notification to be unreliable, and can result in the list of servers in
the ongoing notification to be out of sync with reality.
To fix this, introduce a new field isQuitting to the IRCConnection,
which is set to true when quitServer() is called and cleared once
onDisconnect() has finished. If dispose() is called while isQuitting is
set, it sets disposeRequested instead of doing the dispose itself, and
onDisconnect() will call through to super.dispose() once it's finished.
Note that this requires a change to PircBot to allow the overriding of
quitServer(String message), which is declared final upstream.
