605.686.81 - Mobile Application Development for the Android Platform

Expanded Course Description

Prerequisites

This course relies on a high comfort level with the Java or Kotlin language and basic APIs. The course moves quite quickly and there is no time to learn Java while taking it.

This course includes a Kotlin primer (which assumes Java knowledge), and will demonstrate other Kotlin constructs in presented examples.

You will need to feel very comfortable with:

• The Java or Kotlin language, especially
  • Class and interface inheritance
  • Properties (fields with getters and setters)
  • Inner classes (including anonymous inner classes [Java] or objects [Kotlin])
  • Using callbacks/listeners/observer pattern
  • Using threads [Java] or coroutines [Kotlin] in your application
  • Debugging by reading exception stack traces
    
• Writing basic XML files in an editor
• Simple SQL database statements (some basics are covered in the course, but having some database experience will help greatly)
  
• Basic data structures in Java or Kotlin (lists, maps)
  

Course Structure

For online sections, all course content is available at https://androidbyexample.com. Modules may be textual, video, or a combination. Note that this content is available for all sections, online or virtual-live, but for virtual-live sections, this material is considered supplementary. The material taught in the virtual-live sessions is considered the material you must use for the course.

For virtual-live sections, I will video record the lectures and post them along with any sample code after the class meeting.

Course Topics

(Order of some topics may vary based on term)

• Course Hardware and Software
• Assignments
• Grading
• Using Third-Party and Course Sample Code
• Kotlin Primer
• Architecture
• Android Studio
• Jetpack Compose
• Room
  
• Widgets
  
• Speech
• Google Maps
• REST services
• Legacy Views
  
• Testing
  
• Files
• Sensors
• NFC
• Services
• Publishing

Course Goals

Explore the differences between mobile and desktop application development, and demonstrate these differences through the development of Android applications.

Textbooks

Online Textbook(required for online sections, supplementary for virtual-live sections)

https://androidbyexample.com

Other Materials & Online Resources

Required Software

Android Studio: https://developer.android.com/studio, installed via JetBrains Toolbox.

(instructions provided in course materials)

Student Coursework Requirements

This course is graded on 9 programming assignments. There are no tests or graded discussions in this class.

Late submissions will be reduced by one letter grade (1 point off 4-point assignments; 2 points off 8-pouint assignments) for each DAY (or partial day) late (no exceptions without timely prior coordination with the instructors). See the grading policy for assignment grading details.

If you expect any issues with turning in work on time, please contact the instructor as soon as you know. If I know in advance about travel, expected high workloads or other issues, I can work with you. However, letting me know a day or two before an assignment is due is not acceptable (If an emergency occurs, please let me know as soon as possible afterwards.)

If you encounter issues while trying to submit your assignment, please immediately send me an email with your submission zip and a note stating that Canvas is being your best friend. If you submit in this manner, I will not count your submission as late.

Note that the easiest way to get a lower grade is to turn in your assignments late. If you know that something is coming up (business/vacation travel, expected very busy week at work, medical, expected baby) please let me know and I'm happy to work with you.

Note: I highly recommend that you store your code in a version control system such as git. However, if you host your project on a public site like github, gitlab or bitbucket, you must make the repositories private! Any non-private repositories that I find online will automatically set your grade to "F" for sharing code.

Be sure to control your source code! Lost code will not be accepted as an excuse for late or missing assignments.

These are general guidelines, not absolute descriptions of a grading level. Your overall grade on an assignment depends on the overall quality and functionality of your submission. Again, these are general guidelines. You can get lower grades for very significant problems in your submissions and very late submissions.

I grade on the following aspects of your submissions. Note that there is no specific percentage allocation for each of these concepts.

