Simon S

DISPLAYING POSTS BY: Simon S (11)

Simon S is the programmer behind the field guide app.

 

22 July, 2013 11:48 by Simon S

In the time between this post and the last post, a pair of African elephants could have conceived and given birth to a calf. She’d be a month or so old now, trailing behind her mother on the Savanna. I call her Kimba.

Although the blog has been quieter than a field devoid of crickets, we have been busy, as have some other people with the Field Guide code. Over the past 704 days

  • Simon O has jetted off to San Francisco to improve design in the US. We still miss him.
  • We proposed a more general framework for field guides called Genera.
  • We received funding from the Inspiring Australia project to work with museums around the country to produce field guides for each state and territory.
  • We produced the Bunurong Marine Park Field guide for both Android and iOS platform
  • We’ve updated the original Field Guide on iOS  and produced an Android version
  • We’ve moved from hosting the code at Google Code to GitHub, along with a number of other MV projects, and
  • We helped Goulburn Broken Catchment with their iSpy Frogs app

What happens from here? Well, the iOS Field Guide code on GitHub has been updated so that it works with iOS 6 and has a placeholder image for iPhone 5.  Github will be the place for all future updates.

For the Inspiring Australia project, we’ll be using the Genera code base rather than the Field Guide code base. Why have we done that? Well, the idea behind the Genera project is to produce a platform that can be used to produce guides that involve things other than animals. We wrote a paper about it and the code is also up on GitHub .

The other big news is that three independent developers have published three new apps, using our Field Guide code. They are:

So the field guide code is now being used in three countries – only 201 to go.  Personally, I’m looking forward to seeing a picture of Kimba when someone produces a field guide to Kenya.

Comments (4)

 

30 days hath September, April, mumble and November...

16 August, 2011 15:59 by Simon S

Here's a little known fact: There are actually 77 days in June. Seriously, who are you going to believe, me or some nursery rhyme? Is "hath" even a real word? Earlier in the year, I said that the source code for the field guide project would be released by the end of June. Well, today the source code for the field guide project is available to download. Welcome to the 77th of June.

The project is being hosted on Google Code, and has been released under an MIT license. This is a pretty broad license, allowing you to use the code as is, or mix and mash it to your hearts content. You can sell your app, or give it away for free. 

We’d just ask you to do a couple of things. First up, if you build an app using the source code let us know! If it’s published in the app store, send us a link. If it’s only an internal app, send us a description of how you’re using it and some screen shots. Releasing the source code is an experiment, and we want to build up a picture of how the source code is being used.

Secondly, we’d appreciate it if you mention that your app is built on the field guide project source in your app’s about page. Include a link to either the field guide home page at MV, or to the field guide project home page on Google Code and you’ll have our thanks. We’ve helpfully included an example in the default about page for the project.

Thirdly, let us know if there are bugs or if there’s better ways to do things in the code. This is my first Objective-C app, and no doubt there’s plenty of room for improvement in the construction of the code. Releasing the code like this feels a little like performing on the trapeze without a net, scary and exciting. Everyone who's watching can see if you make a mistake. On the other hand, the more people that are watching, the more likely it is that someone will catch you if you fall.

So what happens next? Well, you may notice that we’ve called this version 0.9. That’s just to give us room to tweak the code and fix any issues based on your feedback. We won’t be adding any new features before we call it 1.0 though.

We’ve still got a couple of blog posts to come on how to customise design elements within the app, and no doubt there will be a couple of posts based on questions and feedback about the code. There’s also a post coming up for those of you who’d like to produce a field guide that’s not about animals.

So grab the code, make cool stuff and enjoy this last day of June. :-) 

 

Comments (4)

 

Presto, chango

16 August, 2011 12:57 by Simon S

In my last post I described how to build the file that contains the initial load data for your field guide. At the same time, I sent the code off to an external beta tester. He came back with the question: How do I change the data once its been loaded by the app? When we were testing of the field guide, if we needed to change the data, I just reset the simulator or deleted the app from the testing device.

Not something you can really do once you've released your app to production.

