AI Programming Makes Developing an E-book App for HarmonyOS Faster

Although multimedia files like images, audio, and video come in many formats, developing apps for them isn't hard, because the common multimedia formats are supported at the system level. Developers just use native components to load them—for example, HarmonyOS uses the Image component for images, the Video component for videos, and the MediaPlayer component for audio.

Documents are different. Document formats are numerous and complex, some even closed-source, which gives e-book app developers headaches. Even though HarmonyOS natively supports many document formats like PDF, TXT, EPUB, MOBI, and AZW3, there are still formats it doesn't support, such as DjVu, RTF, DOCX, and others.

Although formats like DjVu, RTF, and DOCX already have mature implementations on other platforms, the related code is messy and tangled, mixing C, Java, JavaScript, and other languages. With the old approach, a developer would need to master multiple programming languages and even multiple platform development technologies just to migrate an e-book parsing codebase from another platform to HarmonyOS step by step.

Worse still, converting code language is only the first step of the migration. After conversion, the new app project still has to compile successfully and pass debugging across various documents before a HarmonyOS app supporting the new format can ship. The whole workflow demands a huge time investment and burns a lot of brainpower—it's not profitable, it's a labor of love.

But now, with AI programming, this kind of heavy engineering code migration can be handed to AI. What follows is how I used AI programming to quickly make a HarmonyOS app support RTF documents.

1. Find an open-source library on another platform that supports RTF

Why choose RTF? Because RTF is a cross-platform document format based on ASCII plain text, letting formatted documents be exchanged between different systems and software. Unlike DOCX, it's simpler, yet it still supports basic formatting like fonts, colors, styles, and images. Most word processors can read and save it, and many software license documents use RTF.

At first I had no idea how to parse RTF documents, nor which open-source RTF parsing frameworks existed. So I asked Doubao, "What open-source frameworks can Android apps use to open RTF e-books?" Doubao listed four open-source projects: OpenReadEra, CoolReader, KOReader, and LibreraReader, as shown below:

Looking closer at those four e-book open-source projects, I saw that the first three all use C++, while the last one is pure Java. So I decided to start with LibreraReader.

According to LibreraReader's description, it supports PDF, EPUB, EPUB3, MOBI, DjVu, FB2, TXT, RTF, AZW, AZW3, HTML, CBZ, CBR, DOC, DOCX, and so on. My requirement was only to parse RTF, so I asked Doubao again, "In the open-source Librera Reader app project, which module handles RTF?" Doubao answered: "The Java-level RtfParserKit (levigo/rtfparserkit) third-party library, plus your own wrapped RtfExtract / RtfExtract2 adapters," as shown below:

Doubao also pointed out that LibreraReader's RTF parsing is not native C++ rendering, unlike OpenReadEra, EraEPUB, and CoolReader. So using LibreraReader + RtfParserKit to parse RTF has these advantages:

1. Pure Java, no NDK compilation needed, lower integration cost.
2. rtfparserkit uses a permissive license (BSD), more friendly than GPL.
3. After converting to HTML, you can reuse any HTML/EPUB rendering engine for e-book pagination.

So I settled on the LibreraReader + RtfParserKit combo to parse RTF. Both open-source projects are on GitHub, and I downloaded their source code.

2. Strip the RTF parsing code out of LibreraReader

I first tried to manually strip the RTF portion from the LibreraReader source, but it proved messy and time-consuming—hours went by without success. I thought of having AI do the stripping, though Doubao had already reached its limit. So I opened Trae and asked it to try. Here's the prompt I gave Trae:

You are an Android app development expert. There is a copy of the LibreraReader source code for an e-book reading app (source path "xxx"). Please extract the RTF parsing and reading code from LibreraReader and output a new app project. Requirements:

1. I've already created a new app project called rtftest at "xxx"; the gradle, jdk, and sdk versions in that path use the existing project configuration.
2. The entry point for RTF parsing in LibreraReader is at "app\src\main\java\com\foobnix\ext\RtfExtract.java"; start from that file and extract the other code related to RTF handling.
3. I already have the source for the rtfparserkit library used by the RTF parser, and I've placed it under "app\src\main\java\com\rtfparserkit" in the rtftest project, so you don't need to import it in the new project's build.gradle.
4. Replace all "import com.foobnix.pdf.info.R;" with "import com.example.rtftest2.R;".
5. If the new project needs any greendao code, replace calls to the greendao library with the official Google Room library.
6. If the rtftest project needs to be built with Android Studio, note that the local Android Studio installation directory is "xxx".

