Building a prototype
Once you have an idea for an application, it really helps to get a prototype up and running to understand better how the application will function and even if it is possible. Building the mobile data application for the Fermi Science Support Center was no different.
This is the third of several articles about the journey of developing an application for the Fermi Gamma-ray Space Telescope mission. Earlier articles can be found here:
When I started this project my mobile app development experience comprised a sum total of about two weeks of playing around with the Android SDK. I had it up and installed, had read a few tutorials, and started in on a small app that was to be a character generator for an old role-playing game to have something (semi-)practical to work on. But beyond that I was a complete novice.
However, that was infinitely more experience than I had with iOS development and that fact, combined with the fact that I owned an Android smartphone (a Droid X) and the only Apple devices in my house were my daughter’s 3rd gen iPod Nano and a work MacBook that I used occasionally to test out builds of our science software, I decided to try the prototype as a native Android app written in Java.
Breaking New Ground
This was a completely uphill journey, although not necessarily a difficult or unpleasant one. First was the fact that I was working in Java. I’m primarily a C++/Perl programmer although I’m familiar with many other languages. I have a passing knowledge of Java but have never really used it for any real project. So working in Java required more than a bit of looking up syntax and functions.
Doing event driven, GUI programming wasn’t completely new to me. On of my side projects that I work on off-and-on is a computer version of the spaceship combat game from the old Star Frontiers role-playing game. This game is GUI based and so the concepts of responding asynchronously to input events isn’t new. In fact to a lesser scale, the main data server that I built for the mission does the same thing but the events are coming from sockets instead of a user interface.
And of course the entire Android development process was new. Screen layouts, the SDK, etc was virgin territory. I spent a lot of time looking at the developer documentation to figure things out and learn about the various classes, what they did and how they interacted.
What to Build in the Prototype
The next question was what the prototype should contain. The goal of the prototype was two-fold. First, I wanted it to demo the basic functionality of the application so I could show it to the project scientist to get approval to do the full application. And second, it was a way for me to explore a bit of how to do thing in the mobile space and how the whole mobile development paradigm worked.
In the end I decided to implement three major components:
- Plotting the light curves – This was to be the major functionality of the application to begin with so it made sense to try this out from the get go. It didn’t have to pull data from the web or perform updates, but it did need to plot regular data points with errors as well as upper limits and give source and data range selection options.
- Show the Fermi Sky Blog – I mainly did this one because it was easy as it was effectively just providing a link to the web page of the blog. This provided some experience in launching other tasks (Activities in Android parlance) that were external to the application I was writing. However, while everything I learned here could have been learned from implementing the ATels (#3 below) it did provided a little more functionality to have in the demo.
- Building and displaying the list of Fermi related Astronomer’s Telegrams – The main draw to implementing this one was that it provided some experience with reading an RSS feed and parsing the related XML. Both of which I’d never done before. It also provided some experience with the process of using the network interface to go out and get data.
Putting It All Together
Page 1 of 2 | Next page