Archives

I’ve been working through the design course at Hack Design. I’m about a month behind and decided to try to catch up a bit. I’m currently working through the whitespace lesson and stumbled across the answer to a vexing issue I’d noticed in some of the websites I’ve been working on. I’m a relative novice when it comes to CSS and so many of you out there may have already known the answer but it was news to me.

In this article on Scale & Rhythm, Iain Lamb talks about how he adds vertical space between the text and heading blocks on a page. In the article he points out that he adds padding to get the spacing desired. He then goes on to say:

At this point, you might be asking: “Why set subhead padding rather than margin?” The answer: vertical margin collapses between two block elements.

That little bit right there stuck with me. I had never known that and had never come across that little tidbit in my reading about CSS margins and padding. I had run into this problem of the vertical space collapsing and had never been able to figure out why. Now I know.

And just so I wouldn’t forget, I jumped over here and recorded it so I could find it later. Now I need to go back and finish the article.

One of the issues I had to deal with in building my mobile app was the evolving database schema as more features were added and the app grew. I needed a way to update the database scheme without blowing away the old one and forcing the app to redownload all the data. While I could have done that without any loss of data (there is no user supplied data to be lost), the main data set is over 8 MB in size and that isn’t nice to users’ wireless plans. What I needed was a way to incrementally change the schema as the app was updated.

First Attempt

My first attempts just used if() statements. i.e. if the current app version was one value and the new app version was a different value, apply this update. This worked well enough for my development versions where I was strictly controlling the upgrade versions. But I quickly realized that if I were to try to do that with versions of the app out in the wild, where I had no control over when it was updated, I’d quickly have a mess of conditionals to deal with. So I scrapped that idea and went looking for something new.

Final Solution

I don’t think this solution is new to me as I’m sure I saw it somewhere to give me the idea but I couldn’t tell you where I saw it off the top of my head. The answer was a switch() statement, with each case() block having a bit of the upgrade path from old to new schemas. In order for this to work, you need to track a version number for the database schema that increases each time you make a change. Simply start at one and every time you change the schema increment the value. This value, which I called current_version, is simply a coded variable.

Additionally, the app needs a second value that it stores as part of the application data which contains the database version that is currently installed (installed_version). Then, each time the application is run, you check these values. There are three possibilities[1]:

There is no stored value for installed_version. This should only be true the very first time the application is run. In this case, you simply need to create the entire database schema as it now stands and store the current_version as the installed_version.

The current_version equals the installed_version. This is the simplest case of all. Since the database schema is all up-to- date you don’t have to do anything. Continue on to the main part of the application.

The current_version is greater than the installed_version. In this case there is work to do and we now need to do the update.

To make the update we simply enter a switch() statement based on the installed_version. Each case() block should have arguments that start at 1 and increase by one each time. The first case() block (i.e. case 1:) would hold the commands that were necessary to upgrade from version 1 to version 2. The second would hold the commands modify the schema from version 2 to version 3, and so forth.

None of the case statements should have the break command associated with them so that after execution they would fall through to the next one and cascade all the way to the end. That way if a user skips one or more app updates that include database upgrades, each one will be applied in turn and none will be skipped.

Finally, the default() block at the end of the switch statement should contain the code up update the value of the stored installed_version so that it is also up-to-date for the next time the application is run.

Here is a bit of sample code that shows how this works. It is lifted in modified (with additional comments added) from my application which is written in using Titanium Studio’s Mobile SDK. It should be noted that the c object is a configuration object that holds a lot of information such as the database name, the table names, and column names among other things.

