Migration to AndroidX
- Update to API level 29
- Update Java sourcecode and xml import statements
- Upgrade Butterknife Version 10 AndroidX support
- Set Java 8 compile options due Butterknife needs it
This PR fixes some issues with connections and threading. Specifically, the change in #618 introduced threading in `HostConnection`, which had some issues. To fix them, the following changes were made:
- A specific TCP listener thread is used and manually started, instead of using one of the threads in the pool. The TCP listener thread is a long lived thread that should always be running (as long as the connection is through TCP), blocked listening on the TCP socket, so it shouldn't be managed in a pool, where, theoretically, it can be paused and reused.
- Changed the number of threads to 5. We shouldn't need more than this, otherwise we can overwhelm some Kodi hardware.
- Had to sprinkle some `synchronized` to avoid race conditions. For instance, through a TCP connection, as soon as Kore is opened (on the remote screen) it will call at least `GetActivePlayers`, `GetProperties`, `Ping`. If the TCP socket isn't set up yet, each of these calls would create a socket (and a TCP listener thread), so we would open 3 or more sockets when we should just open 1. A `synchronized` in `executeThroughTcp` prevents this. The others prevent similar issues.
Aditionally:
- Tweaked the playlist fetching code, so that it happens exclusively in `HostConnectionObserver` and when PlaylistFragment is notified of changes, it already gets the playlist data. This somewhat simplifies the code, and makes it more consistent with the Player Observer code;
- Change `EventServerConnection` to accept a Handler on which to post the result of the connection, so that the caller can control on which thread the result is called;
- Calls to the various `RegisterObserver` loose the reply immediately parameter, as it was always true.
The onDestroyView method is used to unregister the application observer
from the dialog. However the parent got called first which destroys the
view of the dialog. This could lead to Null Pointer Exceptions when
the listener tries to update the UI of the dialog right after it was
destroyed.
The VolumeControllerDialogFragmentListener was created twice as creation
was triggered on both the down and up event of the volume keys. This has
been changed to only trigger on down events.
The applicationObserver was never unregistered resulting in a memory leak
and even worse, crashes when destroyed dialogs still got called through
the applicationOnVolumeChanged callback.
Also changed the view resource identifiers used by the controller dialog
as it used the same resource identifiers as the now playing panel.
Refactored MusicListFragment and PVRListFragment to use AbstractTabsFragment
Fixed scrolling in a nested scroll view using espresso
Fixed issue with setting and checking Kodi major version
There's no need to have so many classes to handle the hardware volume keys. This PR simplifies it, without duplicating any more code than was already duplicated.
DoomMortal
Synced Synapse
Martijn Brekhof