Android support

[robinst]

There's currently a fork with changes for making commonmark-java work on Android. This issue is about merging those changes back, and making sure we don't break things for Android in the future.

Initial discussion here: https://github.com/Doist/commonmark-android/commit/9ff69424f603c6b8c0ddb6419419d651c0de7380#commitcomment-15439453

[JinneeJ]

After some thinking and «experimenting" I’d like to suggest following: making required changes in core lib (#33 and #32) and creating separate Android project (not fork) which depends on core lib from maven repository. Since Android relies only on Gradle we won’t mix 2 build systems in one repository (Maven and Gradle).

Also if Android library depends on pre-compiled core library it will allow to leave «try-with-resourses» in core library and don't force you to use Gradle in core library 😅

Also commonmark-android has code not-related to Android - are you interested to have those in commonmark-java?

• Replacement extension
• CleanRenderer

[robinst]

Yeah, I think that makes sense too :).

A disadvantage of having it in a separate repo is that we might break API (we're not on 1.x yet) without also fixing the usages. If they were in the same repo and also included in the build, then that wouldn't happen. And we wouldn't be forced to use Gradle for everything, we could just have a separate subtree that included all the Android code and was built using Gradle. Of course there are advantages too :). Let's just see how we go.

Do you have any ideas how we can ensure that we don't accidentally break Android compatibility in this repo? Maybe have a tiny Android project that tries to compile with the library?

• Replacement extension: I'm curious what you're using it for? But I'm not sure we need it in commonmark-java. I think we should keep the extensions we ship to only do parsing-related stuff. Replacement can just be done on the resulting AST, as you have done. (I know I'm a little bit inconsistent here, because plain autolinking is also just a post processor.)
• CleanRenderer: As far as I can tell, it renders a plain-text version without line breaks, is that right? That seems like something useful to have out of the box :).

[JinneeJ]

There is actually one more reason for not having the whole commonmark-android in this repository:
Actually after my PRs with the required java changes commonmark-java is already could be used on Android. Android can work with HtmlRenderer but it's expensive in performance terms. That's why commonmark-android has SpannableRenderer. In general terms Spannable is like markup + appearance. So SpannableRenderer in commonmark-android has custom styles and it's not a good idea to drag them to commonmark-java.

This is what we can do. As I mentioned now Android can use HtmlRenderer and we can skip performance for assurance that you don't break Android compatibility. So I can make PR with little Android "sample" project with easy tests to be sure that Parser and renderers work without exceptions.

• Replacement extension: You're right - it's not related to Commonmark at all. For example it can be used for replacing some text shortcuts by unicode emoji.
• CleanRenderer: it does exactly what you described :)

[robinst]

What do you mean by custom styles? Are you saying other projects wouldn't be able to use commonmark-android because the styles are too specific to your use case?

I'm wondering whether it would be better if commonmark-android was renamed to something a little bit more specific, as commonmark-java now also has Android support. Not sure what a good name would be though :).

(By the way, in case this wasn't clear before, for the "let's put it as another module in this repository", I'd make you a collaborator of course.)

So I can make PR with little Android "sample" project with easy tests to be sure that Parser and renderers work without exceptions.

Cool 👍! Looking forward to that and other PRs.

[JinneeJ]

• By custom styles I meant that styles are specific to current design of our projects. It's because when you create Spannable you should specify the colors, fonts or something similar related to appearance.
• commonmark-android is defenetely will be renamed 👍I'm planning to remove commonmark-android and create new one which won't fork commonmark-java.
• Should I also send PR with CleanRenderer? If yes - should it be included in the core or in the separate module? And does the name CleanRenderer sound good? 😄

[robinst]

• Ok. In case you want others to use it, it should be externally configurable :).
• 👍 sounds good
• Yes, please create a PR. Maybe TextContentRenderer would be a better name (that's it's called in HTML). And maybe the behavior for stripping newlines could be configurable on the renderer.

[robinst]

I think we can close this one now. Thanks a lot, @JinneeJ!

When you have the new project, I can add a link to it in the README, just ping me here.

[gsantner]

sadly the project was upgraded to use java 8 as source level. (data from android dashboard) This makes the library incompatible with about 99% of current devices.

For development of our foss markdown editor app this means sadly we can't get any updates, bug or security fixes.

Is there any plan to provide backports? Or to use java 7 again?

[robinst]

@gsantner I've opened a new issue about this, let's discuss there: #124