In what follows, we provide some guidance on design and coding for your Android programs. Then, we list a grading rubric for each lab. As the labs progress we become more picky about good design and good code.
Remember a program (classes, methods) should do one thing and one thing well. You should start to write good readable code from the start (see coding tips below). Break your programs into meaningful classes/methods. Be defensive when dealing with user input and other interfaces. Always check return values (a reference to an object that might be null) and exit gracefully if an error has been encountered – IO failed – inform the user if needed in a meaningul way.
Keep the MVC (Model, View, Controller) architecture in mind when doing OO design for your Android applications:
Your design should be a modular, object oriented approach.
Design reusable functions, rather than rewriting the same code over and over again -- don't write random functions, make sure they are meaningful.
In your Android studio project, cluster your classes into meaningfully named packages that represent the decomposition of your app; for example: model, view, datasource (e.g., database helpers). This makes your code modular and readable.
Push as much of the UI functionality into the Layout XML and reduce programmatic logic for wiring in the controllers
Offload as much as the computation from the UI thread to for example worker threads, runnables, and async tasks. If you don't your UI will freeze up.
Keep the model logic and data separate from the controller logic by using object encapsulation and getters/setters on the model data.
Don't ignore exceptions: It can be tempting to write code that completely ignores an exception, don't do it.
Write short methods: If a method exceeds 40 lines or so, think about whether it can be broken up without harming the structure of the program.
Comment your code: It should be self evident what well written code does, but add comments to explain classes, methods, code logic in a method if it is not self evident. Don't over comment code.
Limit variable scope: Keep the scope of local variables to a minimum. By doing so, you increase the readability and maintainability of your code and reduce the likelihood of error.
Limit line length to 100 characters. Helps with readability of your code.
Log when you need to: in this class we promote logging to understand control flow, inspect variables during run time, etc.
For most labs we give out the apk solution so you should code to the solution behavior and what is detailed in the design document. However, here we breakdown the grading. Typically, labs are graded on completeness of the required features, the correctness of the functionality, and the robustness:
Please make sure that your submitted code has no warnings in the Android Java code or XML. We will not grade code that has compilation/lint warnings unless you have the OK from the TA in advance for some edge case that can't easily be cleared:
You should download, inspect and run all code examples in the notes (.zip files) to fully understand concepts and patterns taught in class. However, you cannot under any circumstances ``cut and paste'' these examples into your solutions for your submissions. You should use these coding examples as a learning tool; always code your own intrepreation of these coding examples in your solutions if you choose to use the patterns; that is, look at the code and understand how it works but always code your own versions of these patterns if you use them in your solution:
Note, MyRuns is a single user app. You do not have to design for multiple user registration in MyRuns1.
We only consider correctness in this lab. Does the app work correctly as specified in the design document and APK. (points out of 100)
Does the app have the complete UI as shown in the demo apk (25/100)? Note, we don't get hung up on the UI being exactly the same in layout as the demo APK layout but all the widgets and relative layout should be the same. (Including required permissions)
Does the app let you take a picture for the profile image making sure its rotation is correct when stored (10/100)?
Does the app crop the image, render it to the UI and save it correctly (10/100)?
Does the app let you select either a photo from the gallery or camera apps through showing the options the dialog (5/100)?
Edge case: After change in the orientation of the phone (e.g., rotation) or other user behavior (e.g., user pushes the app into the background, starts another app, and then navigates back to the paused app) in the register activity, does the app keep the cropped image which has just been taken but not saved yet (that is, the saved button has not been click yet) (10/100)? -- Remember onSaveInstanceState() and onRestoreInstanceState() methods in the activity class.
Does the name, email, password, phone, gender, class, major have correct input field? e,g., phone allows input of a number? (15/100)
Are buttons (also including buttons in the action bar of register activity) wired correctly (10/100)?
Can the app save the user's profile information in shared preferences (15/100)?
Optional: does the app emulate the network delay for authentical during sign on using a ProgressBar as shown in the MyRuns1 apk
We consider both correctness and well-written code in this lab. You should consider the design and code tips above as guidelines to designing and writing good code. 85% of the grade will be for correctness and 15% for style/well-written code. In terms of correctness: does the app work correctly as specified in the design document and APK we have handed out. As the term progresses we will increase the point allocation to writing good code so start now (points out of 100)
Does the app have the complete UI as shown in the demo apk (40/100)? Note, we don't get hung up on the UI being exactly the same in layout as the demo APK layout but all the widgets and layouts should be the same. In this case we have two pages in a view pager (start and history), and two menu items (settings and edit profile), all with different UI layouts and wiring to the controllers for different widgets. Your app should implement all the UI features including preferences and dialog interactions in the settings and manual entry activities as well. (Including required permissions and updating UI by changing the values of different items in manual entry activity)
You have to refactor your UI to handle the error processing for user input as shown by the MyRuns apk; specifically, are the error messages shown properly against not inputting the required fields in SignIn and Profile activities? (5/100)
Does the app correctly transition between pages through touching different buttons and tapping the bottom navigation items (10/100)?
Can app restore and display saved profile information and photo in the profile activity (10/100)?
Does the app start again from SignIn activity after changing and saving the password in the Profile activity (6/100)?
Is the email field un-editable in the profile activity (4/100)?
Edge cases: After change in the orientation of the phone (e.g, portrait to landscape mode) or other user behavior (e.g., user pushing the app into the background, starting another app, and then navigating back to the paused app), does your app maintain all data that has been input by the user (15/100)?
Is your code well-written: short methods, handle exceptions, comments in code (15/100)?
We consider both correctness and well-written code in this lab. You should consider the design and code tips above as guidelines to designing and writing good code. 80% of the grade will be for correctness and 20% for style/well-written code. In terms of correctness: does the app work correctly as specified in the design document and APK we have handed out. As the term progresses we will increase the point allocation to writing good code so start now (points out of 100).
This lab is focused on implementation of a database of Exercise Entry objects. The actions are to write, read and delete exercises from the database. The UI work is simple based on prior assignments. As discussed in class you have to off load the read and write database operations to background threads.
Does the app have the complete UI as shown in the demo apk (10/100)? Note, we don't get hung up on the UI being exactly the same in layout as the demo APK layout but all the widgets and relative layout should be the same. In this case we have two pages in a view pager (start and history), and two menu items (settings and edit profile), all with different UI layouts and wiring to the controllers for different widgets. Your app should implement all the UI features including preferences and dialog interactions in the settings and manual entry activities as well. (Including required permissions)
Does your application cleanly implement the Exercise Entry object with the correct member variables and constructor/getters/setters methods (5/100)? For the first time in an assignment you implement the main data object in the Model Layer of the MVC framework. On a write you only need to instantiate a single exercise entry object, but on read you will create an object for every entry in the cursor.
Does the app save and retrieve data from the database correctly (15/100)?
Does the app delete an exercise from the database correctly (10/100)?
Does your code use an AsyncTask for writing and deleting data on the database and update UI in onPostExecute() callback function (10/100)?
Does your code use AsyncTaskLoaders when loading all (query all) and specific exercises from the database? (10/100)
Does change in Units preferences instantly change the distance units to Miles/Kilometers respectively? (5/100)
Edge cases: After change in the orientation of the phone (e.g., portrait to landscape mode) or other user behavior (e.g., user pushing the app into the background, starting another app, and then navigating back to the paused app), does your app maintain all data that has been retrieved from the database (10/100)? A challenge in mobile design is maintain the state information of the app under changing conditions. It is really important to think and deal with these edge cases. Note down all the edge cases and make sure your app works for all of them like the solution MyRuns3 APK handed out to you.
Does your code use a background thread to delete information in the database (5/100)?
Is your code well-written: short methods, handle exceptions, comments in code (20/100)?
We consider both correctness and well-written code in this lab. You should consider the design and code tips above as guidelines to designing and writing good code. 85% of the grade will be for correctness and 15% for style/well-written code. In terms of correctness: does the app work correctly as specified in the design document and APK we have handed out. As the term progresses we will increase the point allocation to writing good code so start now (points out of 100).
This lab is focused on implementation of of Google Maps, getting location updates, tracking service, activity recognition, broadcast receivers, and notification. Note, your service has to offload the processing associated with locations and activiy recognitions from the TrackingService (which actually runs on the UI thread). These worker threads do the processing and inform the MapActivity when information is available via broadcast receivers.
A number of the key components in many Android apps. You have to integrate this into your existing MyRuns3 design based on the design spec.
Does the app have the complete UI as shown in the demo apk (10/100)? Note, we don't get hung up on the UI being exactly the same in layout as the demo APK layout but all the widgets and relative layout should be the same. The UI includes Maps and polylines in terms of map display for example. (Including required permissions)
Does your app implement the ``sticky'' foreground service for tracking (i.e., the TrackingService) the user's location correctly (15/100)?
Does your service start an IntentService to offload processing for Locations updates and broadcast (receiver) informing the MapDisplayActivity that a new location is available (10/100)?
Does your app draw the start and end points markers, as well as the path (polyline) followed by the user between the start and end point markers? (5/100)
Does the map load correctly when the user selects a summary from the history fragment view for a GPS/Automatic entry in the listView (5/100)?
Does change in Units preferences immediately change MapActivity information units in terms of Miles/Kilometers respectively? (5/100)
Can the app recognize the type of activities using Google ActivityRecognitionClient API implemented in TrackingService (10/100)?
Does your app use IntentService to offload processing associated with Activity Recognition and broadcast (receiver) informing the MapDisplayActivity that a new detected activity (confidence more than 70%) is available (10/100)?
Does your app work in the background? Meaning, when the app goes in the background, TrackingService and map updating should still be running (5/100)?
Does the app create a notification when the TrackingService is started, and navigate back to MapActivity by clicking on the notification when app is running in the background (5/100)?
Afer completing an exercise using Automatic mode does your app save the correct activity (e.g., running) when the user saves the exercise. For example, I might run for 30 mins but the activity might be still when I click the save button. This would be incorrect because the majority of inferences were running not still. You you need to keep a record of the inference counts and select the inference (e.g., running) with the greatest count to save. (10/100)
Is your code well-written: short methods, handle exceptions, comments in code (15/100)?
Bonus Edge Cases: Does the app keep information, start and end markers, and the path when flipping the screen and changing orientation. Finally does you app acquire and release resources based on the lifecycle of activities, fragments and services (e.g., canceling the notification and location updates in onDestroy() of the Tracking Service (10/100)?
We consider both correctness and well-written code in this lab. You should consider the design and code tips above as guidelines to designing and writing good code. 85% of the grade will be for correctness and 15% for style/well-written code. In terms of correctness: does the app work correctly as specified in the design document and APK we have handed out. As the term progresses we will increase the point allocation to writing good code so start now (points out of 100).
Does the app have the complete UI as shown in the demo apk (10/100)? Note, we don't get hung up on the UI being exactly the same in layout as the demo APK layout but all the widgets and relative layout should be the same. The UI includes Maps and polylines in terms of map display for example. (Including required permissions)
Does your app handle multi-user signup and signin using Firebase Authentication service (10/100)?
Does your app keep the users' exercise data in the Firebase Realtime database (10/100)?
Does the app retrieve the data from the Firebase database and update the phone data if the data in the cloud is changed (10/100)? See the functionality of Firebase Realtime database listener in the API.
Does your app send the users' exercise data to the MyRun5 ``social server'' (see design doc) using the http post method (15/100)? Note that when anonymous posting, you should send a SHA1 or MD5 hash of the email instead of the email.
Can the app get all exercises saved (i.e., boarded) in the social server using the http get method (10/100)?
Does your app avoid redundancy when uploading records to the Firebase database (10/100)? Meaning, if you have already stored an exercise in the Firebase database you need to avoid storing it again. That'd be a waste of app processing and network bandwidth.
When you uninstall and then reinstall your app and then sign in (you have an authenticated account and stored exercises in the Firebase database) does your app load all the exercises from the Firebase db into your local SQLite db (10/100). Note, to do this correctly you actually need to store all client side data into the Firebase db including all exercises and the user's profile. If you do not restore the profile it will remain empty.
Is your code well-written: short methods, handle exceptions, comments in code (15/100)?
We will have a number of (probably 3) short coding assignments called CodeIts. These will not be complex like MyRuns and just reinforce what we discussed in class (e.g., edge cases, finding bugs and fixing them, then testing to make sure no bugs exist).
We will grade CodeIts simply. We will only look at functionality -- does the app do what we asked.
Don't get stressed about CodeIts. They are more brain teasers. And fun.