Using the Same Source Code for Online and Desktop Apps
In this post, we take a look at how one dev team used the code from a web app to create a desktop app.
Join the DZone community and get the full member experience.Join For Free
In this article, we will tell you how it is done and how abandoning native apps might actually help a project.
Desktop Version Differences
ONLYOFFICE started with online editors which were conceived as an open-source Microsoft Office alternative that:
- is based on OOXML formats (docx, xlsx, pptx), unlike LibreOffice that has ODF as native formats.
- works online and allows real-time collaboration, like Google Docs.
- can be deployed on own server or integrated with another app, unlike Google Docs.
But it turned out many of the users still craved a desktop app, because:
- desktop apps are more familiar.
- they work faster (can use the system resources, not only browser ones).
- it is possible to use local fonts.
- language is determined automatically (in online versions you need to set up the doc and paragraph language manually).
- it is more convenient work to with clipboard.
- printing is effortless (no need to save a doc as a PDF first).
At that moment, our resources were limited, so we had to weigh our decisions carefully.
The Option We Declined: Native Apps
If we had chosen to create a native app, we would have to rewrite all the code we had as well as reconsider visualization. Apart from that, in the future, we would have to test and update web and desktop editors that actually do the same things separately.
What We Chose
So, we decided to use the same old JS code from the online version to facilitate both development and updating.
- Same code for communication between JS and C++. This meant that we needed a cross-platform browser engine. Since we were familiar with V8 (which we use for building file versions), we were going to use some type of Chromium.
- Cross-platform GUI. We decided to use the QT framework to achieve that.
- Being able to switch to a native rendering scheme in the future. We are not going to change the editors’ JS code, but we may change the rendering mechanism to speed the app up.
As we postponed implementing native rendering, we needed a cross-platform WebView. We have several ideas.
Out of the box solutions which we might have used given that we chose QT, namely QWebView or QWebEngineView. However, QWebView was abandoned by its developers. It is also slow and uses the same process as the app does. This was critical for us because ONLYOFFICE editors have tabbed interface which definitely means working with several documents in the same instance at the same time. So, if a problem occurred in one tab and in one document, it would affect other documents in other tabs. QWebEngineView is based on Chromium and is actively developed. It is faster and works in a separate process. But it can’t work properly with native code in the JS code process. The communication there is organized by means of web sockets which we found inconvenient. Also, rendering on 4K monitors was slow.
Pure Chromium. Pros — speed and complete functionality. Microsoft’s Visual Studio Code, which is based on Chromium, made us give it some serious thought.
Chromium Embedded Framework. It is regularly updated (cefbuilds.com), easier than pure Chromium, but lacks some of the functionality.
We rejected standard approaches (first and second variants) and went with Chromium Embedded Framework. So, eventually, we implemented CefWebView tailored to our needs.
The App Scheme
The resulting application works as follows:
While creating a V8 context we embed own object, thus accessing the native JS code. If we need to transfer data to another process, we use a built-in CEF messaging mechanism for interactions between processes. Likewise, we send messages from the other processes to the JS one.
XCode for Mac OS
Not everything went as planned. For example, the app for MacOS was created using XCode, not QT.
We use QTabWidget for tabs with editors, and it’s rather slow with MacOS. This is all just about dragging and dropping the editors’ tabs, which doesn’t look like a serious problem. But to make it work correctly it was necessary to implement this control from scratch. And it was convenient to use XCode for targeting MacOS.
So, we do have some native code for this OS.
So, you know the secret now. Our desktop app is some sort of browser that works with documents only. It puts some restrictions, of course, but, in the end, it was totally worth it because:
- we brought desktop editing capabilities to our users.
- the app can actually be used as an alternative to MS Office/LibreOffice or as a client for the online version (which means you can access docs stored in the cloud and collaborate on them right from the app).
- it works on all platforms (as it is a browser, actually, it is capable of running on anything that supports HTML).
- the development and update processes actually save us time and effort as they are made for the same source code.
Opinions expressed by DZone contributors are their own.