This section provides tips on building your application using the HERE Android SDK.
Upgrading from Older Versions of HERE SDK
The HERE Android SDK is now packaged as an Android archive (AAR) file instead of separate JAR, native library and proguard components. If you are upgrading from an older HERE SDK release, the old components should be cleaned up before integrating the AAR version of the HERE SDK. To do so, follow these steps:
- Ensure the
HERE-sdk.jarfile is removed from your project and the compile entry is removed from your
build.gradlefile. The JAR may be located at
app/libs/HERE-sdk.jarand included in your
build.gradlefile one of the following:
Note that if you were previously using the Google GSON library or the JTS Topology Suite library with the HERE SDK, it is still required to be included separately.
compile fileTree(dir: 'libs', include: ['*.jar'])
- Remove the HERE SDK proguard file and the proguard entry specific to the HERE SDK from the
build.gradlefile. The file to remove is named
proguard-here-sdk.txt, and the entry of the same name should also be removed from the
proguardFilesproperty in your
build.gradlefile. The proguard instructions for newer versions of the HERE SDK are now applied automatically and are included in the AAR.
You can find further info on integrating the AAR version of the HERE SDK into your app in the Running the Sample Application section of the User Guide and the associated
Lapsed Listeners and Garbage Collection
The HERE SDK provides a number of listener interfaces, such as
MapGesture.OnGestureListener. To use these listeners, you are required to implement and create a listener instance, then register it with another object (using a method such as
addSchemeChangedListener()) to receive event notifications. Unfortunately, this coding pattern can also lead to the lapsed listener problem, where available memory is consumed by listener objects that are not explicitly unregistered and not garbage collected.
To mitigate this problem, the HERE SDK, in some cases, accepts listener objects in
WeakReference containers. This has the advantage of avoiding lapsed listeners, but it also means that you must be aware of registered listeners becoming garbage collected. To avoid any unintended issues with this coding pattern, be sure to retain a strong reference to your listener instances (for example, by assigning it to a class variable) if you would like to manage its garbage collection lifecycle. Listener objects are not garbage collected as long as a strong reference exists.
Working with Getters
Classes in the HERE SDK return copies of objects in its getters. For example,
MapPolyline.getPolyline() does not return the same
GeoPolyline instance that was used to construct the
MapPolyline object; instead, a copy of the
GeoPolyline is returned. Since this returned object is a copy, you cannot dynamically modify the
MapPolyline instance by modifying this object. If you would like to make changes to
MapPolyline, you must call
Map Object Limitations
The HERE SDK does not limit the number of map markers, polygons, and polylines that can be added to a map. However, rendering a large number of map objects can cause performance degradation in your application. It is recommended that you use techniques such as viewport clipping to avoid these issues.
Doze and App Standby
If you are using Android 6.0 (API level 23) or above, be aware that the Doze and App Standby features may impact your HERE SDK app by disabling network access when the device is unplugged, stationary, and has the screen off for a period of time. While the HERE Android SDK has the ability to work offline, you should design your app with these operating system features in mind.
For more information about Doze and App Standby, including how to use notifications and whitelisting to ensure your app functions properly, see the Android article, "Optimizing for Doze and App Standby".