AAChartCore-Kotlin: a Highcharts model behind an Android web view

AAInfographics renders a chart document, it does not draw with the Android canvas

AAInfographics is the Kotlin member of a chart library family built on Highcharts, the front-end charting engine. The repository description calls it a declarative data visualization framework for Android, and the top-level file listing shows a `charts/` module next to a `sample/` application. Two type names carry the whole design. `AAChartView` is the Android widget you place in a layout, and `AAChartModel` is a Kotlin object that holds the chart definition. The project puts the combination in one line: `AAChartView + AAChartModel = Chart`.

The mechanism matters more than the type list. The repository topics include `webview`, and the project is described as based on the Highcharts front-end library, so the model is turned into a chart document that is rendered inside a web view rather than drawn with the Android graphics stack. What you gain is the whole Highcharts catalogue on Android, including the single touch-drag data inspection and multi-touch zooming the preface promises. What you take on is a web view and a JavaScript engine inside the app process, a different kind of dependency from a plain native view.

The chart is one long chain of Kotlin setter calls

The configuration style is a builder written as a chain of setters, which the feature list describes as chain programming syntax like system framework. Each call returns the model, so a chart is described in a single top-to-bottom expression.

val aaChartModel : AAChartModel = AAChartModel()
    .chartType(AAChartType.Area)
    .title("title")
    .subtitle("subtitle")
    .backgroundColor("#4b2b7f")
    .dataLabelsEnabled(true)

Data points arrive through `AASeriesElement`, where each element carries a name and an array of numbers, and the elements are collected by a `series` call on the model:

AASeriesElement()
    .name("Tokyo")
    .data(arrayOf(7.0, 6.9, 9.5, 14.5, 18.2, 21.5, 25.2, 26.5, 23.3, 18.3, 13.9, 9.6)),

The model is plain Kotlin state with no separate JSON or XML chart file to keep in sync, and nothing is parsed at render time, which is the practical appeal for an app that already holds its numbers in memory.

Installing from JitPack, with a version token that is not a version

Installation runs through JitPack rather than a Maven Central artifact. The first step adds the JitPack repository to the root build file:

maven { url 'https://www.jitpack.io' }

The second step adds the dependency, and the coordinate deserves a careful read:

dependencies {
    implementation 'com.github.AAChartModel:AAChartCore-Kotlin:-SNAPSHOT'
}

The version token printed there is `-SNAPSHOT`, so a build that copies it literally resolves a snapshot rather than the 8.2.1 release. If you need a pinned artifact, put the release version in that position yourself and confirm what Gradle resolved before you trust the result. JitPack also means the build asks a third-party service to compile the library from source, so CI needs network access to jitpack.io.

The view lives in XML under a package name that does not match the artifact

The first real use starts with the widget. The chart view has a fully qualified class name, so it has to be written out in full in the layout:

    <com.github.aachartmodel.aainfographics.aachartcreator.AAChartView
        android:id="@+id/aa_chart_view"
        android:layout_width="match_parent"
        android:layout_height="match_parent">

    </com.github.aachartmodel.aainfographics.aachartcreator.AAChartView>

The activity then looks it up by id:

val aaChartView = findViewById<AAChartView>(R.id.aa_chart_view)

The package path is `com.github.aachartmodel.aainfographics.aachartcreator` even though the artifact is published as AAChartCore-Kotlin, so imports do not follow the artifact name. The layout gives the chart the full width and height of its parent, and there is no separate container or legend view to wire up, since the legend, title, subtitle and data labels are all part of the model built earlier.

Hand-drawn views versus rendering a document: the real difference

The realistic alternative is not another library but another approach: drawing the chart yourself in a custom Android View, or using a native chart widget. The difference in approach shows up in what each hands back to the rest of your app. A hand-drawn view gives you a real object in the view hierarchy that the layout system measures, that you can layer with sibling views, animate, and expose to accessibility services, and it needs no JavaScript engine in the process. The AAInfographics route gives you a rendered chart document, and everything the chart offers comes from the Highcharts engine running inside it. That is why the catalogue runs to polar, funnel, columnrange, angular gauges and error bars without the library implementing each of them.

The trade is worth taking when a chart is a small part of a screen and interactivity matters. It is worth refusing when the chart has to sit underneath other native views in the same layout, when process memory is tight, or when a web view is ruled out for policy reasons.

The usage guide stops before the render call and release rules are undocumented

Two limitations deserve pricing in before you commit. The first is the release build. The sample module ships a `proguard-rules.pro` file, and the README says nothing about what a production build has to keep, so shrinking a release build is something you verify yourself rather than copy from a documented recipe.

The type catalogue is also unevenly described. The feature list enumerates a dozen common types, while the repository description adds error bars, box plot, waterfall and angular gauges. Treat the shorter list as the confirmed set.

The licence badge and the licence identifier disagree

The project is recorded under the Apache-2.0 licence, and a LICENSE file appears in the top-level file listing. The README badge, though, renders the text MIT beside a link to that same LICENSE file. The two identifiers carry different obligations, especially around patent grants and how notices travel with the code, so which one governs is not something to infer from a badge.

Read the LICENSE file in the repository and see which text is actually attached. If the terms require a notice to be reproduced, keep that notice alongside your app's own licensing files. Apache-2.0 also asks you to preserve notices of modification, which matters if you fork the `charts/` module instead of consuming it as a dependency. This is a question for whoever reviews licensing where you work, not something to settle from a screenshot.

Version eight releases, and the last push was on 2026-05-28

The repository is not archived. The last push was on 2026-05-28, and the two most recent releases are 8.2.1 on 2026-02-11 and 8.1.0 on 2025-10-28. A tagged release follows the newest commit, so the project is still moving, at a pace of roughly one release every few months rather than frequent patches.

The version numbers sit in the eight range, so an app already on an earlier major has a path forward, but the top-level file listing holds no changelog file, and the README does not describe a deprecation or migration policy between majors. When you move a major version, expect to re-check the model builder calls yourself.

Editorial conclusion

AAInfographics suits teams that want an interactive, animated chart in an Android app quickly and can accept a web view in the process, and it suits less well if you need native view semantics, tight memory budgets, or a build pinned to a published artifact. Before adopting it, read the LICENSE file to settle whether Apache-2.0 or MIT governs, pin the dependency to 8.2.1 instead of the printed snapshot coordinate, and confirm in the source how the final render call is triggered, since the documented usage list ends before that step.

Frequently asked questions

Official sources

1. AAChartModel/AAChartCore-Kotlin on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases