Day 11

Day 11 will be mobile development, day 12 will be online advertising with Dan Armendariz, and day 13 will be about choosing a technology stack, with Patrick Schmid.

First, a short video (embedded in the lecture video) featuring Tommy, a former CS50 TF who now works at Quora. Quora is a question-and-answer website where a community of experts contribute responses and build knowledge. Tommy focuses on mobile development, with the goal of allowing people to easily use all the features of the website from their phones.

An article titled "D-Link says sorry for shoddy security and sloppy patching of its routers" was sent in, illustrating the importance of checking users' inputs before executing them as commands.

"Can you spend a few minutes going more high level again? Website server vs data server. Physically do they look different? Or is one virtual? More of the differences. Computing services vs storage services (seems like computing does both)."

What is Docker and why is it being embraced at such a rapid clip?

Could you explain how Heroku and its add-ons are used? How would you incorporate and pay for an add-on? What makes Heroku easier than AWS?

From the class discussions and my online explorations, I am still not sure that I understand the difference between Redis and PostgreSQL. They both are cloud storage servers for databases that allow for horizontal and vertical scaling. Is the difference largely that Redis is used for enterprise applications, but PostgreSQL is for "hobby" apps? Thanks!

On day 9, Professor Malan talked a little bit about oAuth. Many tools for apps require oAuth functionality like Facebook connect. How does oAuth work? What are the security vulnerabilities? What was the difference between oAuth and oAuth 2?

It seems Facebook’s React Native language looks promising and is relevant to our discussions. Could you perhaps discuss this in class? http://techcrunch.com/2015/04/20/howfacebooks-react-native-will-change-mobile-apps/

The market share of mobile operating systems look something like this these days:

Of the people in the class, the vast majority have iPhones, so the ratio definitely changes based on demographics and geography.

The "Other" category includes Windows Phones, Blackberries, and other smaller vendors.

The takeaway, though, is that generally mobile developers have to either exclude some part of their target audience, do twice as much work to develop for both Android and iOS platforms, or write an application that works on both platforms, but not optimized for either.

A native application is a program that’s on the App Store (or Play Store) that users can download and install on their device locally.

For iOS, the languages that these apps must use are either Objective-C or Swift.

Apple provides an IDE called XCode for devleopers to use, to create apps for iOS and OSX:

iOS development also involves something called storyboards:

David does a quick demo of XCode, where he first creates an app called hello:

The app has an initially blank storyboard, but we can drag over, say, a switch:

We can also drag over a label and type some text in:

XCode also comes with a simulator, or a program that simulates an iPhone on your computer that runs the app you’re working on.

As for performance and battery issues, generally developers can optimize their applications with better algorithms or data structures, but at the same time rely on the operating system to make the most use out of the hardware. For example, Apple did not allow background apps in iOS until just a few years ago, since it would negatively affect speed and battery life too much.

Stanford has a freely available iOS course taught online, with many resources for someone to teach themselves iOS development. Other online education providers have courses as well, but they generally charge for those options.

Android uses the Java language for native applications. The primary IDE for that is Eclipse, and developers also need the Android SDK, software development kit, which includes libraries, simulator, and other files.

There are some freely available tutorials from the official Android site, too.

The operating system version distribution for Android, however, looks like this:

There are lots of users with older operating systems, implying that their phones are also older and lacking certain features, or perhaps just slower.

Apple’s avoided this by having more forceful automatic updates, as well as controlling the hardware that can run iOS. But bugs in the update process mean that users might end up with bricked, or broken, phones. (In fact, this happened with iOS 9, a few months after this lecture.)

Dropbox, for example, sends out their app updates to a small percentage of their users at first, and wait a few days for any bug reports or issues before updating all users' apps.

And backwards compatibility, too, is an issue because not only are newer features unavailable in older software or hardware, older features previously available might be replaced or removed altogether.

Different screen sizes and resolutions, too, require app developers to be considerate and thoughtful about layout, if they want to support a wide range of devices.

So instead of writing native applications, companies can also adapt their websites to have a mobile layout:

But websites lack access to features such as location, photos/camera, and notifications.

The user also needs to have internet access in order to access anything in the app at all, and might also be frustrated if there is a lot of content to download while they are on a slower data connection.

Using CSS to adapt pre-existing websites for a mobile layout is pretty straightforward.

The final option, then, is the use of hybrid apps, where the application is written in HTML, CSS, and JavaScript, but installed onto the user’s device so as to have access to all the features it can.

Using HTML, CSS, and JavaScript as the language means that any smartphone will be supported, since they generally all have browsers.

Harvard, for example, uses a hybrid app:

All the main content inside is written with HTML and CSS, and only the buttons below are native, or in Objective-C.

Apps that look similar to this might be based on some framework or library that has pre-written code for those native features, with a menu bar at the top or bottom and essentially a web browser in the middle that displays most of the content of the app.

And access to features like the camera or location might be a simple JavaScript call that the content can use, with the help of those libraries.

Quora, too, has a hybrid app based on some framework:

The downside is that these apps are generally not as fast, since there is the additional layer of rendering HTML and CSS and running JavaScript on top of these frameworks that use the actual native languages.

The back-end of the mobile app doesn’t matter as much, because APIs can be standard HTTP requests or even provided as a service by companies like Parse. The decision for how to implement that, however, is separate from that of the front-end.

Some frameworks that developers might use in a hybrid app include:

These frameworks are essentially basic programs, written for each of the various mobile platforms, with blanks for developers to fill in and customize.

Tommy from Quora returns to talk about the tradeoffs they chose to make for this exact decision.

Given that Quora’s main product is a website that’s constantly changing as well as the fact that it’s a startup, it makes sense for them to choose a hybrid approach rather than writing native apps.

Day 12 will be about advertising, and Day 13 will be about choosing your entire technology stack. Until then!