What's included in the final sprint, and how is it graded?
This is the final deliverable of the personal Android project. This milestone is cumulative: It include elements delivered in earlier milestones, but these should be updated as necessary, and they won’t be weighted as heavily in the grading. (Note: If these elements from earlier milestones have not been updated, and do not correspond to the application in its current state, you will not get full credit for them.) Thus, the delivered content for this milestone is expected to include project summary elements, intended user identification & stories, data model documentation, data model implementation, any appropriate connections to device/platform/external services, user authentication, and a functioning user interface.
Important: Sensitive content needed for building and running your app—e.g., API keys or other credentials for external services—must not be committed to your Git repository and pushed to GitHub. Instead, files containing such content—as well as any .properties or other files not included in the repository—must be submitted separately from the repositories, as directed by the instructors prior to the deadline. If you don’t know whether some key or credential used in your project constitute sensitive content, please discuss it with the instructors before committing it to your Git repository. (Please do not assume that committing a file containing sensitive content and then deleting that file later will make the file inaccessible on GitHub; it won’t—even if that deletion occurs before the first time you push to GitHub.)
Please include (in your build instructions) all necessary steps for incorporating this content into the build of your app.
The nominal total value of this deliverable is 75 points. Up to 15 more points can be earned for exemplary execution of any or all of the required elements, as outlined below.
See “Milestone 1: Project description” for this element’s requirements.
See “Milestone 1: Intended users and user stories” for this element’s requirements.
See “Milestone 1: Cloud- or device-based services or data” for this element’s requirements.
See “Milestone 1: Wireframe diagram” for this element’s requirements. Please note that you must update the wireframe if—while working on the navigation—you have changed your planned flow through the different screens.
See “Milestone 1: UML class diagram” for this element’s requirements. Also, please note that any updates to the acessible attributes (properties) and operations (constructor and method declarations) in the domain classes must be reflected in corresponding changes to the UML, and vice versa.
See “Milestone 2: Entity-relationship diagram (ERD)” for this element’s requirements. Also, please note that any updates to the persistent elements of the entity classes must be reflected in corresponding changes to the ERD, and vice versa.
In grading a prototype, understanding what is does and doesn’t (yet) do is important preparation for evaluating it in operation. Please provide the following in separate paragraphs & lists:
A description of the current state of completion/readiness of your app. This should include a “hit list” of deficiencies: any unimplemented/incomplete elements, and known bugs, that would have to be implemented or corrected for a usable prototype (i.e. one that could be given to a skilled user for testing and feedback), ordered with the most urgent items first.
A list of aesthetic/cosmetic (not functional) enhancements that you think would improve your app. This list should be ordered, with those that would give the most improvement (in your opinion) listed first.
A list of functional stretch goals. These should be sorted either with those that would add the most utility at the top, or with those that would be the simplest to implement at the top.
Your project documentation must include the following:
A list of Android API versions and hardware (including emulators) on which you’ve tested the submitted version of your app, the minimum Android API required, and any other hardware/software/orientation restrictions that you’re aware of. This includes any restrictions on device language, orientation, etc. that a tester should be aware of.
A list of the 3rd-party libraries (i.e. anything beyond the Android standard and support libraries) used by your app. These include (but are not limited to) Google Sign In, Google Maps, Gson, Retrofit, ReactiveX, and Picasso.
A list of Android permissions required to run the app. This must include “safe” permissions (i.e. those not requiring explicit opt-in permission from the user) and “dangerous” permissions (those that the user must explicitly allow). For each of the dangerous permissions, please indicate whether the app can still execute without that permission, and—if so—what functionality will be unavailable if the user does not grant that permission.
A list of the external services (including Google services such as Sign In, Calendar, Maps, etc.) and device services (sensors, camera, audio recorder, etc.) consumed by your app.
The project must include Javadoc documentation. Please keep in mind that including this requires 5 distinct, high-level actions:
Add Javadoc comments to all public classes, and all public and protected members (fields, constructors, methods, and nested classes and enums) of those classes. The only allowable exceptions to this are methods with the @Override annotation, which do not necessarily require additional comments. (While simple setters and getters only require minimal Javadoc documentation, they must have some.)
Execute the appropriate Gradle task to generate Javadoc HTML/CSS/JavaScript artifacts from the Javadoc comments; these should be generated into the docs/api subdirectory of your project.
Add and commit the generated files to your Git repository.
Push the generated files to GitHub.
In your documentation pages, link to the generated Javadoc pages.
The project must include copyright statements and license information—for your app itself (you may optionally choose an open source license for your app; this is not required), as well as for all relevant 3rd-party libraries.
Note that it is not sufficient simply to include a link to the license information on each library’s publisher’s site. Most open source licenses specifically state that software incorporating the licensed software must include copyright and license information in the documentation, include the relevant license statements in the source code repository, etc. As a general rule, this implies that your project must include the following:
A NOTICE text file including all copyright and license information for your project, and for the libraries used.
A corresponding page in the GitHub Pages site, containing the same information as the NOTICE file, formatted for website display.
These must include the steps required to:
Clone/download the repository.
Import the project into Android Studio/IntelliJ IDEA.
Execute the build.
If any content not included in the repository (e.g., an API key) must be incorporated for a successful build, instructions for doing so must be included. (Any such content must be provided to the instructors via Slack.)
In writing these instructions (another Markdown file), it should be assumed that the user is reasonably experienced with the Android OS, familiar with most standard navigational devices (e.g., navigation drawer, action bar, overflow menu, back button). The user instructions should thus focus primarily on app-specific operations for exercising the implemented functionality.
In order to grade the app itself, the instructors must be able to build the app, install it on a physical device or an emulator, and run it. In doing so, the build instructions and basic user instructions provided in the documentation will be followed. Of course, when following those instructions, if there are serious failures, this can prevent the evaluation of the app’s functionality and technical elements. For this reason, the steps of building, installing, and launching the app—like committing and pushing the project repository to GitHub—have no direct point values associated with them; but any issues encountered here will almost certainly affect the grade indirectly.
Can the user navigate easily and intuitively between the screens (activities and/or fragments) of your app? In navigating through your app, does the back/up button work in a sensible manner with the rest of the navigational elements (e.g., bottom button navigation, navigation drawer, action bar items)?
For more information on navigation concepts and design, see “Understanding navigation”, Material Design. For additional information on navigation implementation techniques, see the “Navigation” section of the “Develop UI for navigation” developer guide.
Your app must use SQLite—either directly via the SQLite library or via the Room ORM persistence library—for the app’s primary persistent data store
For an overview of SQLite use in Android apps, see the “Save data in a local database using Room” section of the “App data and files” developer guide.
Almost all apps that make use of a data store such as SQLite will need to provide the user with views of the stored data. For some purposes, looking at a single record at a time is sufficient; however, letting the user view multiple records at once (e.g., in a scrolling list or grid) is generally an important feature. Even an app that uses the tabbed activity with the swipe left/right navigation style will typically need to construct the set of available pages dynamically, by querying the database.
For credit in this category, your app must use one or more instances of data-driven view groups such as ListView, RecyclerView, ViewPager, GridView, or some functionally equivalent alternative (possibly a subclass of one of the above), populated by data from the data store, to present some portion of the app’s data to the user. (Note that a ViewPager presenting a fixed number of pages does not satisfy this requirement.)
Don’t forget to include launcher icons (mipmap resources) in your app! Additionally, drawable resources are typically used in bottom navigation buttons, and sometimes in action bar items and navigation drawer items. Of course, games will often use drawables extensively. For all of these, keep in mind that some kinds of drawables work much better than others for certain purposes. For example, bottom navigation buttons, navigation drawer items, and action bar items will generally need vector assets, rather than raster (image) assets.
While the standalone Android project requirements do not include (and in fact, specifically consider out-of-scope) a server-side development component, it is very common for an Android app to consume data from, or otherwise integrate with, existing web services. This might take the form of integrating Google Maps with your app, implementing a component in your app that consumes relevant data from an outside service, etc.
One such service, frequently overlooked, is the OpenID/OAuth 2.0 authentication service accessible through the use of Google Sign In; by itself, that will earn 2-3 points in this category, depending on how the account information is used (or not) to personalize the user experience.
Even if the app doesn’t consume any additional external data or services in real time, a data pre-load, using data obtained from an external source, may be used to earn points in this element.
Apps may also integrate with Android features such as contacts, location services (i.e. GPS), messaging, MediaStore, camera, sensors (accelerometer, magnetometer, etc.). Typically, such integration requires the user to grant specific permissions to the app; implementing a suitable workflow for requests any required permissions will be considered part of this implementation element.
Your app must maintain multiple user preferences, application settings, or other application state properties in Android shared preferences; after such values are saved or updated, the saved values must then be read and utilized in some aspect of the app’s behavior. See “Save simple data with Shared preferences” for more information. (This requirement may be satisfied through the use of SQLite, but shared preferences are preferred for this purpose.)
While it is not necessary to use <PreferenceScreen> XML resources or the PreferenceFragment or PreferenceFragmentCompat classes in order to use shared preferences in an app, these UI features may easily be employed to allow direct user control over some or all of an app’s shared preferences.
The basis for awarding extra credit for exemplary execution includes not only functionality, but also development practices as evidenced by the code base. Elements eligible for extra credit include, but are not limited to, the following:
Instructors will be assessing the organization of the code of your app into packages, with an eye to how the contents of each package are (or aren’t) oriented to addressing different areas of concern in the app (e.g., managing changes to application state, long-term persistence of application state, integration with external services, visual representation of application state, handling user interaction).
For this portion of the grade, the instructors will assess the overall code quality—primarily in terms of code clarity and conformance to the DDC Style Guide, but also examining encapsulation; degree of cohesion within classes and packages (greater cohesion is better); degree of coupling between classes (lower level of coupling is better); occurrence of repeated code, unused code, or unused resources; etc.