// Check that we have a stored value for the installed database version
if(!Ti.App.Properties.hasProperty('installed_db_version')){
// if not, the database has never been created
createDB();
} else {
var installed_version = Ti.App.Properties.getInt('installed_db_version');
if (c.current_version > installed_version){
Ti.API.info("Performing an upgrade from database version "+old_version+" to version "+c.version);
var db = Ti.Database.open(c.name);
// We need to do an upgrade to the new version based on the old version.
// We'll do this incrementally adding in all the changes since the installed
// version was created.
switch(installed_version) {
case 1:
db.execute("REPLACE INTO daily_data (source,start,duration,flux_1000_300000,error_1000_300000,ul_1000_300000," +
"flux_300_1000,error_300_1000,ul_300_1000,flux_100_300000,error_100_300000,ul_100_300000,test_statistic)" +
"VALUES (1,56000,86400,10,1,0,9,2,0,1,0.5,0,32)");
db.execute("REPLACE INTO daily_data (source,start,duration,flux_1000_300000,error_1000_300000,ul_1000_300000," +
"flux_300_1000,error_300_1000,ul_300_1000,flux_100_300000,error_100_300000,ul_100_300000,test_statistic)" +
"VALUES (1,57000,86400,12,2,0,10,1.5,0,2,0.5,1,32)");
case 2:
db.execute("DELETE FROM " + c.T_DAILY);
db.execute("DELETE FROM " + c.T_WEEKLY);
Ti.App.Properties.setString('last_lc_data_update','0');
case 3:
db.execute(DATABASE_CREATE_GCN);
Ti.App.Properties.setString('last_GCNNotice_date', '0');
case 4:
...
...
default:
Ti.App.Properties.setInt('installed_db_version',c.current_version);
break;
}
db.close();
}
}

In version 1, I was using some dummy data that I was setting explicitly. In version 2, I had updated the code to get the data from a web service so I needed to remove all the old data and add a stored variable to track the date of the last data point. In version 3, I added a table to the database and an internal stored variable to track the date that data was last updated.

At the beginning of the code block, I check to see if the database is installed at all. If not I call a createDB() function. This function simply contains the code that creates the current version of the database schema. Another option would be to just set the installed_version to 0 and have a case 0: block that creates the original database schema that all the modifications are applied to but I believe it is faster and cleaner to just create the current schema rather than run through all the old ones applying one updated at a time. While probably not an issue if you only have a few changes, as the number of modifications grow, so does the time involved in the creation of the new database.

And there you have it. A simple straightforward way to make sure that your database updates go smoothly across updates of your application code.

One final note is that you don’t have to call this each time the app runs, but only the first time the database is used. Now I suspect in most cases, the database is used every time the application is run but if there are sections of your app that don’t use the database, this check can be delayed until first use of the database. This allows the app to load up a bit faster, although the difference may not be noticeable.

[1] There is a fourth possibility and that is that current_version is less than installed_version. But if you’re properly incrementing current_version then this should never happen unless you roll back a distributed version of your application. If you do that, all bets are off and you’ll need to find another way to handle the update. Of course this is only a worry if the older code can’t work with the newer schema.

Let me say right from the beginning that I have nothing against OS X. In fact, there are many nice things about the operating system and it definitely looks nice. It’s just that I’ve been using some form of Linux (mostly RedHat and it’s derivatives) since 1997 and was using VAX and Solaris before that. That was for school and work. At home I run Linux and Windows. I’ve never owned a Macintosh computer although I’ve occasionally used one here and there through the years.

I knew when I started developing the mobile app, I would eventually find myself on a Mac for development work because of Apple’s restriction that iOS apps can only developed on OS X. And I knew there were going to be adjustments to be made. Here are the ones I ran into that caused me the most grief.

Focus follows mouse

The first was the lack of “focus follows mouse” behavior on OS X. I’ve spent the last 15 years with my windows set up so that when I move the mouse, the window it is over has focus and I can immediately start typing. Many times I’ll have multiple terminal windows open (sometimes with just a line or two showing) and slide the mouse from window to window and launch programs.

No longer having that as an option definitely caused me several false starts and a bunch of retyping. It wasn’t so much of an issue for the mobile development and that was mostly being done in a single IDE plus the emulators, but for my other Mac project, which involved a lot of building and compiling and running tools in the terminal windows, it was definitely causing a hassle.

I can understand completely why OS X doesn’t have this as an option. The windowing system design with the menu bar always at the top of the screen and not attached to the individual windows definitely makes the idea of focus follows mouse undesirable. It’s just something I’m used to that I miss on the Mac.

Command vs Control Key and Muscle Memory

