As part of our X-SIG program, we we are working on education research and developing educational tools for future students. We split our efforts between finding the best ways to help people understand novel programming concepts, and building the most effective tools to implement those approaches. To explain, we’ll have to provide a little bit of background.
Background – Nathanael Epps and Jordan McShan
The homework assignments in CS111 courses involve making apps for Android, as it provides an intuitive entry point for students to familiarize themselves with the basics of programming. Working from the very beginning with the CS department’s custom-built graphics tools allows them to directly see how their code is working, and learn some of the common practices and expectations of programming languages in an unimposing context. In general, when you want to write an app for a given platform, you would normally use the provided Application Programming Interface, or API*. However, the Android API is large and complex, which is good for those who need fine-grained control over their app, but can be a hurdle to those new to programming. In the context of an intro-level computer science course, the focus of the homework should be less on learning the ins and outs of a particular software or programming language, and more focused on programming concepts. Focusing on concepts as opposed to focusing on any one specific language allows a student to pick up the skills necessary to learn any programming language or work with the latest software. So, to get around this issue, the CS department created their own API that uses the Android API but makes it substantially easier for the intro students (the hiding of details of operation and exposure of what’s essential is a concept called abstraction in computer science.) So, those who take the CS111 courses get the best of both worlds- they’re easily able to write apps for Android, and also able to focus on learning important concepts that will be applicable no matter the programming language or technology. Over the course of eight weeks, we have been focused on adding features and improving the code base.
Adding Features and General Improvements – Nathanael Epps
Over the last few weeks, my focus has been to learn about the Android API and learn the API of the department so I can add to and improve it. During the course of the first week, I familiarized myself with the Android API by writing a simple tic-tac-toe app, using the Android API and not the department’s code. Although I initially felt like I was banging my head against the wall trying to learn to use the monolithic code base that is the Android API, I eventually began making progress and was able to create an app that plays intelligently against the user. During the second week, I familiarized myself with the department’s API by doing some of the homework from CS 111. I was able to see firsthand why working with an easier-to-use API makes the lives of the students substantially easier. Also, I completed the XSig ethics course. During the third week, I started on new features. I added code that allowed students to play sequences of notes easily, and started working on some code that would allow students to read CSV data files from the internet. During the fourth week, I finished the CSV reading code, and started on code to allow students to use the camera from their apps. I also added a feature that would allow students to use location services of the device to get the phone’s location. During the fifth week, I continued camera usage code, and enabled bluetooth emulation and tested it with a two-player tic-tac-toe app. Also, I started looking at changing the build system. What’s a build system, you ask? Let me explain.
Certain programming languages, like Java, C, C++, and a lot of others, are said to be compiled, which (basically) means it has to be turned from the source code that people can read and write to the 1’s and 0’s that the computer can understand. If you have a Java program composed of multiple files, they have to all be compiled separately and then are bundled into a .jar file. This can be a painstaking process to do for each and every file of your project, so what a build system will do is let you write a script that tells the build system what to do, and then you can compile your whole project in a single command. While build systems differ, this is the general idea.
Currently, CS111 projects are built using a build system called Ant. I’m in the process of switching a project from using Ant to a newer, shinier build system called Gradle, which is the build system Google uses to build Android apps.
Porting the code to iOS – Jordan McShan
While Nate and I spent our first week and a half in much the same way, familiarizing ourselves first with the Android API and then with the the CS department’s one, our paths soon diverged. The college’s API was built exclusively for Android devices, and my goal was to expand that system to work with other operating systems like iOS. Apple, however, does not use Java as an accepted programming language on their devices, and that was the challenge.
I needed a way to take the code that students would write in one language, and translate it into another. The good news is that such a tool already exists, an impressively dynamic, capable system called Multi-OS Engine, or MOE. It allows developers to write code in Java, which MOE then converts to an Apple-accepted language when the program runs, allowing programmers to write for Apple devices without ever needing to see another language or the work happening behind the scenes.
What has made my work so interesting is that neither MOE’s creator nor anyone else has published significant documentation on how it works, leaving me in the curious position of reverse-engineering it. I find myself often looking for how to do things in the Apple language, Objective-C, so that I can probe MOE for something similar, and then experimenting with that to find how it works. Though the names in Objective-C are often similar to MOE’s Java tools, the ways one interacts with them are often radically different. It took nearly two days of researching, testing, and digging through old snippets of example code in order to display a circle on the screen of my iPhone. But oh, what a beautiful circle it was when at last it appeared. Finally cracking the code on how to display to the screen was equivalent to a dam being broken, and within a couple hours I had implemented all the rest of the CS API’s drawing tools.
After that, it has just been a matter of continuing to expand the iOS library, working in a strange twilight zone where my code is technically one language and conceptually another. I have since added all the functionality present in the Android version of the code, and have begun implementing brand-new features as well. This includes an ID system that allows students to interact with shapes they have drawn on the screen.
Most recently, I started writing a program that allows students to add images and audio to their program without needing to go through Apple’s user interface. As a long-time Windows user, I find myself continually baffled by design choices made at every layer of the Apple experience, but none more so than the fact that they designed their programming interface to require manually clicking and dragging things every time you want to show a different image. My program now circumvents that need. The largest piece of the puzzle remaining now is putting all of these different tools together and making them work as cleanly as possible. The program where the students write their code is not configured to build and run it by default, so we will need to modify it to create the right kind of project, manipulate the customized files as needed, and and hide all the complicated intermediate steps behind the scenes, allowing students to focus on the important parts.