BeeWare mobile application development lessons learnt

Lessons Learnt: BeeWare is a mobile application development framework with a strong emphasis on the “write once, run everywhere” mode of writing applications. It leverages python language for writing applications and cross compiles application logic to the targeted platform such as android and iOS devices. The framework supports Pythonnet for enabling the applications written to be run and tested on Windows desktop without targeting any platform. This enables independent testing of applications. It supports Briefcase which is a tool for converting Python projects into a standalone native application. Briefcase allows scaffolding boilerplate code for application bootstrap as well as building, running, and packaging the application into native formats for targeted platforms. The framework supports Toga for user interface development and comes with the ability to compose a user interface with cross-platform widgets. These widgets allow basic functionality for the user interface so that forms can be written and user input can be collected and validated. The framework supports Rubicon which allows the written application to be built for android and iOS respectively and there is a version of Rubicon each for those platforms.  This article goes through some of the idiosyncrasies involved with the use of this framework in detail and the lessons learnt.

Details: BeeWare offers convenience in writing applications with Python which is also machine-learning friendly given the well-known libraries supported by this protocol. These applications are written with dependencies on several modules which are imported into the application logic. When the BeeWare build command is written, the dependencies are also imported into the build application if they are specified as required for the application in the project file at the base directory of the project. Even machine learning libraries can be imported, build, and included in the package of the applications. However, the python modules must conform to well-known formats of dependency publication such that BeeWare can include them. Proprietary and customized modules might not be included by default. When the BeeWare includes the modules, both the compiled forms of Python code as well as the built binary of the targeted platform will be available under the project file layout. When the application is run on the desktop, these dependencies are loaded from the project file layout. It is also possible that the dependencies might be found outside the application file layout and it will still be found. When the application is run on an emulator with debug output visible, the console will indicate with exception stack if a module is missing. The emulator provides a kind of sandbox so the dependencies from outside the application package cannot be loaded. These are some of the ways in which this issue is detected and resolved.

One of the considerations in cross-compiling application logic is that the dependencies are not only for the application but also for the framework as well as those for the targeted platform. These layers of dependencies require versions and version compatibility can quickly get out of hand even for modules that appear within the project layout after build. A common resolution to this dependency mismatch is to roll back the Python version to older ones or in some cases apply overrides. When the applications are developed on Windows, there is an additional dependency on Visual Studio compiler binaries and the Windows .NET runtime framework. Unfortunately, there is no panacea for the dependency conflict resolutions, and it must be tackled on a case-by-case basis. A significant fraction of the application development time goes into this. One of the common errors encountered is "Error while dexing".

Another important consideration is that the machine learning models take input data and make predictions. They are computation heavy, and a model must be trained with a lot of data before it can be made to predict with high precision and recall. This calls for the models to be developed on the desktop or in high resource available devices. The model can be created and trained elsewhere and then they can be packaged and run with the mobile application and the emulator. This makes it easy to write machine learning applications with BeeWare. The flip side is that the development of user interface heavy applications is somewhat limited. The Toga library provides a basic set of widgets and containers which makes it hard for custom widgets or imported widgets to be used. Even the set of widgets provided are not all universally usable. Some of them may not be used on Android applications, while others may be used with iOS devices. The documentation of each widget also includes callouts for these but a missing widget availability on a targeted platform does not have a workaround without significant investments. The bright side of the application development on BeeWare is that the machine learning application development requires only a form with minimal widgets to capture manual entry of data with which the predictions are made. In such cases, the library is sufficient.

Conclusion: Among the lessons learnt, the callouts are for budgeting time into the setting up of the framework as well as the investigations into the deployment and smooth running of the application. The ability to write application logic with minimal code appears unmatched with this framework.