I think of all the adjustments this one has caused me the most grief. My hands have been trained, over the past two decades, to know exactly where the Control Key is located for all my keyboard shortcuts and the spacing between that key and the other keys in the command. All of those same short cuts, on a Mac, use the command key which is one key over and which I still continue to miss for the first hour or two working on the Mac unless I make a conscious effort. Eventually, I remember that I’m on a Mac and hit the right key, but in the mean time, since my IDE responds differently to Control-C versus Command-C for example, I’m having to hit a lot of extra key strokes to recover form my mistake.

Middle Mouse Button ≠ Paste

This one I use extensively and it’s absence drives me batty. Instead of doing this:

highlight selection

move mouse to target window

click the middle button

I have to do the following:

highlight selection

Command- (not Control-) C to copy

move to the new window

click to activate the window (remember, no focus follows mouse)

Command- (again not Control-) V to paste.

In my Linux windowing environment, this works everywhere, no questions asked. In fact, I can’t think of a single place where I’ve not been able to use it.

On the Mac, it does work (sort of) in the terminal windows. But in the Titanium IDE it doesn’t work at all. Maybe it works in other places but I don’t use much else right now and where I do spend my time, it doesn’t work.

In the terminal windows, it works like on Linux but with one exception. When you middle click, it doesn’t count that as clicking to activate the window. A lot of times I’m pasting in a command and I then want to hit Enter and have it execute. On the Mac, the Enter key keystroke is captured by the window you copied from, not the one you just middle clicked in. You have to middle click and then left click to activate the window you just pasted to. Maybe Linux does the same with click to focus window behavior but with focus follows mouse enabled, the window I’m in is the active one so it’s not an issue.

Fuzzy Screen

I’ve seen flame wars and huge discussions on the font rendering engine on the Mac vs. Windows vs. Linux and I don’t intend to reignite those, but for me, the Mac screen is fuzzy. I should say that I’m using an external 24″ 1920×1200 monitor on the Mac (it’s an HP LA2405wg) and it is being driven by the Mac at it’s native resolution (the Mac is a MacBook with a 1440×900 LCD screen that is just way too small for a guy that uses dual 1920×1200 screens on all his other systems). I get used to it after a bit but whenever I have to be switching back and forth between systems, its definitely an irritant.

Slow Response

I don’t think this really has anything to do with the fact that the computer is a Mac, per se, other than the fact that the machine has an old Core 2 Duo processor where my other systems are a Intel i7 and an AMD Phenom which are both quad-core and much faster. I’m running Mountain Lion on a system that originally shipped with Leopard and I can feel it. Luckily, this is soon to be rectified and I’m getting a new MacBook in a month or two with a faster processor and more RAM.

The other area of slow response is when I do switch between systems. I have all my computers hooked up to a pair of monitors, keyboard, and mouse via a KVM switch. For some reason the Mac has issues with the switch. Many times it doesn’t connect the keyboard and mouse and sometimes just doesn’t grab the keyboard. It also doesn’t seem to respond very well to the video switch when the screen saver is on. Again, I think these are mainly issues of the old hardware and are only an issue when I switch to the Mac for the first time any given day.

Final Thoughts

Overall, the experience of working on the Mac has been fine. I don’t have adapters to do the dual screen setup like I do with my other computers (only one video out on the MacBook) but that typically isn’t an issue since my work on the Mac is fairly focused.

Would I ever switch to a Mac as my primary system? Probably not, although it’s not out of the question. If I was doing mobile development full time and had to target iOS, then I might just out of necessity. But while that’s only a side project, I think I’ll stick with what I’ve been using longer and am more familiar with.

I think the biggest thing I learned by starting to do development on the Mac is how ingrained some habits are and what I took for granted in my usual environment. It has helped me to realize what is core to my workflow and what is extras provided by the environment I’m working on.

Supporting your application on multiple operating systems requires some tough decisions. Do you develop natively for each OS and maintain multiple code bases? Do you use a cross platform development framework? Or do you do something else?

This is the fourth of several articles about my journey developing an application for NASA’s Fermi Gamma-ray Space Telescope mission. Earlier articles can be found here:

I knew from the start that in the end the application needed to run on both Android and iOS devices as both are widely used in the scientific community the app targeted. I chose Android for the prototype simply for practical reasons: I owned an Android phone and tablet but the only Apple devices in my house were my old MacBook from work and my daughter’s 4th gen iPod Nano, neither of which ran iOS. I didn’t have a device to test an iOS prototype on.

