Extensible Application Framework
When building a large application, it is important to have a well thought out workflow. This is one problem I have to solve while building my “Smart Mirror”. I realize that I have a very limited amount of time to complete what I want, but many difficulties to overcome. Since I am working by myself, my processes need to be as efficient as possible to maximize my outputs.
I decided that my application would need to follow protocol to keep it structured and efficient. This protocol in software terms is often referred to as a framework. Since I would constantly be adding features and functionality to the device, I placed high importance on building an extensible framework.
Although this framework was initially designed to aid in my development process, it will potentially have much more important applications outputs in the future, which will define the nature of the project.
To me as a developer, this framework means efficiency. Efficiency in writing code, implementing it, and editing it. The software of my device will have many screens and functions, and if not well managed the application would become unusable. For this reason I decided a good strategy was to maximize code re-usability.
Each “application” of my mirror has its' own package. The layout for each feature is formatted to certain style specifications to allow it to fit in my layout framework without issues. The voice commands that activate that application are stored locally in that package, and are accessible by the main service. My program is switching activities and layouts constantly, but I need to maintain constant contact with the sensors on my device for voice recognition, motion detection, face recognition, and network transactions. To solve this I have implemented several background services which handle all of those tasks on their own threads.
More important than the benefit now, is the potential benefit to the platform as a whole in the future. A hardware and software platform is highly augmented by the applications that developers create, and the degree that users take advantage of that functionality.
The application framework that I use for development now could become an extensible framework for widgets and user made applications in the future.
This would allow for modules to be added and removed from the software painlessly.
The framework that I am developing has gone through many stages. Currently the largest focus was on transferring between tasks based on voice commands, without using hard coded databases. When a voice command is going to be executed, there are two parameters to be considered; the spoken command, and the application context. Simply, this means what the users said and on what page of the application. These are passed in string variables from the voice recognition result callback to the switcher class. The same switching class is used by all modules of the application. I am able to switch the activities dynamically using secured java reflection. This means that just a few lines of code can handle switching for the whole application. To switch the layout, a Fragment Manager is used. However, I did not want to have this code sitting in every module of my program. So in the switcher class I created a fragment switcher method which is capable of pulling the integer IDs out of the compiled resources file, and referring to them dynamically to switch layouts.
For this to work, my activities and layouts all follow a very specific naming convention which allows them to be located easily.
The result of all of this work is that each voice command goes through the same exact code, while each producing a different result. This means that adding a new module to the application is much simpler than it would have been without this work.
Conclusions and Continuations
In the future I plan to continue this framework to create an ecosystem which will define my project's scope. I am conceptualizing items such as an app center, user configurable widgets, and an entirely customizable user interface.