Lecture 25 - Android Material Guidelines

Lecture Date: Friday, October 26

The current set of Android design principles is called "Material". It's an all-encompassing metaphor for how different elements should be displayed and interact on the screen.

First, we'll look at what "Material" actually is:

We will spend most of our time looking at the individual components and patterns provided by Google.

Such as:

How do we apply it to our apps? Using Material Design - https://developer.android.com/training/material/get-started.html

And also, how do we support themes for different versions of Android? Supporting Themes - https://developer.android.com/guide/topics/ui/themes.html

Slides - Android UI

more ...

Lecture 24 - Accessibility

Lecture Date: Wednesday, October 24

Touch screen devices have some inherent issues when we consider people that may have limited sight or ability to touch the screen. How do we assist those people? What do the manufacturers do?

The criteria we look at for mobile is very similar to that of other mediums (desktop, laptop, web) because these realms crossover a great deal now:

  • Web sites often have a responsive design that changes for a mobile screen
  • Laptops now have touch screens
  • Laptops can run mobile OS
  • Some mobile devices have external input devices

To consider accessibility, we examine it in terms of four main principles:

  • Perceivable - Information and user interface components must be presentable to users in ways they can perceive. This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses)
  • Operable - User interface components and navigation must be operable. This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform)
  • Understandable - Information and the operation of user interface must be understandable. This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding)
  • Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)

Perceivable

  • Screen size - Consider minimizing the amount of information on a screen. If you have a form or other input, position items vertically instead of horizontally.
  • Magnification - What will your app do if is zoomed it an the OS level? Can you reposition information? Make sure to use default OS settings for text sizes!
  • Contrast - Provide the capability to differentiate colors or ensure a proper contrast level.

Operable

  • Keyboard controls - Most mobile OSes allow for external keyboards, so make sure to allow for this as well. Don't do any extra on screen keyboards that are not OS related.
  • Touch target size and spacing - Space touch spots a reasonable distance apart. Specs recommend at least 9mm x 9mm touch targets.
  • Touch gestures - Allow for alternate mechanisms for touch gestures. Don't add in any excessively difficult gestures.
  • Button locations - Optimize for one hand, but consider both.

Understandable

  • Orientation support - Some devices may be mounted due to the inability to hold the device. Support both orientation layouts.
  • Consistent design - All of your pages should look the same / follow the same design layout with consistent font sizing, buttons, etc.
  • "Above the fold" - Place important items at the top of a page, before the user has to scroll to get to them.
  • Group elements that perform the same action - Keep all your controls together to make it easier for screen readers, etc.
  • Indicate actionable items - Provide clear indication what can be interacted with (i.e. coloration, icons, location, etc)

Robust

  • Virtual keyboard specialization - Always set a keyboard to the most logical layout for the data coming in.
  • Easy data entry - Use specific widgets for data entry instead of text when appropriate.
  • Follow platform guidelines - Apps should look and play nice together.

Let's design a new version of our previous example apps!

more ...

Lecture 23 - UI Design

Lecture Date: Monday, October 22

We'll take today to start talking about how to build good, usable apps. You're working with limited screen real estate, a unique input system, and a device that's nearly constantly in motion. That adds up to a headache for UX design.

Some links we will reference for the next few days:

Slides - UI Design

more ...


Lecture 21 - Sensor Ethics

Lecture Date: Wednesday, October 17

Smartphones are marvelous devices. They have the capability to connect us in ways we never though possible just a few years ago. But can we go too far? Can all the data collection capabilities actually hurt us?

Slides - Sensor Ethics

more ...

Lecture 22 - Midterm Exam

Lecture Date: Monday, October 15

Midterm Exam day!

You will need to bring a (fully-charged) laptop to class today. You will be taking taking the test in Collab.

The exam will consist of five questions. Each should be answered with a reasonable sized paragraph, fully touching on all aspects of the question. Bullet lists will receive no credit.

The questions will roughly cover the main aspects of these topic areas:

  • Basic mobile architecture / MVC
  • Android architecture
  • iOS architecture
  • Data Management (the four concepts of storing data and how they work)
  • REST (the five aspects and how they work)
  • Using Web Services

There is no coding on the test. All questions are conceptual around the design and construction of mobile apps.

Tips for taking tests in Collab:

  1. Open the test in Collab and copy the questions out of Collab and into the document editor of your choice (Word, text editor, Google doc, whatever).
  2. Answer all the questions first in your document editor, saving as you go.
  3. Copy the plain text of your answers into the question boxes in Collab one at a time when you are ready to submit.
  4. Submit the test and keep your back up just in case something happens.
more ...

Lecture 19 - Authentication


Lecture 18 - REST Frameworks and Services

Lecture Date: Wednesday, October 10

