Final Report
Prepared by: Ethan C. Joshua S. Kyler K.
The current world of applied ethics in medicine offers a wide variety of contest on how limited resources should be allocated. Whether it is by the purse of the individual, the amount of dependents, their age and demographic, their likeliness to contribute to society and overall social points, most can agree there isn't a level playing field that makes this choice come easy. That's where Project Alek comes in as a neutral, white-box solution that is random in it's selection.
Project Alek is a mobile app that aims to allow its users to randomly choose individuals from a population, given an amount of limited supply. Built in Flutter and integrated with Firebase as well as a variety of other resources, it allows each allocation run to be verifiable and provable in a reasonably assured manner. It accomplishes all the major goals that were laid out at the start of the project; lightweight, email integration, verifiable results and effectively allocates resources in a random way.
Project Alek was designed with the medical field in mind as Covid-19 has hit the world and scarce amounts of ventilators and other supplies are needed to maintain the health and livelihood of people. This does not mean that it is limited to this application. We designed this application to work under any situation where things need to be distributed in a way where there is no applicable bias. A list is generated with user-inputted names or potentially auto-generated id's. These lists are used to randomly pick an amount of data depending on how much of a resource is available and is then displayed to the user. A PDF with the report data is also automatically generated and sent to whatever email was provided at the start of the application. Firebase is implemented as well and stores a specific hashkey for a run which is displayed to the user at multiple points. This hashkey is unique and insures that a specific run of the data cannot be replicated without having an entirely different hashkey. Local history functionality displays the last runs with the list generated and this hashkey is displayed there as well.
Description
We decided to go with Flutter for this project due to the abilities it provides. Being able to program for the Android, iOS, and experimental Web platforms all at once meant that we could develop an application that could fit any need our sponsor / users would want. This is not without flaws as there are some aspects of it that take away from the personality we could have added if we developed for each separately.
One such issue is the scaling from mobile to web. The web functionality in Flutter is still a bit rough and there was likely a way to customize it to look better, but you can see from this photo that the experience is very stretched out:
Compared to the mobile version shown here:
The plugins used will be explained later, but we essentially used provider states in order to maintain all of the data we needed for this application. The history section of the application uses Shared Preferences to store a list of history models with data from the provider and is then loaded back into the application when the history page is loaded. It is an easy and efficient way to store the data that only goes away when the application is uninstalled. We did things this way because we did not want users to have the ability to delete the history of a run and then run the application again to get different results. The main development challenge of this application is that we wanted to avoid storing as much personal data as possible.
Description
Description
This was the plugin used in order to handle application states. The provider plugin allows us to create a model, a provider, and a state that all work together. A new state is created which contains all of the data for an allocation run. This included the email inserted, the list generated, the history data (loaded and saved from here to the device), and also any data that had to be pulled from Firebase and stored for usage in the history and report. This was used throughout the application to manage stored variables and to update screens so that everything was using the correct state. It is essentially an entire state management tool that works wonderfully for these types of applications.
I am currently working as a Software Engineer at a company which is focusing primarily on new Flutter applications. This meant that I had some experience coming into this project and was glad that we decided Flutter would be the best tool for this application. With this in mind, there was a large amount that I did not know and learned through this project.
Firebase was a weakness of mine, and although I was not specifically the person to implement it, I feel as though I now have a better grasp on how the overall structure of it works within Flutter. The same can be said for the PDF service MailGun. I was the one that went through and formatted the send-able PDF in a way that interfaced with the providers that were created and it was the first time I had ever done something like that.
Android deployment is next. The original plan was to release on as many platforms as possible and the app is setup to do so with the exception of a few configuration details for iOS. In the end, we were told that we only really needed to deploy on Android and that is what we did. I have never actually gone through the steps of deployment and this was an absolutely wonderful chance to learn. The application is now available on the Google Play store at the following link:
https://play.google.com/store/apps/details?id=com.projalek.allocation_app
x.xx Full name
Description
Our team has been absolutely wonderful as a whole. There were some sprints that could have gone much better and there were sprints that were absolutely amazing. I believe that everyone was able to work together in a way that benefited everyone and the communication through Discord, Slack, and other means went over very well. We were able to check pull requests and fix issues in a minimal amount of time while keeping a professional standard that we wanted to maintain.
Project Alek has been a wonderful project to work on as a whole. The entirety of the team is coming out of this with more knowledge about a popular programming language than ever before and we feel that we have made something that can be incredibly useful given time. This application was created to fill a gap between randomization and validation. There were many applications out there that provide randomized selections of data but none of them had a way to truly verify that the application was run in a fair and verifiable way. There are many improvements that could still be made but we feel that we have provided the absolute best application we could given the time available to us.
We had some sicknesses / other personal matters that drove our development ability down quite a bit. This was partially countered by the sheer amount of work we all did early but it was still a challenge towards the end of the development cycle.
Another challenge we had was the overall challenge of learning Flutter. Now that we have worked on this application for awhile there are some aspects of the application that definitely could have been done in a way that would have been even better than it already is. This includes things that were coded in an overly complicated way when it really didn't need to be. It caused some issues with widgets resizing properly / aligning with what the design was supposed to be.
This project has a lot of integrated services that require maintenance to some degree. The current area of biggest concern is that the Firebase rules need to be updated to only allow read and writes of a certain type. There are some flaws with the UI and some small bugs that cause the keyboard to act weird, but otherwise the application itself is fairly simplistic.
Communicate and start early. You can't start early enough. We had the benefit of starting this project early, which meant that things got done much sooner than they would have otherwise. We ran into some issues later on in the semester and that early start saved us from having to catch up on a lot of work.
Research is also incredibly important for a project like this. Flutter itself was a hurdle for some of our teammates and that is without all the plugins that we had to use. Being able to accurately search for information saved the team a large amount of time when trying to find solutions.