I originally toyed with the idea of just doing two different apps, one in Java and the other in Objective C to target the two platforms. Of course that would require learning Objective C as I had (and still have) zero experience with that language. More appealing would be to find some cross platform development framework that would allow me to target both platforms simultaneously. And so I started looking around.

I new the app was going to be fairly basic, it would make plots, have some lists and buttons and serve up webpages and data tables. So the cross platform environment didn’t need to be that spectacular. I looked at several. Many of the cross platform systems seemed to be focused on game development (or at least their sales pitches on their websites were). Others were a little too pricey.

In the end, I settled on Titanium Studio from Appcelerator. It allowed development for Android and iOS, code was written in JavaScript (which I had some familiarity with), and it was free. Using this tool, I would be able to write a single program that would compile down to native code on both platforms, and it would look and behave similarly on both.

Switching Development Environments

Up to this point all my work had been done in my primary work environment, namely Linux and the Eclipse IDE. Titanium uses a customized version of Eclipse for their IDE so that wasn’t an issue, but in order to develop for iOS you have to build and compile on a Mac. If there is one thing I don’t like about writing iOS apps, it’s that you have to do it on the Mac. I understand why, but it is still frustrating.

Unfortunately for me, my MacBook is pretty old. And I definitely felt it. The iOS simulator was snappy enough but the Android Emulator was painfully slow. In fact, in the end, it was faster (by nearly an order of magnitude) to deploy test versions to my phone (A Motorola Droid X) and test there instead of trying to use the emulator. There were times I could definitely relate to this XKCD comic.

There were other issues with working on the Mac, but I’ll save those for another post. Beyond the slow computer and minor interface dissimilarities, the switch was relatively painless and worked just fine.

One Code Base?

One of the draws of working in Titanium Studio was the promise of being able to develop in a single code base for both mobile OSes. I knew that there would have to be some OS specific coding in the app to deal with different features (i.e. no hardware back or menu buttons in iOS) but at least it would all be in the same language.

This aspect of the development turned out pretty much as advertised. I have a single set of classes/files that work just fine on both iOS and Android. I don’t have to worry about implementing a feature for one OS and then going and reimplementing it for the other. I just have to do it once and it is there for both. I believe that this definitely cut down on the total development time it would have taken to build it as two separate apps.

In addition, it saved having to deal with context switches. I was working in JavaScript with the Titanium APIs. While developing I didn’t have to switch out of that mode. Had I tried to do native Java and Objective C applications, I would have been constantly switching between the Java/Android APIs and the Objective C/iOS APIs. That’s a lot more you have to keep straight in you head and many more chances for errors. I think of all the benefits, being able to work in a single context and not having to continually switch is probably one of the best benefits of the cross platform framework.

Does that outweigh the issues encountered? That remains to be seen. From the point of view of the programmer, I think so. From the point of view of the functionality provided and the user experience, I haven’t decided yet. There were several gotchas that I had to deal with where something would work on one OS and not the other that I had to work around but for the most part these were minor. And there was one major issue that I encountered that I had to work around. But those issues will be the topic of a future post.

Conclusions

Looking back, maybe Titanium wasn’t necessarily the best choice of a cross-development framework. It’s been a rocky road that I’ll detail in a future post and give my reasons for that assessment.

However, the decision to use a cross platform development framework was, I believe, a good one. It kept all the code in a single place. I didn’t have to worry about implementing a feature in Java and then making sure I remembered to go and reimplement it in Objective C or vice versa, I could implement it once and it would be there. I think it definitely cut down on the development time, if not the testing time.

So, if you want to target both iOS and Android and possibly others, I think it is definitely worth the effort to look at the existing cross platform development frameworks. Look closely at the features that you need and what they provide. And pick a framework that provides what you need/want. It could save you a lot of work.

As I mentioned in my last post, I like making maps. Primarily I’ve done starship deck plans. You can find examples of several I’ve done for the TSSS Dart, CSS Nightwind, TSSS Morning Glory online (I need to get that last one into the wiki as my website layout has changed and the pages are all messed up now). As such I get asked occasionally by members of the gaming circles I inhabit for tips on getting started on map making. Since it has come up more than once, I thought I’d compile my tips and suggestions here to save having to rewriting the information individually to each new query. Now I can just point them to my blog.