Then Trae worked for half an hour and successfully stripped out the RTF code, compiled it, and generated a debug APK. Here are the results of Trae's stripping work:

Then I opened the Android project Trae had built and quickly tested it. Plain-text RTF files parsed fine, but a rich-text RTF file with images failed to display images. So I asked Trae, "I changed a few code bits and on a real device the text part of the RTF file displays, but the images in kuaipan.rtf don't show. The 3 extracted PNG images are only 16B each. Please look at why the image content isn't being extracted correctly."

Trae then worked for 15 minutes and successfully located the problem preventing RTF images from showing, and directly modified the source to fix the bug. Below is Trae's bug-fix result:

I recompiled the app project Trae had modified and tested again; this time the rich-text RTF file displayed its images correctly.

3. Convert the Android project that supports RTF into a HarmonyOS app

I was surprised at how quickly AI programming had transformed the RTF-parsing app, and I gained confidence, deciding to push through and have AI handle the corresponding HarmonyOS app as well. Again I asked Trae:

You are a HarmonyOS app development expert. rtftest is an Android app project. Please rewrite this Android app project as a HarmonyOS app. Requirements:

1. Convert the Java code and XML files in the Android project to HarmonyOS ets code.
2. Save the converted HarmonyOS app project at "xxx".
3. The app must be compatible with HarmonyOS 6.
4. Name the project RtfApp.
5. If the HarmonyOS app needs to be built with DevEco Studio, note the local DevEco Studio installation directory is "xxx".

Of course, converting to a HarmonyOS app is different from stripping an Android app. Stripping happened between two Android app projects—only extracting a part of the code from one complete Android project to another. The conversion lies between an Android app project and a HarmonyOS app project; the whole implementation logic has to be rewritten from Java to ArkTS. So even with AI programming, it took nearly an hour to convert the RTF-parsing Android app project to a HarmonyOS app project. Below is Trae's conversion result:

Because a HarmonyOS app's debug package also requires manual signing by the developer, AI only produced an unsigned bare package.

Then I opened the HarmonyOS project Trae had built and quickly tested. Two problems appeared: odd strings mixing letters and digits showed up, and a rich-text RTF did not display its embedded images. I asked Trae again:

When testing RtfApp on a real HarmonyOS device, two problems came up. Please analyze the exact causes and fix them:

1. For tiaozhuan.rtf, besides normal Chinese text, many odd strings mixing letters and digits appear.
2. For kuaipan.rtf, only the text content is parsed; the 3 embedded images are not shown.

Trae spent half an hour analyzing and fixed both issues, finding a single root cause: readCommand() mishandled the delimiter for control words (off by one compared to the Java original RawRtfParser). The analysis process is shown below:

Just looking at that analysis, it's expert-level. If a human had to track it down, it would probably take a big part of the day.

I then tested other RTF files and found the parsed text only had one font: no bold, no black (heavy) style, no hyperlinks. So I asked Trae, "On a real HarmonyOS device I tested with QQLicense.rtf. The parsed content uses only one font, can't show bold or heavy style, and hyperlinks in the HTML become plain text without link behavior. Please fix these two issues."

Trae analyzed for 15 minutes and found these were bugs already present in the Android version; the HarmonyOS version simply carried them over unchanged. AI then found a solution and fixed the code. The fix process is shown below:

I recompiled the repaired HarmonyOS project and on a real device the RTF document now renders its rich styling completely. For example, the plain-text RTF parsing result below shows both bold text and hyperlinks:

And the rich-text RTF parsing result below shows different fonts and the associated images correctly:

The above is the full process of using AI programming to enable RTF parsing in a HarmonyOS app. Apart from the initial research into technical direction and the final document debugging, the middle parts—code extraction, code conversion, and bug fixing—were all done by AI. This makes it much easier for a HarmonyOS app to adapt features from other platforms.