A web application that is RESTful:

  • Is bookmarkable (in general)
  • Has "good looking" URLs
  • Has a good data model behind it
  • Often has a good external API
  • Fully takes advantage of the Internet's asynchronous nature

Check out the Postman tool for connecting to RESTful APIs.

Postman - https://www.getpostman.com/postman

Imagine a software system made up only of various web applications, linked together through various RESTful calls. Crazy, you say?! Of course not! That's a service-oriented architecture!

UVA does this! Check out http://devhub.virginia.edu/.

Slides - REST

Slides - SOA

Flight REST PHP Framework - http://flightphp.com/

CakePHP PHP Framework - http://cakephp.org

Node.js JavaScript Framework - https://nodejs.org/en/

Firebase Cloud DB Service - https://firebase.google.com/

Amazon AWS Mobile Hub - https://aws.amazon.com/mobile/

more ...

Lecture 17 - REST Activity

Lecture Date: Friday, October 5

Prof. Sherriff is out of town today, so here is what you'll work on today (and next week, if needed):

  1. Pick your platform: iOS or Android. (Ideally, you'll choose the platform you're planning on using for the final project.)
  2. Sign up for an API key to use UVA's building info REST web service here: https://devhub.virginia.edu/API
  3. On your platform of choice, build a VERY simple app that will allow a user to make a basic request to the buildings API to look up info about a building at UVA. You do NOT have to provide an interface for EVERY option in the API, but you are welcome to expand upon the basic request outlined here.
  4. The app should have an EditText / UITextField that allows a user to type in the building name and a button that initiates the search. The info should be displayed in the app somehow (i.e. not to the console through Log.d or print()), but it's up to you how you want to do this.
  5. Your app does not have to be fancy in any way, but please make it "neat and clean..." I would prefer not to grade sloppy looking apps.
  6. Accept this GitHub Classroom assignment and make sure your final version is pushed by class time on Friday, October 12: https://classroom.github.com/a/ZqUvPkKL
  7. Note that this is an individual assignment.

Android

I highly suggest using Retrofit (https://square.github.io/retrofit/) to make your calls. Using native Java is pretty painful in my experience. There are other libraries that do this, but Retrofit is the one I see used the most.

Check out their GitHub repo for some samples (https://github.com/square/retrofit) along with whatever else you can Google. Note that to add Retrofit to your build path, you'll need to add implementation 'com.squareup.retrofit2:retrofit:2.4.0' to your Gradle build file along with the other implementation lines.

iOS

I would suggest just using the built-in Swift libraries, as they are relatively straightforward, but you can use other libraries if you like. Chapter 5.5 in the Swift book outlines exactly how to do this. This Xcode Playground shows you how you could make a JSON REST call against iTunes - the concept is the same: http://cs4720.cs.virginia.edu/resources/iTunesSearch.playground

more ...

Lecture 16 - REST

Lecture Date: Wednesday, October 3

Today we're going to start discussing REST - Representation State Transfer - a software architectural style for distributed hypermedia systems, such as the web.

The main principles of REST are the following:

  • Stateless Client/Server Protocol: Each message contains all the information needed by a receiver to understand and/or process it. This constraint attempts to "keep things simple" and avoid needless complexity.
  • Idempotency: you get the same result from the same action
  • A set of uniquely addressable resources enabled by a universal syntax for resource identification; "Everything is a Resource" in a RESTful system
  • A set of well-defined operations that can be applied to all resources; In the context of HTTP, the primary methods are POST, GET, PUT, and DELETE, similar (but not exactly) to the database world's notion of CRUD (Create, Read, Update, Delete).
  • The use of hypermedia both for application information and state transitions. Resources are typically stored in a structured data format that supports hypermedia links, such as HTML or XML

Let's look at how SIS works - it's command based. You do a command and the system responds. The system is built around verbs. In a RESTful system, the design emphasis is around nouns and resources - what their representation is and how they are affected by the standard methods. In REST, we assume four basic operations - Retrieve, Remove, Create, Update. Very much like Get, Delete, Post, and Put from HTTP and Select, Insert, Update, Delete from SQL.

For example, you could create an XML or JSON representation of an object that is then retrieved and modified by clients via the standard methods. Using HTTP commands, the XML or JSON could be retrieved with GET, modified, PUT back on the server.

A web application that is RESTful:

  • Is bookmarkable (in general)
  • Has "good looking" URLs
  • Has a good data model behind it
  • Often has a good external API
  • Fully takes advantage of the Internet's asynchronous nature

We will first look at more examples on RESTful websites that you have found. Check out the Postman tool for connecting to RESTful APIs.

Postman - https://www.getpostman.com/postman

Imagine a software system made up only of various web applications, linked together through various RESTful calls. Crazy, you say?! Of course not! That's a service-oriented architecture!

UVA does this! Check out http://devhub.virginia.edu/.

Slides - REST

Slides - SOA

more ...