With landscape view enabled (e.g. e06b2c7) in the app and auto
rotation enabled on the phone, switching between portrait and
landscape orientations leaks instances of MainActivity. This prevents
garbage collection of not just the MainActivity object, but fragments
and other objects referenced by the Activity.
This is caused by repositories, the AppContext instance, the player
service, and authentication code maintaining a reference to the
context which with they are initialized. So rather than initialize
these with an Activity context, pass them the Application context.
Activities are torn down and rebuilt on screen rotation. The
Application context is not.
To enable instantiation of the FavoritedRepository with the
Application context, delay that repository’s initialization until
first use. This ensures the Application context is fully initialized.
It is not fully initialized until the MainActivity has been fully
initialized.
With the BottomSheet open, while trying to tap one of the
controls (esp. add to playlist and favorite buttons) it is easy to
miss the touch point and tap directly on the BottomSheet.
This tap bleeds through to whatever fragment is currently displayed in
the navigation area (Artist, Album, Playlists, etc.). That tap
changes the view in the navigation panel. For example, if the Artist
fragment it current, it will open a list of the artists albums.
That change may be surprising when the BottomSheet is toggled closed.
So, ignore BottomSheet taps outside the active controls.
Having changed the context object in CoverArt from a received function
parameter to an initialization time derived variable, withContext no
longer needs a Context parameter.
That leaves the method misnamed. So rename withContext ->
requestCreator and drop the first parameter.
Address "java.lang.IllegalStateException: Too many receivers"
exceptions. (See Issue #145). Each new Picasso object registers its
own NetworkBroadcastReceiver. Worse, we create a new Picasso object
each time we transform an AlbumCover image. So do not create
unnecessary Picasso objects.
Rather than depend on receiving a Context object when called to load
an cover art, fetch the Application context as returned from FFA.get()
at singleton construction time. The Application context is long
lived.
This has an additional advantage. Not generation new Picasso objects
for each CoverArt image avoids holding a reference to an object that
cannot, later, be garbage collected.
When Gradle version was bumped to 7.0.0, it required Java version 11.
In 82b9121 (2022/01/05), .sdkmanrc was adjusted to accommodate. But
app/build.gradle.kts was not.
More recent Gradle releases have started to complain:
,----
| > Could not resolve all files for configuration ':classpath'.
| > Could not resolve com.android.tools.build:gradle:7.4.2.
| Required by:
| project :
| > No matching variant of com.android.tools.build:gradle:7.4.2 was found. The consumer was configured to find a library for use during runtime, compatible with Java 8, packaged as a jar, and its dependencies declared externally, as well as attribute 'org.gradle.plugin
| .api-version' with value '8.0.2' but:
| - Variant 'apiElements' capability com.android.tools.build:gradle:7.4.2 declares a library, packaged as a jar, and its dependencies declared externally:
| - Incompatible because this component declares a component for use during compile-time, compatible with Java 11 and the consumer needed a component for use during runtime, compatible with Java 8
| - Other compatible attribute:
| - Doesn't say anything about org.gradle.plugin.api-version (required '8.0.2')
`----
Adjust gradle’s specification to suit.
Hugh Daschbach