What are the allowed and required elements of the personal Android project?
Each student’s project will have its own set of functional and aesthetic features. However, all projects are expected to include a core set of implementation and documentation elements; these are summarized below, and specified in more detail in the accompanying rubrics.
Note: In this page, and in the accompanying rubrics, sentences like “The Android app must implement functionality X” or “The Android app should implement functionality X” should be interpreted as “For full credit, the Android app must implement functionality X.”
Successful completion of the Android project requires a wide range of design, technical, and user documentation. In general, the following are required for full credit. Easch is introduced in a relevant milestone, and is expected to be updated as necessary in subsequent milestones.
Many of the elements listed here will be expected to follow particular naming conventions or style guides. This level of detail is not included in this document, but will be specified in the milestone rubrics.
This includes the app name, the summary of the app’s functionality, and any additional supporting details not addressed in the other documentation elements.
Central to the functional design is this list of generalized intended users, where each list item is accompanied by a simple statement of key functionality required by that user type, including the benefit that will be obtained from that functionality.
This is a high-level diagram of UI layout and flow (with few details regarding fonts, colors, or precise positioning of elements), used to specify the key elements of the user experience.
This diagram shows the domain model classes—i.e., classes that correspond to physical or conceptual objects in the domain being modeled by the application—and relationships between them.
This diagram shows the entities (high-level persistence classes) and inter-entity relationships managed in the app’s relational database.
These are the SQL statements that completely specify the structure of the app’s relational database.
Documentation embedded as specially formatted comments in the Java source code is used to generate HTML-formatted documentation of the accessible packages, classes, interfaces, methods, and fields in the code. Students are expected to write and maintain these comments in the source code of their Android apps.
Students are expected to demonstrate respect for their own and others’ intellectual property. All of the libraries used in class-wide coding activities are classified as free and open-source software (FOSS); however, all have some license notice requirements, which students are expected to fulfill when using any such libraries in their personal Android projects. Students are also expected to declare their own intellectual property using the appropriate copyright and license notices.
The process of preparing the build environment, obtaining the source code, building the app, and deploying it to an Android device for testing must be documented.
User-level documentation is expected to include minimum hardware and software requirements; peripheral hardware requirements and optional capabilities; and the operations (starting with launching the app) required to perform the actions for at least 2 user stories.
It is often the case that not all planned elements of the app are completed during the project. This will not be penalized per se, as long as key technical requirements are met, and as long as the state of completion is accurately described on final delivery. This description must include not only unimplemented functionality, but known deficiencies (especially conditions under which the app is known to crash).
This element is related to the state of completion, but focused on formal & informal test conditions and test outcomes.
This is a list of potential functional enhancements, coherent with the primary underlying aims of the development project, the implementation of which would not significantly change the fundamental nature of the app.
We expect that students will propose and execute Android projects in a wide variety of application domains. In signing off on on proposals at the start, and in grading project work at the milestone, we have no interest in prioritizing productivity apps over games, utilities over interesting wastes of time, “serious” apps over eye candy. However, because we are committed to helping students build skills that will position them well for employment as developers, we do require that all the personal Android app include a number of key implementation elements.
Use of the SQLite relational database management system (RDBMS), incorporated in virtually all Android phone & tablet devices, is required for persistent storage of app data (master lists, transactions, events, etc.).
All apps are expected to incorporate multiple screens, and to implement rational, intuitive navigation controls for moving between screens. In general, navigation will be expected to follow Material design guidelines for navigation.
Every app is expected to include data displays—lists, grids, pagers, etc.—without preset or hard-coded content or bounds, which instead take their content from database queries or external service requests.
By default, an Android app runs entirely in its own sandbox, unable to see or modify the behavior or data of any other app on the device, unable to leverage the shared hardware/software services of the device (e.g. camera, contacts, messaging, sensors), unable even to access the Internet. However, an app that can escape this sandbox—using the supported facilities for doing so—becomes (at least potentially) much more powerful and interesting.
Each student’s Android app is expected to include some functionality that integrates with one of these device or external services or data sources—requesting data from an external web service, reading or writing files in the device’s external storage (a portion of the device’s non-volatile storage which can be accessed by multiple apps), capturing an image with the device’s camera; reading or updating the user’s list of contacts; reading data from the device sensors; etc.
Apps are expected to maintain user-specified (or system inferred) preferences and configuration settings via the Android Preferences framework (the recommended approach) or a SQLite database.
Almost as important as the required elements are those elements that are specifically excluded from the allowed project scope. Most of these are excluded not because they’re beyond students’ abilities, but because the magnitude of effort required to implement them, without sacrificing the required project elements, wouldn’t fit within the time constraints of the personal Android project. (On the other hand, several such features are allowed in capstone projects.)
Out-of-scope features include—but are not limited to:
Continuous, real-time animation, beyond simple object motion.
Real- or near-real-time interaction between distributed users.
Any features that are only usable if the application is installed on multiple devices.
Use of server/cloud-based services that are not already running, freely accessible, and well-documented.
Any features that require the use of fee-based services in development or testing of the app.
Dependence on additional hardware devices (i.e. besides the Android device) for core functionality.
E-commerce applications that include any financial transaction handling.
Machine learning, computer vision, or other AI applications.
Integration with SMS messaging or telephony.
(SMS & telephony integrations are difficult—sometimes impossible—to implement, test, and evaluate when using emulators. Under some conditions, an exception may be granted by the instructors for simple SMS or telephony integrations; a necessary, but not sufficient, condition for such an exception is the use by the student of a physical Android device—rather than an emulator—as a primary target platform.)