Estimated read time: 3 minutes
As it has been announced last week, an Android port of LibreOffice in the form of a viewer app is now available for download. What’s next? Editing, naturally. First, thanks again to The Document Foundation — and all the donors who made this (ongoing) work possible. In this post I would like to explain what did we do with Tomaž Vajngerl at Collabora so far in that direction.
If you ever touched the Android port of LibreOffice, you probably noticed that sadly developing for Android is much harder compared to Linux (desktop). On Linux, if you just touch a single module, it’s possible to rebuild just that module in a few seconds, and then you can run soffice again with your modifications included. On Android, this is much harder:
-
due to a limitation of the Android linker, we link all the native code into a single shared object, that has to be re-linked after each native code modification
-
the native + the Java code has to be packed into a .apk archive
-
the .apk archive has to be uploaded to the device (or emulator) and installed there
and only then can you test your changes. To partly sidestep from this problem, we split the "Android editing" into two:
-
tiled editing: this can be tested on Linux using the gtktiledviewer test application (and ideally any core problem can be seen here already)
-
Android LibreOfficeKit client: replacing gtktiledviewer with the real Android client code, and this time testing it on the device
One problem with this approach was that while Android properly rendered small tiles of 256x256 pixels, gtktiledviewer rendered a single huge tile. This means that in case part of the document changes and we need to re-draw it, we always repainted the whole document in gtktiledviewer, while we only repainted the necessary parts on Android. Guess what, if the area to be repainted is wrong, it’ll be visible on Android but not on gtktiledviewer. So the first task we solved was to let gtktiledviewer also render small tiles. For debugging purposes, small red rectangles are painted at the top left corners of each rectangle, so the size and position of the tiles can be seen easily:
The next step was to somehow start work on real editing — but where to start? We identified two critical building blocks:
-
there should be some way for the user to provide input (e.g. press a key on the software keyboard)
-
once the document changed, the application has to redraw the changed part of the view
To avoid solving two problems at the same time, we first went after the second. One use case that only requires the update of the view is blinking text. Even if no touch or key events are available, a blinking text wants to update the view using a timer, so it’s a good testcase. It’s now possible for LibreOfficeKit clients to register a notification callback, and using that, LibreOffice can notify clients if part of the view has to be redrawn. Here is how it looks using gtktiledviewer:
This demonstrates that the LibreOfficeKit implementation in LibreOffice core and also the gtktiledviewer client code handle correctly tile invalidations. Once that was done, we could also implement a similar client code in the Android app — it looks like this:
That’s it for now — next on our list is adding support for input handling, so it’s possible to type in some text. :-)