Skip to content

Extract native Markdown codec from AndroidDocumentsPlugin#91

Merged
Renakoni merged 1 commit into
mainfrom
refactor/native-markdown-codec
Jul 10, 2026
Merged

Extract native Markdown codec from AndroidDocumentsPlugin#91
Renakoni merged 1 commit into
mainfrom
refactor/native-markdown-codec

Conversation

@Renakoni

Copy link
Copy Markdown
Owner

Summary

Sixth PR of the semantic-decomposition series, first on the native side: moves the pure-JVM Markdown byte handling out of AndroidDocumentsPlugin.java into a focused MarkdownCodec helper. Behavior-preserving — error codes, messages, and byte-level output are unchanged.

Boundary

MarkdownCodec (package-private, static, zero Android dependencies) owns:

  • encoding-name normalization (the full 36-name table with the utf8 fallback),
  • charset lookup with the DOCUMENT_ENCODING_UNSUPPORTED mapping,
  • BOM detection (UTF-32 sniffed before its UTF-16 prefix — now documented in place) and BOM emission for the five Unicode encodings,
  • strict encode/decode with CodingErrorAction.REPORT and the DOCUMENT_ENCODING_FAILED mapping,
  • the 5 MB byte validation (DOCUMENT_TOO_LARGE), exposed constant included since the plugin's streaming read enforces the same limit.

The supporting value types — DocumentReadException, MarkdownWriteOptions, DecodedMarkdown — are promoted from private inner classes to package-visible top-level classes, chosen deliberately so every existing plugin reference, method signature, and catch clause compiles unchanged.

The plugin keeps everything the TODO says it must: Capacitor call handling, URI parsing, ContentResolver stream I/O (readText/writeText stay put and feed bytes through the codec), Activity lifecycle, and the mutable default-encoding/auto-detect settings — which remain plugin state passed into decode per call, so configureMarkdownSettings semantics are identical.

Testing

  • New MarkdownCodecTest (8 JUnit tests, pure JVM, no emulator needed): UTF-8 round trip with CJK content, BOM write + detect, the UTF-32LE-vs-UTF-16LE sniff priority, the auto-detect-off rule that still honors a BOM matching the default encoding, the 5 MB rejection code, name normalization (unknown/null/untrimmed), and both DOCUMENT_ENCODING_FAILED paths (unmappable char on encode, malformed bytes on decode). All 8 pass via gradlew testDebugUnitTest.
  • CI: the Android debug workflow now runs testDebugUnitTest before assembling, so native unit tests gate merges from this PR onward.
  • compileDebugJavaWithJavac and assembleDebug green locally; the web bundle is untouched (Java-only diff), and the TS-side encoding contract is unchanged (encoding/hasEncodingBom payload fields, error-code strings).

Moves the pure-JVM Markdown byte handling into a focused MarkdownCodec
helper: encoding-name normalization, charset lookup, BOM detection and
emission (UTF-32 sniffed before its UTF-16 prefix), strict encode/decode
with the REPORT coding actions, and the 5 MB byte validation. The
supporting value types (DocumentReadException, MarkdownWriteOptions,
DecodedMarkdown) become package-visible top-level classes so every
existing plugin reference and catch clause compiles unchanged.

The plugin keeps all Capacitor, URI, ContentResolver, and Activity
lifecycle responsibilities: readText/writeText stream I/O stays put and
now feeds bytes through the codec, and the mutable default-encoding /
auto-detect settings remain plugin state passed into decode per call.
Error codes, messages, and byte-level behavior are unchanged.

Adds MarkdownCodecTest (8 JUnit tests, pure JVM) covering round trips,
BOM writing/detection incl. the UTF-32/UTF-16 prefix priority, the
auto-detect-off default-match rule, the size limit, name normalization,
and both encode/decode failure codes, and wires
gradlew testDebugUnitTest into the Android debug workflow so native
tests gate CI from now on.
@Renakoni Renakoni merged commit 700a718 into main Jul 10, 2026
5 checks passed
@Renakoni Renakoni deleted the refactor/native-markdown-codec branch July 10, 2026 13:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant