Retain the bitmap cache

[jeffdgr8]

Use a retained fragment to retain the Renderer bitmap cache between configuration changes.

[jeffdgr8]

These changes are important to avoid redownloading all bitmap icons after each configuration change.

[barbeau]

@jeffdgr8 Thanks so much for this contribution, and your patience!

This looks good in general, and follows the Android guidelines for handling caches with configuration changes:
https://developer.android.com/topic/performance/graphics/cache-bitmap#config-changes

A few comments in-line (only one requires action).

One test is failing due to the transition of using activities instead of a context - KmlRendererTest.testAssignStyleMap()

Could you please fix this? I believe it should be relatively straightforward and just involve instantiating an activity in the test and passing it in (null was previously passed as the context).

java.lang.NullPointerException: Attempt to invoke virtual method 'android.app.FragmentManager android.app.Activity.getFragmentManager()' on a null object reference
at com.google.maps.android.data.Renderer.<init>(Renderer.java:119)
at com.google.maps.android.data.kml.KmlRenderer.<init>(KmlRenderer.java:48)
at com.google.maps.android.data.kml.KmlRendererTest.testAssignStyleMap(KmlRendererTest.java:19)
at java.lang.reflect.Method.invoke(Native Method)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at androidx.test.internal.runner.TestExecutor.execute(TestExecutor.java:56)
at androidx.test.runner.AndroidJUnitRunner.onStart(AndroidJUnitRunner.java:392)
at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:2156)

[barbeau]

Note that this is a breaking change for apps, as any apps passing getApplicationContext() would need to change to passing an Activity, as shown here in the demo app.

@jpoehnelt Normally this would require a new major version release in traditional semantic versioning, but given that we're still pre v1.0 I don't know your feelings on this.

[barbeau]

Thanks @jeffdgr8, this looks good to me!

@jpoehnelt I'm requesting your review on this too before merging because it includes a breaking chance in the contract with applications - instantiating KmlLayer now requires an Activity as an argument while it previously allowed the more general Context (see KmlDemoActivity for an example). This is a relatively simple change to make in an app but still breaks the build for users when they update to the version that includes this PR. Normally this would require a new major version release in traditional semantic versioning, but given that we're still technically pre v1.0 I don't know your feelings on this.

[jeffdgr8]

Thanks for getting to this review. I opted to handle the case of a null activity argument by instantiating the LruCache without a retained fragment in this case. Getting an activity for that test case would require adding a dependency, test rule, and test activity, which was easier to avoid by just handling the null.