My maps are fairly simple. As such I have never used any big mapping software. I just do my mapping in Inkscape, a free vector graphics program similar to Adobe Illustrator (which I have the CS3 version of but never have learned to use). The following tips were generated in response to a request for help I got a few months ago and were designed to get someone completely new to the program started on some basic maps. Hopefully they help you as well.

Tip 1: Open the File->Document Properties dialog and set the size of the paper to be big enough to hold your map at the scale of 50 pixels per grid square with 50 extra pixels on each side. I use 50 pixels per meter for all my maps so that if you print them out you can use the [Star Frontiers] counters (which are 1/2″ squares) on them. For example if I was doing a map that was a 10m diameter ship I’d make the image 10m x 50px/m = 500 pixels + 100 pixel border = 600×600 pixels in size.

Tip 2: In that same dialog, select the ‘Grids’ tab and create a new rectangular grid. Your tools and such will snap to this grid and make lining things up much easier. Note that this grid is only for use in inkscape to assist in drawing. If you want an actual grid in the final image, you have to draw that yourself on a separate layer. The sad thing is I’ve never figured out a way to automate that and so have had to draw all the lines and then copy and paste.

Tip 3: Use layers. I usually use at least one for the underlying grid, one for the map itself and one for the labels). That way you can turn things on and off as needed. You might even consider doing one for the walls and bulk equipment and another for the furnishings. Turn on the layers dialog (that will show the layers and allow you to manipulate them) by selecting Layer->Layers… in the menu.

Tip 4: In the bottom right of the program window is the information about your cursor position. You can use this to line up things and put them right where you want them. If you’ve got the grid on (and snap to grid on which is enabled by default), you’ll see a little red box or ‘X’ show up on the nearest grid point to your cursor.

Tip 5: Pressing the 5 button zooms to the page. Pressing the 3 button zooms to the object you’ve selected and pressing 1 zooms to 100%. Pressing + and – zoom you in and out. You can see the shortcuts if you pick View->Zoom from the menu.

Tip 6:(This one was prompted by a specific question) Drawing a circle. There are two ways to do this. The first is to draw from the upper left to the lower right. For example if you were drawing a big circle to be the outer hull of your 100m diameter ship, go the the upper left of the image 50 pixels in from the edges. Assuming you set up the page size based on tip #1 the cursor position in the bottom right should read X:50, Y: 5050. Click and hold the button down as you drag down to the bottom right and stop at X:5050, Y: 50, release the button and you’ll have your circle.

Now if you have the grid turned on (File->Document Properties, Grid tab, New button) you don’t have to get exactly on those coordinates as it will ‘snap’ to the nearest grid point.

The other way to do it is center outward. Go to the center of where you want the circle and click and start to drag to the lower right. Then press and hold the shift key while you’re dragging. This will move the center of the circle to your first click point and you just drag it out the size you want it.

Along the bottom in the status bar you’ll seed something that looks like Ellipse: 100.00px x 100.00 px (with the values showing you how big in x and y your object is).

Now for the pro tip on making circles. If you also press the control key while you’re dragging out your circle in either of the methods above, it constrains to ratio of the x and y sizes to be integer ratios. This means that as long as you go basically down or up diagonally, it will stay 1:1 and you get a perfect circle.

Tip 7: Changing line thickness. In the bottom left is a Fill: and Stroke: label with colored lines near it (just under the color bar). Next to the color line by the Stroke label is also a number. This is your line thickness. Right clicking on it will bring up a list of sizes that you can just click on to thicken or slim your line. If you don’t want one of the choices there you can get finer control. Double clicking on one of the color lines will open up a dialog with three tabs, Fill, Stroke Paint, and Stroke Style. The first entry in the stroke style tab is width. Adjusting this allows you to set the width of your lines to anything you want.

I also encouraged him (and you) to do a web search for “inkscape tutorials”. There are a lot of good tutorials out there to help you get going and solve particular problems you might run into. That was all my original inquirer needed from me to get started and he cranked out some pretty cool maps for a spaceship he was writing an adventure on. I hope those little bits help you get started. Feel free to post questions in the comments and I’ll try to address them. Happy mapping.

