Programming Space

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:

• My First Mobile App
• Designing the Mobile App
• Building a Prototype

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.