Battle Buddies is an application designed to send reminders to a user to check in. Clicking on the reminder will either send a check in message with their current location or allow a user to send a check in message with or without gps based on the type of check in they choose.
Battle Buddies is a flutter application that aimed to provide a user with a way to easily send check in messages and location updates via sms without the need for external accounts. The application was developed with an intent to provide the user a way to expose their location only when they want to without any complicated set up. The project was created in Flutter in order to explore how the framework handles background execution. In the modern software world developers are faced with many different frameworks and libraries that attempt to provide the programmer a simple way to accomplish complex tasks. While these newer frameworks have wide use cases in the modern web based world, the importance of learning and implementing native platform code on both Android and iOS should not be minimized.
Flutter development, in its simplest form, is based around the Dart language, widgets, and plugins. By taking advantage of the many pre-built Material UI widgets, darts simple syntax, and elegant state management, Flutter is an ideal tool to create a CRUD based mobile web applications that can interface easily with other tools such as Firebase. When faced with executing background processes and interfacing directly with the Android system, the simplicity of Flutters framework quickly loses its ease of use for an inexperienced mobile developer.
Flutter background tasks make use of Dart Isolates, these isolates run on a separate thread of execution from the main application. The isolate can then be configured to communicate with the primary application using channels to send messages and data between the isolate and main application, but only if the main application is up and running. If a developer has any experience with web workers they will likely find the implementation, use case, and execution very similar to Dart Isolates. The Flutter API points a developer interested in creating background processes to a Medium article about creating a geofencing application using dart isolates. While this article is thorough and can be a good introduction to the ends and outs of creating a geofencing application, the focus on background tasks is severely lacking and hidden behind geofencing specific terminology. Attempting to decode the background processes portion from this article has led many developers to leave comments and do projects of their own to attempt to decipher what has been lost in a clutter of geofencing specific execution. One user whom took it upon themselves to create a more clear and simple implementation commented that "[he] read this article 10 times and 26 hours later (literally) [he] finally wrapped [his] head around this concept..." and provided a very helpful github link with his example. Creating this application led to a very similar frustration when attempting to implement the logic to send location updates via sms in a background isolate.
Currently Flutter does not offer an elegant or simple way of implementing complicated background tasks that maintain the context of the application or have access to its other plugins. The developer must choose between creating an application that is constrained by previously created plugins or writing native implementations in order to solve complicated background tasks. Battle Buddies ultimately decided to take the approach of staying within the constraints of the current Flutter plugins in order to ensure timely delivery of a functional product. Had Battle Buddies gone the other direction and made use of a custom plugin implementation, it would have needed to take advantage of platform specific libraries. One approach would have been to develop a custom wrapper around Android Alarm Manager and Android SMS. This custom plugin could then make use of intents and life cycle methods, both of which are missing from Flutters standard library, to keep track of the applications state when not running. Even pivoting and changing requirements to make use of pre-built plugins led to some minor difficulties when utilizing the Flutter framework.
Flutter is very new. Many of the plugins, while being created recently, have already been deprecated or are no longer maintained. Many implementations such as android_alarm_manger plugin lack the full range of capabilities their native versions contain. These plugins may also have new constraints when executing background tasks such as only being available in a top level function or lacking the ability to maintain the necessary state and configuration needed by other plugins such as sms. These constraints highlight the importance for a mobile software developer to have a fundamental basis in platform specific code such as Java for Android and Objective C for iOS. While Flutter truly does simplify mobile application development, when a developer is faced with a situation where they need to implement a very specific use case, if the developer lacks the knowledge of native programming, they may struggle to find and implement a native solution. Creating a custom plugin that maintains cross platform functionality can be extremely time consuming and may slow down the release of a final project or require a relaxation in the original product requirements. This makes it very important to assess all requirements prior to developing. The developer should explore in depth the tools they wish to use in order to ensure they are making well informed decisions.
As a software developer there is a certain temptation to jump into frameworks and libraries that abstract away the underlying functionality. In the pursuit of simple cross platform mobile development this choice can carry even more consequences. If the developer does not have a fundamental understanding of the native platforms, they limit their capabilities to the implementations and use cases that others have created. In these cases the developer could end up wasting more time than if they had built two separate native implementations.