I like to make maps. Whether they are buildings, complexes, starship deck plans, or what not, I enjoy making them. I don’t know that I’m that great at it but it is fun.

To that end, I’ve been seeing a lot of mentions of “Five Minute Maps”. The idea is that you sit down, set a timer for five minutes and draw to see what you came up with. I decided to give it a go. In fact, I even joined The Friday Five Minute Map group on Google+. In any case, I did my first map today.

It was drawn in my mapping Moleskin with a 0.5mm pencil. It’s nothing great but I did do it in five minutes. It shows a large impact crater with central spire that has been mostly filled in with a shallow lake. Probably brackish as there is no outflow channel, just an inflow. The crater walls have been cut down at two points and a road/bridge has been built across the lake to the central spire which holds (the ruins of) a keep. The entire region around and in the crater is forested (it’s an old crater).

Beyond that you can fill in the details as you wish. The Friday Five Minute Map group has a theme/inspiration idea for each Friday’s map. These weeks was this image: https://plus.google.com/u/0/communities/107162032035058071166 of an old foliage covered, ruined tomb keep. Going with that image, the keep and bridge are overgrown with trees/vines and in a great state of disrepair and the area hasn’t been inhabited for centuries.

Of course that begs the back story of why build the keep there, a question that was asked on the Google+ group after I posted it. Off the top of my head, this was the answer I came up with (taken from my answer to the question):

Why did they build the castle there in the first place? Let’s see… It’s an impact crater with a central spire, several tens of miles across. Maybe there was some mystical properties of the material that was the impactor and which is now buried deep below the center of the crater. A wizard ferried slaves and overseers to the island via boat and began excavation trying to find the source of mystic energy emanating from the region. Realizing that this would be a good, isolated place to set up shop, both for magical research and controlling the power source, and that it may take some time to find the meteorite, masons were brought in to work the rock being excavated into a keep that would later become the tomb castle.

As work progressed, moving people and supplies by boat tens of miles across the lake was somewhat tedious and the bridge/road was constructed to ease logistics, again being constructed from material being quarried on the central isle. What later happened, whether the wizard found the meteor, and what happened to cause the keep to fall into disrepair is left as an exercise for the reader.

Someone else suggested that maybe it was built by a civilization that just didn’t want to go out of it’s way, The shortest path between two points was through the crater so off they went. That got me thinking of another, related reason for building the bridge, namely a short cut.

If the crater is large, and it probably is given that it has a central spire, going around could add tens to hundreds of miles to a journey. And maybe that was the way things were for centuries. But then someone decided that they had the engineering know-how to make a bridge across the lake and shorten the distance. They built the bridge, built a keep on the island in the middle, and then set up a toll booth on the island. The road across the crater cut out days or weeks of travel. And since the toll booth was on the island half way through, most people paid to continue on. You could refuse the pay the toll but then you had to backtrack all the way out and then around. It made a lot of money for the original constructor. And was probably the scene of many battles for control over the years.

Anyway, that was my first foray in the the 5 minute map. I look forward to doing more in the future.

Finally got around to getting the WordPress back end, plugins, and themes updated. The theme update changed the appearance slightly or maybe more than slightly. I still need to tweak it a bit but I think I like the new look.

If you are accessing via mobile devices, the theme change was dramatic. The mobile theme I was using got updated and started injecting ads into my site. I wasn’t happy with that so I removed it and went to a second theme I had selected back when I first set up the site. I’m not completely happy with that one (which is why I wasn’t using it) so I’m going to revisit the mobile theme in the near future.

I seem to have an infinite number of side projects that I’m always working on. Today, however, I just want to give a quick shout out to a couple of them that take up the majority of my time.

I like to play (what is now considered) “old school” pen-and-paper role-playing games. When I started down that hobby decades ago all the adjectives weren’t needed. You just said role-playing games and people knew what you were talking about. But today with the computer role-playing games as well other developments, you have to be more specific.

Specifically, I’m a big fan of the old TSR game Star Frontiers. So much so that I run a Star Frontiers website, The Star Frontiers Network, which primarily hosts gaming forums and a wiki, and I provide hosting for a second site on my server. You’ll find me hanging out there and on other Star Frontiers sites under my handle Terl Obar, the name of my first major Star Frontiers character.

