Final Project – Dive Log – huttereg
For my final project I implemented a log book for SCUBA divers. Since a log book is essentially a really big form, I figured that would be no sweat. I’d already done a form and underlying database for the second app. Turns out when your form has about 30 fields instead of two, things become more complicated. Well the layout is more complicated, the actual backend isn’t, just much more tedious.
The dive log starts with a list of entries. I think it was mentioned earlier that there’s a list header thing that could be done instead of the dummy item at the list beginner. Well that sounds all nice and good, but after reading for a bit i thought the three or so if tests and the dummy entry was the way to go, mostly since i wouldn’t need to spend anytime figuring that out.
The only think i hadn’t ever tired before was some image capturing work. After finally admitting that storing the images in the database was just to big of a pain ( and perhaps not a great idea anyway), I decided to just store the path to the images in the database.
For the actual image taking i figured i could just follow along with Dr Johnson’s code from the falling math one. The intent part, and the actual image capturing went fine, no problems there, but when i went to set the pictures as the source for the images view that would display them to the user i hit a snag. Not even an error, just a message in the log ( it was green, not sure what that means) saying something to the effect of “resolveUri failed”. Well ok, not terribly descriptive but i looked into it, i was setting the image source by Uri so it seemed reasonable. First stop, the Uri of the image; i don’t know a whole lot about Uri’s but it seemed ok. Next, maybe the image i got from the camera was bad. After taking the time to actually pull the image off the emulator, it was also ok. Alright, enough messing around time for google. So what i was trying to do was this:
// vrf_stamp_uri is a Uri object, which is the parameter type for this ImageView method
vrf_stamp_image.setImageURI(vfr_stamp_uri);
This is a very well documented way of setting an image view, except on android 2.1 it doesn’t work. For what ever reason, using a straight Uri object as a parameter mysteriously doesn’t work. So instead, i found a work around that should be semantically null, but for whatever reason isn’t:
// basically turning the Uri into it's string path, and reparsing it
// as a Uri. This should logically do nothing, oh well...
vrf_stamp_image.setImageURI(Uri.parse(vrf_stamp_uri.getPath()));
Well that’s really the interesting bit for the dive log, here’s what it looks like, first the list of entries ( which has a nice little entrance animation added):
And here is the first of five tabs in the dive log, most of them aren’t terribly interesting so one should suffice:
One real minor point to note is that the layout for each tab and the whole layout are in separate file, and make use of the really handy include block, which makes this editor make when i try to add it in. Also every field on the whole form has a listener on it to see if you’ve made any changes an remind you to save (though it does remind you to save if you open up an entry, don’t do anything and then close it, not sure why yet).
The second major part of the app was an electronic version of a SCUBA diving tool called a recreational dive planner. Basically what this is, in physical form, is a series of three related tables. These tables are generated from mathematical models that calculate the amount of nitrogen that is absorbed into the various type of bodily tissues, and well as the release of that nitrogen. This modeling for nitrogen (well any inert gas that the diver breaths at pressure, but mostly nitrogen) is important because if a lot of gas has been absorbed into the tissue, when the diver ascends into an environment with less pressure, the absorbed gas had the potential to bubble and destroy tissue, a condition know as decompression sickness, which can be fatal. So divers use the RDP to track this, and establish safe dive lengths at different depths.
So now that you know more about SCUBA diving than you ever wanted to, what actually have to be done to make this into an app. Well if you actually bothered reading the above paragraph, you probably assumed that these models are rather complex, and you would be correct. There were well beyond the scope of this little app, so instead i input the data of the physical RDP into text files; pretty tedious, but it was that or math.
From these file it was a pretty trivial matter to read them into a SQLite database, the it was a process that takes some time, at least on the emulator, so some care had to be taken to get it off the UI thread.
For interfaceing with the RDP there were initially going to be two way to use the data: a stand-alone calculator like interface that could perform the three main functions that the RDP is used for, and integration into the dive log, where certain fields could be automatically calculated in the user so desired. Well the log integration got cut, but there was still the calculator, so mission basically accomplished.
When a diver uses the physical RDP there is various parts where rounding need to be done, say the user wants 55 feet for a dive, but the table only has intervals of ten, so they would look at the data for 60 feet instead. By using the correct comparisons and careful sorting of the output, this wasn’t too difficult to do will select queries.
The interface for the RDP looks like this (the other two tabs are fairly similar, with the exception that each one has a spinner and an edit text, instead of two edit texts)
Well that’s pretty much everything, the only other things that got cut were the support of metric units through preferences, and a translation (and doing all of the references to the string resources i really wanted to try this out, but oh well)