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.
Use clearComposingText() when inserting nick completion to ensure
that autocorrect doesn't try to replace the completed nick on the next
keypress; thanks Thomas Martitz for pointing out the bug
* If there's a new message notification, keep showing the "New messages
in" content text, even after a disconnect notification.
* Handle the case of a channel/query name duplicated between two or more
connections more gracefully in new message notifications
* Fix a race in updating notifications
(1) Let full-screen IMEs wrap the text into multiple lines instead of
making the text scroll off the screen.
(2) Provide a preference to let the user choose whether or not to enable
autocorrection of typed text.
(3) Provide a preference to let the user choose whether or not to enable
autocapitalization of sentences. Note that even when this is enabled,
autocapitalization will only happen if the option is also enabled in the
IME.
(4) In landscape mode only, don't replace the Enter key with a Send
button, to make it harder to accidentally send a message. (We can't do
this in portrait, because we would be left without any send button at
all -- perhaps the input line should be changed to be similar to the
text message application, which has a send button next to the input
line?)
The current method of supplying an onKey handler for the input line
(having the activity implement OnKeyListener) is somewhat unusual -- the
documentation recommends creating an anonymous inner class to pass to
setOnKeyListener(). Do this, while refactoring the code to make it
somewhat more readable and removing some instances of code duplication.
Features:
* Now displays the number of mentions that the user has not seen in the
notification.
* When no mentions are outstanding, display which servers the user is
connected to, not the last message.
* When more than one mention is outstanding, display the names of the
conversations with new mentions, not just the last message received.
* Notifications of mentions are suppressed if you're in the conversation
at the time of the mention.
* Notifications of mentions automatically clear when you bring up the
conversation.
* Vibrate notifications now generate the user's chosen default vibrate
pattern, not a hard-coded one.
* Add ticker text to the notification that's displayed when the IRCService
goes into the foreground, instead of displaying a blank ticker.
To allow for all of this, the implementation moves most of the details
of generating the notification text into the IRCService, which now
exposes addNewMention() and notifyConnected()/notifyDisconnected()
methods instead of the lower-level updateNotification().
As of now, private messages where the sender is our nick end up in
a query window targeted at us. Show these messages in the query window
of the target instead, which is probably what we want.
This is useful for use with irssi proxy, which will send messages sent
by another client attached to the proxy to us in this way.
(Note that this patch makes a change to PircBot to pass the target of a
private message to the onPrivateMessage handler.)
As of now, the activity does not remember whether a conversation is
switched across configuration changes (such as screen rotations). Fix
this by adding onSaveInstanceState() and onRestoreInstanceState()
callbacks in the activity to pass this information to the new instance.
To make the implementation of this simpler, all code to configure the
MessageListView, which was duplicated in several places in the codebase,
has been moved to the MessageListView's constructor.
While we're at it, make the padding setting independent of screen
density instead of specifying in fixed pixels (equivalent to specifying
the value in dp instead of px), and increase the padding for switched
views. This ensures that message text isn't obscured by the gradient at
the edges of the ConversationGallery, which started happening when we
began caching MessageListViews in the DeckAdapter.
Each IRCConnection starts an input thread and an output thread when
created; if not stopped, these threads continue to hold the IRCService,
resulting in a leak when the service is stopped. Fix this by using
PircBot's dispose() to stop the threads when disposing of the
IRCConnection.
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.
If a private message that should open a new query window contains a
mention of the user's nick, the expected new window fails to open
because the isMentioned() path tries to use
server.getConversation().setStatus(), and server.getConversation() is
null in this case. Fix this by moving the attempt to highlight the
window to a point where a conversation is guaranteed to exist.
This has two advantages:
(1) The activity remembers which conversation was last selected if it's
destroyed (e.g. via the Back button) and then recreated with the connection
still running.
(2) It prevents onCreate() from clearing all the mentioned notifications for
the conversations in that activity.
Rey Rey