I expect your assignments to follow the approaches I demonstrate in the class examples. When I see other approaches in your submissions, it sends up warning flags for me that you may be plagiarizing (I've caught several students this way). I'll spend a good bit of time examining your code and online code that feels similar. Sometimes I'll notice approaches that I used to teach in previous terms, and then find a previous-student submission that matches.

Please make my grading easier and your grades safer - follow the class example approaches and don't copy code from other students in previous or the current class sessions.

Violation of the academic integrity policies will result in a minimum penalty of a 0 for the assignment in question, but there could be higher penalties depending on the circumstances.

All assignments must observe the following coding conventions.

Why? I read your code

Sometimes your code doesn't work correctly. Before I decide on the grade to give you, I carefully read the code to try to figure out why it didn't work. If the reason is a small, subtle thing, I'll often give more credit (rather than simply saying "doesn't work; you get a C") I often have to do this for multiple assignments. If the code is readable, using meaningful variable, method and class names, I can often find the problems more quickly.

• Indentation must be consistent. Use either leading spaces or tabs, but not both!

• All type names must follow Upper-Camel Case:

  • ShoppingCart
  • ObjectDrawingApplet

• All Composable functions that generate user interfaces must follow Upper-Camel Case:

  • MovieDisplayUi()
  • SettingsUi()

• All variable and other function names must follow Lower-Camel Case:

  • drawObject()
  • numberOfObjectsOnScreen

• Type, variable and method names shall be a series of full words, not abbreviations or single letters.

  • Standard acronyms are acceptable (such as url or http), but names like c are generally not acceptable. If you aren't sure whether a name is acceptable, feel free to ask me, but remember the rule of thumb: it should sound exactly like what it's being used for.
  • Some Exceptions (based on common, understood usage)
    • integer counters in loops can be named i, j, k
    • the "current number" for walking through an array or counting items can be n
    • e for an exception in a catch block

• All classes and interfaces must be contained in a Kotlin package

• All Kotlin package names must be completely lower-case and start with lastname.firstname.hw# where the # is the homework number. For example, I might have a project named stanchfield.scott.hw4 (with the same Android package name) that contains Kotlin packages:

  stanchfield.scott.hw4 stanchfield.scott.hw4.model stanchfield.scott.hw4.database

• All projects must be named HW1, HW2, HW3 and so forth

• All submission zip files must be named lastname.firstname.HW1.zip, lastname.firstname.HW2.zip, etc

• All string literals that would appear for the user (typically text in TextViews, dialogs, toasts, etc) must be externalized into the strings.xml file. This is a really good habit to get into upfront, and you should always do this in any application you create to make localization simpler. This means all user-facing text. Any string constants that the user could see, whether used in your XML files or Kotlin code, must be externalized.

Grading Policy

Assignments are worth 4 or 8 points each, mapping to GPA letters.

I assign letter grades first, then convert them to numbers and apply late penalties. The grading scale from letters to numbers is as follows:

Note: Percentages for coursework map back to letters as follows:

• 100% = 4.0 = A
• 75% = 3.0 = B
  
• 50% = 2.0 = C
• 25% = 1.0 = D
• 0% = 0.0 = F

This keeps the weight of each letter even, so an F (0) and an A (4) average out to a C, rather than a 0 and 100 averaging to 50 (which would be an F by the traditional scale).

Your final grade WILL NOT include +/- designations. A/A- both count as "A" and "4" for University GPA purposes(and similar for other letter grades).

Each day late results in 1 full letter grade deduction (1 point off 4-point assignments; 2 points off 8-point assignments).

When grading assignments, I will write comments describing your grade, but I will not note specific point-value deductions (see "Holistic Grading" below). Some comments are "for your information"/"helpful hints" and will be marked to indicate that they have no effect on the grade.

If you disagree with a grade you can ask me to review it. Tell me what your concerns are and I'll look at it. Sometimes I may miss something in your code.

If I note a problem with a submission that was also noted for a previous submission, I will not count off for it. (If I do, please let me know and I'll correct the grade.)

I started out using a rubric to grade. For many reasons, this almost never reflected reality. I came up with a much fairer scheme that I call "holistic grading".

First, some problems with Rubrics...

• Gaming the System

  When I had point counts next to features, many students would decide which features to implement based on how many points they felt they could afford to lose. Rather than implement all function (the point of which is to exercise important techniques), they would implement a subset just to "get the grade". This is frustrating for a teacher because we design exercises to be sure students have had the opportunity to try out important techniques.

• "Sum of the Parts" vs "The Whole"

  Rubrics tend to cut both ways when the points are added up...

  Sometimes, a few relatively minor things that don't greatly impact the overall submission would numerically push the grade into "B" territory or lower. This didn't feel fair to the student based on the overall result, but to be fair to all students I had to stick with the grade based off the rubric.

  Other times, small things that made an impact when combined could result in an "A" that didn't feel right (sometimes because of gaming the system, other times because the small problems really added up).

• "That shouldn't be n points off"

  The most common complaint would be that either the rubric was unfair in the number of points it assigned to a specific item, or that I was applying a rubric item too broadly to a problem in the submission. Most of the time I would leave the grade as-is, but in some cases it was a matter of a possible alternative interpretation of the assignment requirements, in which case I adjusted the points off.

  Later, after I stopped using rubrics, but would list points deductions on assignment comments, I'd get the same complaints.

  In either case, this never made any significant difference in the grade for the assignment, or the course.

  Students ended up spending a good bit of time trying to figure out which items they could argue to get a few points back, not realizing a few points over the term made no effective difference.

This led me to... "Holistic Grading" (If it sounds a little "New Age", it's not... "Holistic" here simply means "looking at the whole")

"This feels like a B+"...

I'll write comments about what I see in the assignment, and don't write specific deductions for each one.

I look at the overall result, taking all comments into account, and say "that's an A", or "that's a B-", or "that's barely anything more than the sample code" (at which point I estimate the % of the assignment that was done and assign that number).

The letters I assign are converted to numbers. A=4.0, A-=3.7, etc.

When coming up with these letters, one of my key concepts is "things that cap the grade at A-". There's not a fixed list of such items, but things like "coding conventions" fall into this category. If several small things like these happen, a rubric may have pushed the grade into "B" territory. When I see several little things but otherwise the overall submission feels like an "A", I use "A-" as the grade.

If the assignment does everything I ask, in the ways I taught in class, meets coding standards, and is on time, that's where "A" comes in.

Other grades (before late deductions) are usually driven by

• Feature omissions or problems

  Most common: something is missing or doesn't work properly

  This is often because a student started work a shor time before the assignment was due and didn't have time to ask questions or study the concepts.

• Crashes and compilation errors

  Note that I try to make your code work before grading it. Sometimes it's an inverted boolean expression, and if I can get it working and it's something simple, I'll give a better grade than "doesn't work".

  However, sometimes, after spending an hour or two trying to get it to work, I have to give up...

• Working together or Plagiarism

  I've caught many students doing this...

  Sometimes they even try to submit something they found online that doesn't match the assignment description or is very obviously not based on what I've taught.

Bottom line: When you see a "3.7" for a submission, don't think of it as "0.3 points off". Think of it as a few minor things aren't right and you got an A-. If that's how most of your assignments go, that's an overall "A" for the course...

It is possible (and has happened in past sections) for everyone to get an "A" in this course. I will not be applying any sort of curve or other means to artificially distribute grades.

I will be looking closely at your efforts in this class when determining your final grades. An "A" grade in this course requires a good deal of effort. Do not expect an "A" if you start programming a few nights before they are due...

Let me repeat that. Do not expect an "A" if you start programming assignments a few nights before they are due... This has often been the reason for B and C grades in the course; students do not allow enough time to ask clarifying questions or do the coding.

Be sure to at least look over and understand the assignments at the beginning of the week they are assigned! This will give you time to ask questions.

If you do all the work well and on-time, you will get an "A" for the course. If you do all of the work on-time but are having trouble with the concepts, you'll likely get a "B" for the course. If you're in danger of a lower grade, I will speak with you as soon as it becomes apparent to me.

Course Evaluation

I frequently update this course and appreciate any and all feedback. Please complete the course evaluations (midterm and final). If you have other thoughts on the course, what you liked, disliked, topics you wanted to see or any other feedback, please send me an email or post on the Course Feedback discussion forum.

Course Policies

Using Open Source Content and My Code ExamplesNote that you may copy small sections of code and other content you find online **if and only if** you attribute it and the code is freely copyable with a license that says it's ok to copy. Place a comment above the copied section stating where you found it and the license that applies.

You may copy code from my class examples as well. Once again, attribute it. Assume that any code I do not explicitly mark is licensed for your use only in this class and for not other purpose.

Code from the course sample code repository is licensed Apache 2 (see the LICENSE-code.txt file in the repository) and can be used/incorporated into your own projects with attribution.

Code that I write live in face-to-face class or post in a discussion forum are not licensed for any use outside this class. You may not post or distribute any this code.Your Work in this Class

PLEASE READ THIS SECTION CAREFULLY. I HAVE HAD TO SIGNIFICANTLY REDUCE GRADES AND/OR CONVENE ACADEMIC INTEGRITY HEARINGS BECAUSE OF ISSUES MANY TIMES IN THE PAST.

Please be sure to carefully read the Academic Misconduct Policy (linked below).

You are encouraged to discuss the course material with each other as you sort through concepts that may be difficult to comprehend. However, the line between collaboration and cheating needs to be carefully delineated.

Whenever you turn in work with your name on it to be evaluated, graded and included in your record it must represent an individual effort by you alone.

If you include direct quotes or code from any source in your discussions or project submissions, you must provide attribution. Note that you are only allowed to include code when the license for that code is explicitly stated (such as what I mention above for course code samples) and that license is open source.

Note: I have had issues with plagiarism during several terms. I am very good at catching this! Work that you submit as your own must actually be substantially your own. Any code that you borrow must be attributed.

Let me repeat: You cannot discuss what your code or project structure will look like. It's ok to discuss the concepts and code I have demonstrated, but you cannot discuss how to apply those concepts to the homework assignments.

The minimum penalty for academic misconduct is a 0.0 on the assignment in question, but can be more severe depending on the circumstances.

Academic Policies

Deadlines for Adding, Dropping and Withdrawing from Courses

Students may add a course up to one week after the start of the term for that particular course. Students may drop courses according to the drop deadlines outlined in the EP academic calendar (https://ep.jhu.edu/student-services/academic-calendar/). Between the 6th week of the class and prior to the final withdrawal deadline, a student may withdraw from a course with a W on their academic record. A record of the course will remain on the academic record with a W appearing in the grade column to indicate that the student registered and withdrew from the course.

Academic Misconduct Policy

All students are required to read, know, and comply with the Johns Hopkins University Krieger School of Arts and Sciences (KSAS) / Whiting School of Engineering (WSE) Procedures for Handling Allegations of Misconduct by Full-Time and Part-Time Graduate Students. This policy prohibits academic misconduct, including but not limited to the following: cheating or facilitating cheating; plagiarism; reuse of assignments; unauthorized collaboration; alteration of graded assignments; and unfair competition. Course materials (old assignments, texts, or examinations, etc.) should not be shared unless authorized by the course instructor. Any questions related to this policy should be directed to EP’s academic integrity officer at ep-academic-integrity@jhu.edu.

Students with Disabilities - Accommodations and Accessibility

Johns Hopkins University is committed to providing welcoming, equitable, and accessible educational experiences for all students. If disability accommodations are needed for this course, students should request accommodations through Student Disability Services (SDS) as early as possible to provide time for effective communication and arrangements.  For further information about this process, please refer to the SDS Website.

Student Conduct Code

The fundamental purpose of the JHU regulation of student conduct is to promote and to protect the health, safety, welfare, property, and rights of all members of the University community as well as to promote the orderly operation of the University and to safeguard its property and facilities. As members of the University community, students accept certain responsibilities which support the educational mission and create an environment in which all students are afforded the same opportunity to succeed academically.  For a full description of the code please visit the following website: https://studentaffairs.jhu.edu/policies-guidelines/student-code/

Classroom Climate

JHU is committed to creating a classroom environment that values the diversity of experiences and perspectives that all students bring. Everyone has the right to be treated with dignity and respect. Fostering an inclusive climate is important. Research and experience show that students who interact with peers who are different from themselves learn new things and experience tangible educational outcomes. At no time in this learning process should someone be singled out or treated unequally on the basis of any seen or unseen part of their identity.    If you have concerns in this course about harassment, discrimination, or any unequal treatment, or if you seek accommodations or resources, please reach out to the course instructor directly. Reporting will never impact your course grade. You may also share concerns with your program chair, the Assistant Dean for Diversity and Inclusion, or the Office of Institutional Equity. In handling reports, people will protect your privacy as much as possible, but faculty and staff are required to officially report information for some cases (e.g. sexual harassment).

Course Auditing

When a student enrolls in an EP course with “audit” status, the student must reach an understanding with the instructor as to what is required to earn the “audit.” If the student does not meet those expectations, the instructor must notify the EP Registration Team [EP-Registration@exchange.johnshopkins.edu] in order for the student to be retroactively dropped or withdrawn from the course (depending on when the "audit" was requested and in accordance with EP registration deadlines). All lecture content will remain accessible to auditing students, but access to all other course material is left to the discretion of the instructor.