Lecture 23 - Sensor Ethics

Lecture Date: Monday, October 16

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: Friday, October 13

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)
  • Web Services / Service Oriented Architecture

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 21 - Authentication

Lecture 20 - Web Service Connections

Lecture Date: Monday, October 9

We will start by finishing up the frameworks from last lecture before moving on.

Now that we know about service-oriented architectures and web services, how do we actually use them? And how do we know what we want to use?

Looking for some APIs to use? Google's your friend! You can also check some registries like PublicAPIs or ProgrammableWeb.


Here's a general tutorial from ssaurel.com - http://www.ssaurel.com/blog/learn-to-consume-a-rest-web-service-and-parse-json-result-in-android/

The basic steps go like this:

  1. Find/create the web service that you want to use. This could be many different things for your app. You might need an external database to keep up with what your users are doing. You may need a place to host images or audio. Find something that will add value / important features to your app and go with it!
  2. Make the HTTP call. Android has a built-in HTTP library that allows you to build an HTTP request and then parse the result.
  3. Parse the result. Once you get the result, you'll need to pull it into a data structure you can use. If the service is using XML or JSON, Android has built-in libraries for handling both!
  4. Implement the features. So, the catch to all this is that starting with a previous version of Android, it was made a requirement that all networking activity has to take place off of the main thread. This prevents the app from hanging while the user is using it. Thus, you'll need to create an AsynchronousTask and use that to spawn a thread that will do the call in the background for you.

Once you've done all that, you can then do what you want with the data - load it into a list for viewing, process it some other way, etc.

Sending data to a web service is very similar. The main difference is when you make the HTTP call, you'll have to make either a GET or POST command and then pass the appropriate variables you need to with the call.

Another option is to use a third-party library that will provide a wrapper around the REST service. If you go this route, you don't have to deal as much with the network functionality or parsing the JSON. Most wrappers will just hand back to you a Java object you can just use. Retrofit - http://square.github.io/retrofit/ is one good option.

Here are some Retrofit tutorials I used to make my Lou's List example:


The basic steps are effectively the same for iOS as Android, including running the call on a separate thread. The main difference is a change that occurred with iOS 9. In iOS 9, Apple added some network security features that require very particular HTTPS traffic. This makes it difficult to connect to... well... most anything. They apparently even had a session at their developer conference on how to get around it.

You'll need to make some changes to the Info.plist file to make it work. Information can be found in the links below.

Some tutorials you can look at:

Here's some code to pull down and parse the JSON:

override func viewDidLoad() {

    let config = URLSessionConfiguration.default // Session Configuration
    let session = URLSession(configuration: config) // Load configuration into Session
    let url = URL(string: "http://stardock.cs.virginia.edu/louslist/Courses/view/CS?json")!

    let task = session.dataTask(with: url, completionHandler: {
        (data, response, error) in

        if error != nil {
        } else {
            do {
                let json = try JSONSerialization.jsonObject(with: data!, options: .allowFragments)
                //Implement your logic


            } catch {
                print("error in JSONSerialization")

Want to be like the Android folks and use some cool frameworks and APIs?

First, learn what CocoaPods is - https://cocoapods.org/. CocoaPods is a package and dependency manager for Xcode (Mac, iOS, Swift, Obj-C). Built in Ruby, it allows you to quickly add components to an Xcode project. We used it as a part of the Core Skills app for Firebase, in fact.

Here are two to look at for doing REST:

more ...

Lecture 19 - REST Frameworks and Services

Lecture 18 - REST

Lecture Date: Wednesday, October 4

Reminder: Fill this out if you absolutely cannot take the midterm on Friday, October 13 - https://goo.gl/forms/gYdRRlsD3u7ai1Mv2

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 ...

Lecture 17 - REST

Lecture Date: Friday, September 29

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

Slides - REST

more ...