After having all of the logistics completed, I was able to get back to Android development. I am still working on the sqlite database implementation in Field Day. After some research, I determined that the best method for implementing a thread is by the use of Handler and Runnable objects. Before implementing this method, the Field Day was writing to the sqlite database too often causing the primary keys I’ve chosen to fail. I implemented the UI option from Seshat of selecting how often the sensor values are logged. The Handler object basically just has the runnable ‘run’ every number of seconds that is chosen by the user. Inside the runnable function, the SensorSampleActivity goes to the interface for communication between the sensor Fragment and Activity to grab the list of sensors and adds appropriate metadata (geocode, accuracy, satellites, etc). and writes it to the database. I think it is working, but I still need to do some more testing. I have to get the database off the Nexus (not particularly easy) and examine the contents.
It’s been two weeks since my last post but you can probably figure that out by looking at the dates. Last week was Spring break so I didn’t do anything (except sleep a lot). The week before however, I did quite a bit. I finished booking the accommodations for the nights we are in the west fjords. I’m so glad that is over and done with. I was able to find two Airbnb’s for a reasonable price in the west. They are roughly in two of the areas where we are probably going to be spending a decent amount of time. All of our accommodations are through Airbnb, turns out. I’ve never used Airbnb before but it seems to be pretty straight forward.
After many painful hours of Google (I probably went through at least 7 pages of ‘Iceland car rental’ multiple times), I figured out the best option for our transportation. My first thought was to get a 7-seater SUV because we don’t have as much luggage and some of the options are cheaper than getting a 9-seater vehicle. After calculating our payload, roughly 1500 pounds, and looking at the specs of some of the SUVs we were considering, Charlie and I determined that none of the SUVs would be able to hold all of that weight. I was in correspondence with some of the car companies to figure out year of the vehicles to get exact payload and still none of them would work. I ended up going with the cheapest 9-seater I could find — a 2014 Renault Trafic Mini-bus from goiceland.com.
Now all we need to do is book our flights. I’ve done a little research in that area too and we really need to book soon. The flights are just getting more expensive as the days pass.
Our best option is this:
- one-way flight to a large airport (JFK or YYZ (Toronto))
- round-trip flight from large airport to KEF
- one-way flight back to airport near Richmond (DAY, CVG, IND) or MIA for those of us going to XSEDE
So far, I believe the cheapest option is Toronto.
After getting most of the logistics sorted out, I’ve finally been able to get back to working on Field Day. Not a whole lot has been done because I spent most of my time working on logistics but I was able to get a few things done or started. The first thing I did was get rid of the black background for the Sensor Sample activity. We don’t have to keep it this color I was just tired of the black. I made it green because it reminded me of grass and being in the field. The next thing I added was EditTexts for Site, Sector, and Spot like Seshat had. In the data model, we also added a ‘Trip’ column but I didn’t think that there needed to be an option for that on the main screen. I put in option in the Settings page since it’s going to be constant throughout the entire trip. In Seshat, we had an option to select how often the stream to the database. I added that in Field Day as a Radio Group with customized buttons from 1 – 60 seconds. I haven’t done anything with those values yet but the visual and backbone is in place. (You can see these edits in the two pictures below — Sensor Sample on the left and Settings on the right). Ignore the ‘Table name for readings database’ on the Settings page for the time being because I have figured that out yet.
Since my last post, I have successfully booked all of our accommodations up to Akureyri. In the South, there was one Airbnb that was directly in the middle of the two large places we want to go (Laki and Solheimjokull) and is also in the town Kirkjubaejarklaustur (a.k.a Klaustur) that is in the Island on Fire book and talks about the Reverend Jón Steingrímsson and the sermons, later to be called ‘the Fire Sermons’ that were given when the Laki volcano erupted. So, we decided that we would book that for the three nights we are in the south and then something else for the southeast. In the southeast, I found an Airbnb that is an old farm house on the coast with an organic farm. It looks really nice and from the description it looks like we’ll get to have quite a few interactions with the host. After that we are on our way to Skalanes where we already have accommodation. Akureyri was another Airbnb for three nights. I’m still working on where we are going to stay for the two nights in the West. I’ve found some Airbnb’s, I just have to confirm those with Charlie. It’s difficult to find places close enough that we don’t feel like we’re moving constantly, but close enough to attractions in the West that we won’t have to drive that far to see. I’ll have those figured out and booked this week. So far, we’ve stay significantly under budget! We had budgeted 60 per person/per night and with 7 people and 22 nights that comes to around $9240. Without the West booked, we are at $3613. Even if we were to use the 60 per person/ per night for the two nights in the west, we’d still only come out at $4453. This does not include Skalanes. We don’t know how much that is going to cost, but Oli is really hoping we won’t have to pay anything. We haven’t had confirmation on that yet, though.
Other logistics: I also booked our ferry to and from Heimaey, and we’ve figured out our car situation. We are going to get a 7 seater SUV and bring rope to strap down our luggage on the top. It’s more practical for some of the roads we travel on. We had some trouble in the highland roads wit the 9-seater on our last trip. This SUV is a 4×4 car and is suitable for the highlands. It’s also less expensive! I also started working on a map, just placing points that are our accommodations or places we’ll stop.
Most of the work I’ve done this week has been with the logistics aspect — calendars, flights, accommodations, etc. Charlie and I met on Monday to start working on the calendar for the months until our trip. We are trying to set dates for when we want specific projects completed — Field Day, soil sensors, flights booked. I can’t remember everything we talked about in that meeting (we wrote the calendar on the white board in hopper), but I’ll transfer that to the Drive calendars soon.
We decided that accommodations, flights and vehicles should all be done before spring break starts, but it turns out they need to be done now. I started working on booking our accommodations this week. I’ve booked the first two places and the last one. It turns out almost everywhere on the south coast is booked for the days we need, or they only have one room with one bed available. Starting for the next trips, we’ve put down that we need to book hostels as soon as we know the dates and the number of people. I’m still looking for a place on the south coast, but it’s looking like we’re going to have to stay in two different places. One place for the first two nights and another place in the southeast for the second two (most likely).
I haven’t done much in the last week, to be honest. It was kind of a crazy week for me so I had to focus on some Admin things. I’m still looking at the best method for threads in Android and thinking about the Notepad/Lab Notebook/Checklist aspect of Field Day and the best methods and classes to implement it. If there’s anything that could improve the Notepad from Seshat. That uses a Navigation Drawer but to my knowledge, that has been deprecated in the new APIs, so more research is to be done.
The past week I worked on making the classes that pertain to sensor sampling platforms more generic. Previously, I had been working on just getting them working using the Built-In sensor sampling fragment. The Built-In fragment uses the built in android sensors on the hardware device which uses the Android Sensor class. The aSensor class and other similar classes that we are going to use for all sensor platforms (Database reading and writing, sensor sample fragment frame, and the list adapter) were using Android Sensor class methods. I worked on getting rid of those methods and replacing them with more generic methods that can be used for all sensor sampling types.
I have also been researching the best method for creating a thread in android classes. The SQLite work I’ve been doing is almost finished except it’s writing to the database too quickly which is making my primary keys fail. I am looking for best practices for writing to a database in a thread. In Seshat (our old application), we had a feature where the user could select how often they wanted to write to the database (in seconds). I plan to move this feature to Field Day but I want to research the best approach. In Seshat, we used a runOnUiThread method. This may be the best approach but there are other options to consider — Service, AsyncTask, Handler, Runnable, etc.
After my last post, I decided to dive into our Gitlab setup and see if I could fix the problem. In case you’ve forgotten, the problem was the latest pushed code was broken. So, our master branch was pointing to code that was not working when pulled and deployed. The pushed code had changes to the gradle and build setup, not java code, so that’s why it was pretty broken. None of us know git all that well (but let’s be honest, who does?) so it has taken us a little while to remedy our setup.
I dove in and fixed it learning a lot about git in the process. I basically had to create a bunch of temporary branches with my current working code and rewrite history — basically making it look like the last changes had never happened. I set the origin/master branch to my working code with changes.
After this debacle, we decided that we should be using branches more often, keeping the origin/master branch for production, working, thoroughly tested code.
Since the beginning of the semester, I’ve been working on Field Day again and somewhat sorting out git. At the end of last semester, we were having trouble with git and we’re still trying to figure that out. We’ve decided that we’re all going to stick on the same Android Studio version and upgrade at times we decide as a group. Nic has the most updated version 1.5, so we’re all going to stick to that.
The latest code push was code that broke my Field Day setup, so all of the code I’ve been working on hasn’t been pushed yet. I’ve started a new branch of our git repo called SQLite work that I’ve been committing my changes to. As a result, I’ve been learning a lot of git and branching and I think this may be the way to do so we don’t end up with broken code in our ‘master’ branch.
The part of Field Day I’ve been working on is the SQLite database. Previously, we wrote all of our readings to a CSV file but that gets quite messy. So, in this new application we’ve decided to go to SQLite. I’ve written a class called ReadingsDatabase which is a SQLiteOpenHelper class. This is used to create, delete, upgrade, update, query, etc the database. I’ve also written an interface that will be used to communicate between the Sensor Fragment classes and the main activity. I’ve been using the ‘Built-In Sensors’ fragment to test because we haven’t created any of the other sensors to test yet. I believe it is working, but the problem I’m running into is the class is writing to the database too quickly which is causing the primary keys I’ve set up to fail. I’m looking into a way to slow down the writing to the database. Once we figure out the git problem, I’m going to push my code.
Only being here for half a week, I didn’t really get that much done. The little bit that I did do was not in the area of Android, but in the area of logistics, since I am part of that team.
I started to look into flights and what the best possible arrangement is. I’ve started a document, which you can find in Field Science -> Iceland 2016 -> Logistics, called Possible Flights where I’m keeping track of what I find. Each possible option is in the form of a table. The table documents the departing and arriving cities and times/dates and any layovers that will occur. So far, I have one arrangement in the document, and below I’ve documented my general findings.
Since many of us will head to XSEDE in Miami right after we leave Iceland, it’s not really optimal (as of the flights I’ve found right now) to buy a round trip to Iceland. That means we will have to buy a lot of one-way tickets, which is what we ended up doing two years ago. However, one-way tickets straight to Iceland from Dayton or Indy are extremely expensive — more than just a round trip ticket. I guess they don’t want you buying a one-way there. I suspect it’s partially because of the small size of those airports. One-ways from larger airports are much cheaper. That’s why I think we would buy a one-way ticket to a larger airport (say Toronto, for example), a round trip from that airport to Iceland, then a one-way to Miami, and another one way back to an airport close to us (Indy or Dayton for example, or Columbus).
I worked some with Charlie and Tara on figuring on Kanbanchi to use for keeping track of to-do things. It looks like a really nice and useful tool. We figured out the hierarchy of it in terms of our projects… refer to Tara’s post for more information on the exact hierarchy. I’ve started making one for Field Day and those tasks, which you should be able to find in the Field Science -> Software folder.
This coming week, I hope to finish the Field Day Kanbanchi to-do, work some more on Android, and talk to Charlie about who’s going to go to Iceland next summer. Though, I might not get as much as I’d like to done, since I have a lot of interviews to do with CS tenure-track candidates.