So, with a couple of changes to code, we have two new properties. One in the animalData.plist file called versionID and another in CustomSettings.plist called currentDataVersion. The value of these two properties should always be identical. The first time the app is run on a device, the database is set up and the value for versonID is stored in the database. On subsequent start-ups, the app compares the value of versionID stored in the database against the value of currentDataVersion from CustomSettings.plist. If they're different, the app clears the database and reloads it from animalData.plist.

Why are we storing the same value in two different plist files? If you've got a lot of species in the app, the animalData file will contain a lot of information. It is overkill to parse this file every time the app starts just to find a short string. Since CustomSetting.plist is already loaded every time the app runs, it's the perfect place to put the check value.

Adding versionID as a property to animalData.plist has resulted in a change to the structure of that file. It was an array of arrays, like this

(

(array of taxon data),

(array of animal data),

)

The code determined the content by an element's position in the array. The file is now structured as a dictionary, like so:

{

taxonList=(array of taxon data);

animaldata=(array of animal data);

versionID = 1.0;

}

It's a small change, but it means that any future additions to the list will be easy to incorporate. Here's a new example animalData.plist file and a CustomSettings.plist file for your perusal.

Comments (1)

 

Getting your data out

9 August, 2011 16:02 by Simon S

Were going to take a break from the talk about design for this post, and talk about how you get your data into the app. All the animal data is stored in a property list file called animalData.plist (imaginative, I know). The first time the app is run on a device, it creates a database and loads all the data that file.

The file doesn't just contain the animal data, it also contains the information for the taxon menu. Since thats a bit simpler than the animal data, I'll start with that. Each taxon type has three properties: taxonName, highlightedImage and standardImage. A single taxon entry appears like this

{

highlightedImage = "animalActive_05_insects@2x.png";

standardImage = "animal_05_insects@2x.png";

taxonName = "Crawly Things with 6 legs";

}

Each line is a key value pair. On the first line, highlightedImage is the key, and animalActive_05_insects@2x.png is the value. Note that each line ends with a semi-colon (;).

The property standardImage is the filename of the image displayed next to the taxon name (in this case a grey silhouette of a winged insect). highlightedImage is the filename of the image displayed next to the taxon name when the row is selected. In this case, a white silhouette of a winged insect stands out better than the grey against the blue background.

Within the plist file, the taxon types for your app are contained in an array. So, if you only had invertebrates in your app, your taxon array would look something like this.

(

{

highlightedImage = "animalActive_05_insects@2x.png";

standardImage = "animal_05_insects@2x.png";

taxonName = "Crawly Things with 6 legs";

},

{

highlightedImage = "animalActive_03_freshInvertebrates@2x.png";

standardImage = "animal_03_freshInvertebrates@2x.png";

taxonName = "Freshwater Invertebrates";

},

{

highlightedImage = "animalActive_10_spiders@2x.png";

standardImage = "animal_10_spiders@2x.png";

taxonName = Spiders;

},

{

highlightedImage = "animalActive_11_terrestrialInvertebrates@2x.png";

standardImage = "animal_11_terrestrialInvertebrates@2x.png";

taxonName = "Terrestrial Invertebrates";

},

{

highlightedImage = "animalActive_08_marineInvertebrates@2x.png";

standardImage = "animal_08_marineInvertebrates@2x.png";

taxonName = "Marine Invertebrates";

},

)

The brackets ( and ) mark the start and end of the array. It's important to note that the order of the taxon entries in the document is irrelevant; they are listed alphabetically in the menu.

The data for each animal is also listed as key value pairs. The following properties are simple key value pairs (e.g. species = sapiens)

  • biology
  • species
  • genus
  • order
  • family
  • class
  • phylum
  • diet
  • distinctive
  • distribution
  • habitat
  • identifier
  • identifyingCharacteristics
  • lcs
  • ncs
  • wcs
  • nativeStatus
  • taxonGroup
  • taxonSubgroup

The remaining properties: commonNames, audioFiles, profileImages, mapImage and squareCropImage require a little more structure.

An animal can have many names, so the value for commonName is always an array, even if there's only one entry. The first entry in the commonName array becomes the display name of the animal. So for Turdus merula, the key value pair is

commonNames = (Common Blackbird, Eurasian Blackbird,);

and the name displayed in listings is Common Blackbird.