Related to my love of that game, I let a good friend of mine from the on-line community, Tom Verreault (aka jedion357), talk me into working with him on starting up a science fiction fan magazine, devoted initially to Star Frontiers but with a focus on sci-fi RPGs in general. The magazine, called the Frontier Explorer, has now published two issues and we’re hard at work getting the third one ready to go. It’s been a lot of fun and a lot of work. You can expect to see posts about the magazine and my experiences working with it appearing here in the future.

The other activity that seems to consume the rest of my spare time when I’m not working or spending time with my family is my small publishing company, New Frontier Games. I haven’t done a lot with this as of yet but things are starting to pick up. I wrote a book last year (2011) called Discovery which published just as a free e-book. Just recently I’ve made a print on demand copy available for those that like to have physical copies of their books. The other thing I’ve been working on is a spaceship combat card game, Star Clash, which I just released as well. Right now it is available as a “print and play” game. However, the company we do our distribution through (DriveThruRPG and its related sites) is launching a print on demand card site that Star Clash is specifically suited for. I’m currently working on preparing the cards to be printed so that people can order the card game ready to play instead of having to print them themselves.

If any of those projects sound interesting, follow the links to check them out. I’ve had a lot of fun working on them. Hopefully you’ll enjoy them as well.

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

It took me about a week and a half to get the main application screen and get the basic plotting implemented. I know because a week and a half after I got back from the AAS meeting I was on the plane headed out to NASA Goddard. The trip was to help train a new staff member on our data server but I would also be pitching the mobile application to the project scientist.

One thing I was reminded of during that time is how effective and efficient you can be when you are really excited about what you are working on. I was really excited about this project and wanted to pursue it and so I found myself very focused and working hard to get this done. It’s amazing what you can accomplish when you don’t let yourself get distracted.

While at Goddard, I had a chance to show the prototype as it existed to the scientist who I had worked on the design with as well as the project scientist. Both of them liked what I had so far and the project scientist gave the green light for me to work on this officially and implement the full version.

I still had work to do on the prototype to fulfill it’s role as an exploratory tool for some of the techniques in building the app but it had fulfilled at least one of its main purposes as a demo tool. In the end, the functionality of the prototype was expanded some what to include other things like notifications, automatic data updates, and pulling live data from our servers. Especially in the latter case, it served as a test client to back end services that I needed to develop for the final applications but that that is the topic for another post. But all along the way it was a tool to help me learn what was possible, what wasn’t, and how to implement those things. And in the end, that was really its primary purpose which it fulfilled admirably.

The idea for the application came about due to a request we had from a couple of scientists at the American Astronomical Society meeting in January 2011. They asked if we had a mobile application that would allow easy access to some of the public data that we were already releasing on the mission website but which would be nice to be able to quickly access on their phones.

At the time we didn’t have such an app or plans to create one so the answer we had to give was no. However, the requests started us thinking about what it would take to create such an application.

While at the meeting I sat down with one of the mission scientists and she and I went over what such an application should provide, both in terms of functionality and data. Over the course of a couple hours we worked out the initial design of the app. This was by no means a continuous process as we both were on duty staffing the mission booth and answering questions about the mission to those who stopped by and so were continuously being distracted from the design process to talk with others about the Fermi mission.

However, out of that process came a fairly straightforward design of what the application should do. In all, the final design was barely over one page of hand written (by me) notes that included the basic functionality of the the app, the various user interactions it should support, and basic sketched out screens for the various parts of the app.

The initial design we came up with in those few hours at the AAS meeting has served remarkably well to guide the development of the application through its initial release. Although I should say that the application is fairly simple. It is serving up basic plotting data and then a lot of textual data and as such didn’t need a complicated design. Even so, having the design provided good guidance throughout the later development process and kept me on track of what to do and what to leave out.

One of the best things you can do when designing any software, is sit down with potential users and find out how they expect the app to function. While I knew this already, the process of designing this application reminded me of that truth. Working with the scientist on the design was very helpful. While I have a Ph.D. in Astronomy myself, we were working with data that I didn’t use and had no experience with. She was someone who would actually be using the application and the data it provided and so was invaluable in providing insight into how the app should behave and how the data should be presented.