HERE Android SDK Developer's Guide

Development Tips

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:

  1. Ensure the HERE-sdk.jar file is removed from your project and the compile entry is removed from your build.gradle file. The JAR may be located at app/libs/HERE-sdk.jar and included in your build.gradle file one of the following:
    compile files('libs/HERE-sdk.jar')
    compile fileTree(dir: 'libs', include: ['*.jar'])
    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.
  2. Remove the HERE SDK proguard file and the proguard entry specific to the HERE SDK from the build.gradle file. The file to remove is named proguard-here-sdk.txt, and the entry of the same name should also be removed from the proguardFiles property in your build.gradle file. 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 HERE-sdk/tutorial/BasicMapSolution/app/build.gradle file.

Lapsed Listeners and Garbage Collection

The HERE SDK provides a number of listener interfaces, such as Map.OnSchemeChangedListener, Map.OnTransformListener, and 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 setGeoPolyline(GeoPolyline) instead.

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".

Native Libraries and ABI Splits

Your app may encounter an error if it also includes other dependencies that have unsupported ABIs. To get around this issue, enable ABI splits to only build for the armeabi-v7a architecture explicitly by modifying your app's build.gradle file:

android {
  (...)
  splits {
    abi {
      enable true
      reset()
      include 'armeabi-v7a'
      universalApk false
    }
  }
  (...)
}

For more information about the splits Gradle block, see Configure multiple APKs for ABIs in the Android Studio User Guide.