The audioFiles, profileImages, mapImage and squareCropImage are also arrays, even though youll only have one mapImage and one squareCropImage. Each file reference has two properties, filename and credit. You can leave out the caption in the file references for mapImage and squareCropImage.

profileImages = (

{

filename=image1.jpg;

caption=Great Photographer;

},

);

mapImage = (

{

filename=map1.jpg;

},

);

When you put it all together, you get a document like this. This has been a fairly technical post, if there's anything that needs clarification, let me know in the comments.

Comments (0)

 

Beta Testing

25 July, 2011 15:46 by Simon S

Just wanted to let the two of you that are following this blog that we've handed over the code for the open source code for the Field Guide to our beta tester. We are moving ever closer to the date that you can get your hands on the code.

Why are we beta testing? In getting the code ready to release, I've simplified the code in some areas but also added in a new setting or two. While I know you're a fan of Museum Victoria's particular shade of green, it's remotely possible that somebody with a less sophisticated palette may want to change the colour of the toolbars. A charming shade of mauve may be their choice, or perhaps honeysuckle, if they're up with this year's Pantone colour. The setting for this was buried in a class, but is now set in a configuration file.

Even if I hadnt tweaked the code, it's important to check that the whole thing isn't going to fall in a heap when you get the code and run it yourself.

At the risk of teaching you to suck eggs, after adding your own data to the code, you should put aside a block of time do some extensive testing of the app before releasing it to the public.

Before releasing our field guide, we checked the detail page of each animal, made sure the images were there, maps were appearing, that audio was working and there weren't any unexpected crashes (not that we had a list of expected crashes). I'm not going to lie to you, while the images and audio in the guide are beautiful, it can get a little tedious having to go through a couple of hundred in one sitting.

It's unlikely, but possible, that something in the data for one of your animals will interact strangely with the code. Better to find that out before you publish to the App Store.

Comments (4)

 

Developers, Developers, Developers

21 July, 2011 11:00 by Simon S

We've talked about data and images, and while theres still more to relate on that score, I want to jump ahead and talk about the something you'll need to do to pull it all together.

You're going to need register in the iOS developer program.

Don't panic, it doesnt mean that you're going to have to become familiar with the intricacies of Objective C and XCode, it just means that you, or your organisation, have to stump up US$99 and jump through the hoops of the registration process. The cost is the same whether you register as an individual or a company. 

Joining the iOS Developer Standard Company Program requires entering into a legal agreement on behalf of your organisation. If you can do that, great! If not, you need to involve a person in your organisation who can. This involvement is going to be an ongoing commitment for that individual. Every time Apple updates the developer agreement they will need to log into the developer portal and check the I agree box (after carefully reading the agreement of course).

Plan on the initial process of getting registered taking a couple of weeks. You need to send through documentation proving that your organisation is real, and that the person who says they can enter into legal agreements can actually enter into legal agreements, and so on.

If your eyes have glazed over at this point, I'll be honest with you. You (or your organisation) don't have to become a registered iOS developer. You can get someone else thats gone through the registration process to compile and publish your Field Guide to the App Store. However, there are a number of downsides to this approach: 

  • In the App Store, your external developer appears as the seller of the App
  • You wont be able to access App Store stats.
  • If its a paid app, Apple sends the cash to the developer. 
  • You will have to use the same developer to make updates to the App

 

The last point is pretty critical. If you part company with your external developer, your existing Field Guide becomes an orphan. You could partner with another developer to get it back into the App Store, but the App Store sees it as new app. Customers with the old app wont get any updates that you push to the new app.

Registering your organisation as a developer may seem painful, but it's going to save you from a lot of problems later on.

All of this does'nt mean that you have to have in-house developers to publish a Field Guide. An external developer can compile the code and send you the binary. Your development team agent then submits the binary to the App Store.

Easy J

 

Comments (0)

About this blog

We've released the source code for MV's Field Guide Project under a MIT style license. This blog will help you identify all the material you need to collect so that you can publish a field guide of your own.

MV's Open Sourced Code on Github

View all Museum Victoria's apps

Blog authors

Simon S is the programmer behind the field guide app.

Simon O is the designer behind the field guide app.