HandlerThread for reconnecting AWSIoTMqttManager

[rvp-thunderbuild]

Added a separate HandlerThread for reconnect attempts and publishing of queued messages.
This way the former doesn't need to happen on a newly created thread each time, and the latter no longer runs on the Main thread (since that is really not the best place).

This issue was mentioned before:
#532

[minbi]

Hi @rvp-thunderbuild ,

How does this pull request differ from #601 which creates and disposes of the handler thread when execution is completed?

[rvp-thunderbuild]

Pull request #601 merely cleans up the handler thread after reconnecting. My proposed changes make use of a single handler thread instead of instantiating a new one each reconnect attempt. And also use this thread for publishing queued messages after a successful reconnect attempt instead of running these on the main thread.

[mutablealligator]

@rvp-thunderbuild Sorry for the delayed response. Can you rebase the changes with the current master and update the PR?

[mutablealligator]

I notice a difference here: The HandlerThread you created uses its looper whereas the existing code here uses the looper from the main thread. Do you have any reasoning behind this change?

[rvp-thunderbuild]

I don't believe that the main thread should be responsible for publishing messages from the Queue since this is network related. Originally the first message was published by the reconnecting thread, while all successive messages where published by the main thread. I changed this so that all queued message will be published by the reconnecting thread instead.

This makes more sense to me since either there is no connection and that thread is being used te reestablish it or there is a connection and that thread can be used to publish queued messages.

[mutablealligator]

@rvp-thunderbuild Sorry for the delayed response. Can you rebase the changes with the latest changes from master and remove the changes in .idea/ files?

[rvp-thunderbuild]

@kvasukib I merged the master branch into this one and updated the .idea/ files

[mutablealligator]

@rvp-thunderbuild Sorry for the delayed response. I see that the following 4 unit tests failed. Can you take a look at them if you have some cycles?

> Task :aws-android-sdk-iot:test

com.amazonaws.mobileconnectors.iot.AWSIotMqttManagerTest > testOfflinePublishQueueWithCallbacks FAILED
    java.lang.AssertionError at AWSIotMqttManagerTest.java:2148

com.amazonaws.mobileconnectors.iot.AWSIotMqttManagerTest > testDefaultDrainingInterval FAILED
    java.lang.AssertionError at AWSIotMqttManagerTest.java:2425

com.amazonaws.mobileconnectors.iot.AWSIotMqttManagerTest > testOfflinePublishQueueWithError FAILED
    java.lang.AssertionError at AWSIotMqttManagerTest.java:2532

com.amazonaws.mobileconnectors.iot.AWSIotMqttManagerTest > testLongerDrainingInterval FAILED
    java.lang.AssertionError at AWSIotMqttManagerTest.java:2468

The tests are located here: https://github.com/aws-amplify/aws-sdk-android/blob/master/aws-android-sdk-iot/src/test/java/com/amazonaws/mobileconnectors/iot/AWSIotMqttManagerTest.java

[rvp-thunderbuild]

@kvasukib Those unit tests seem to fail because the OfflinePublishedQueue is no longer emptied from the main thread. Those tests are run with Robolectric instead of an actual device and any scheduled tasks are unable to run without specifically triggering these using Schedulers. In the current tests this is done for the main thread, however this no longer has any effect since it needs to be done for the new ReconnectHandlerThread.
I'm not a expert on Robolectric so I don't know if that is even possible without exposing the used HandlerThread to your unittests, which doesn't seem like a very good idea either.

[mutablealligator]

@rvp-thunderbuild We will work on to update our unit tests to accommodate the changes you have made in this PR. Your effort is much appreciated!

[jamesonwilliams]

This PR unfortunately has gone stale before it could be addressed. Will close for now. Please re-open if it can be updated.