Yet another To-Do Application
Multido is a multiplatform app with the same codebase to Mobile, Desktop and Web.
My main goal was to make an attempt to create a real application that can be used daily without having to write separate code to every platform. I have been experimenting with React Native for quite a while now and I decided to try to achieve this goal this way.
My other goal was to eliminate the need of using sticky paper notes to schedule my daily tasks. Of course I have lots of options on mobile or web, but personally I couldn’t use these apps the way I wanted to use them. For example, I don’t like to tap my smartphone when I work at my desk. On the other hand, when I sit at my computer I appreciate the option to use a desktop app for work or task handling. In addition, I use daily task lists even for a few days in advance. Of course this should be accessible from everywhere and constantly synchronized.
The first steps
I started out with the goal to build an application for mobile and desktop. The React Native and Electron frameworks seemed to be the most efficient solution. I decided to try to connect these two systems. React Native is an excellent crossmobile library to develop iOS and Android apps, whereas Electron is a very effective framework for making desktop apps via web technology for macOS, Windows and Linux. Of course we could also use React in that framework. React Js and React Native provide us with an opportunity to use similar source code to work, but we need a library to translate React Native renders to html elements. The solution was the react-native-web module.
During experiments, the most convenient starting point was to initialize a React Native application then insert the Electron framework into it. After that I could handle the system from a common code with webpack and react-native-web. It was already apparent that this idea wouldn’t be good for a big project, but it might just be good for a to-do.
So now that the basis of the system was set, I started to design the UI. It always improves my motivation. Especially since I discovered Figma, which is a cool cross-platform design tool that I could use perfectly on macOS and Windows. Moreover, I was immediately able to test mobile layouts on devices with Figma Mirror. This is a fantastic, constantly evolving design tool, which I can only recommend.
This part of the story deserves another article so I’m just going to be brief now. I knew when I started that I would have to handle certain components and functions separately on mobile and desktop. On the one hand, not every given module can be carried from one framework to the other. On the other hand, user behaviors and device usages are also different.
For instance the swipe gesture is an established practice on mobile devices, while we could use right click context menus on the desktop. During the development I tried and used many approaches to distinctions. In some places it was enough to differentiate according to platform, but of course in other places some components had to be handled in a completely different way.
Obviously in the development process I had to rethink some parts of the software. It turned out if I display too many svgs, Android won’t like it. I had to change svg usage to icon font usage, which made me redesign some icons, but it was worth it and the performance improved.
Sortable lists were another challenge, because additional features were required. I made list rows swipeable and made changes show nice animations. Unfortunately, Android also posed a bigger challenge because the Layout Animation usually left out elements when sorting. On the desktop I solved that list items could be droppable to another list or over the date-picker.
Naturally, the redux experience is not negligible either. Proper usage is essential for good performance. If we don’t handle the updates of components effectively we will experience serious slowdown when we use 10K-row data sets.
I assumed that if the application runs in chromium then it would probably run in Chrome. So I made a little detour to try this in a web environment. To my surprise, most browsers handled the task better than I expected. I had to apply only minor changes regarding appearance to make the web-app run on current browsers. Of course, nothing was perfect here either, for instance you couldn’t use a drag-and-drop on Edge and IE.
During the development I got lots of new ideas, and I had to use temporary solutions, but I had to set a limit somewhere to make a 1.0 version. Naturally, this is an early test version and I certainly made mistakes there.
Anyway, I’m happy because these frameworks and libraries are a major step forward to building multiplatform applications in the near future.
Multido is just one experiment, one approach of many to develop applications for main platforms with the same codebase.
Details of development: https://medium.com/@attilaberki/multido-details-of-development-c5ff644e3bb1