Sending data back and forth
by on with No Comments

As you remember, last week I finished the new data model implementation within Field Day and downloading remote database data. Field Day writes sensor database to the local database respecting the new model — populating fieldday_streaming, fieldday_reading, and fieldday_spot.

The big hurdle that still needed to be hopped over was sending those newly populated tables back to the remote database. This week I got over that big hurdle. The user can now upload the local tables to the remote tables. Field Day gets all of the rows in the tables I mentioned above, starting with fieldday_spot because the other two have foreign keys that reference the spot table. Moving the rows from the reading and streaming table is simple, but moving the spot table has different characteristics. If people are pushing to the database at the same time, we have to make sure that we are only inserting one of each ‘trip, site, sector, and spot’ which make up the primary key in the database. Field Day takes the ‘tripID, siteID, sectorID, and spotID’ of each row in the local database and queries the remote database asking for the count where a line has those four columns that equal the values in the local table. If the count comes back zero, then Field Day inserts the row. Each tables updating is wrapped up in a transaction, so if something goes wrong Field Day rolls back the transaction and sets the database to it’s previous state. Once the inserting has successfully finished, the database in the local table is copied to external storage in an /archive directory and the tables are dropped and created again so they are empty.

I moved ‘Take a Sample’ on the main screen to ‘Sampling’ and created a new option under that menu for ‘Database Actions.’ The downloading from remote database activity was previously under the Settings option, but since the application is basically doing the same thing in each, I merged them in to one activity. There are three buttons for the user to choose from (which you can see in the picture below) — setup local database, upload tables, clear local database. Upon the press of any of the buttons, the user is asked to confirm.  When the user selects clear local database, just like after the user upload the tables, the local database is copies and wiped.

A couple other small things that I’ve worked on this week are integrating the Google Drive Android API and fixing small things with the sensor sampling activity. As for the Google Drive API, I’ve gotten Field Day to the point where it asks for permission to access Google Drive, but doesn’t do anything after that. To my knowledge, this API only allows the app to interact with files that were created by the application itself. I’m not 100% sure of that so I’m still working on it. Small things that are fixed are the user is notified if they haven’t set up their local database with a remote database, which means they can’t write anything to the local database. When a Spot number is put in the spot edit text on the sampling activity, Field Day checks to make sure that spotID doesn’t already exist in the local database if it does, then it doesn’t write to the database.

 

device-2016-05-19-094627

Lots of Android Fragments!
by on with No Comments

This past week I have done a lot with the Android application, Field Day. I’ve implemented the basic architecture that I think we are going to use.

It makes use of Android ‘Fragments’ class. Fragments were introduced to make it nicer when building UIs. Before Fragments (introduced in API 11), whenever a new screen on the Android device was shown, a new Activity was created. Even if only one thing on the page changed, you needed to create a new activity. That meant that there were many lifecycles that needed to be tracked and maintained. That’s drained the battery and made the code more complicated than it needed to be. The Activity lifecycle is complicated. With Fragments, you can easily swap out parts of a UI and still stay in the same lifecycle. The activity that created the fragment controls its lifecycle. There’s no extra ones that need to be maintained.

Right now, there are only about 3 activities, and 5 or 6 fragments. The main screen buttons, and when you click on ‘Take a Sample’ or ‘Lab Notebook’ are all fragments with one activity maintaining them. Once a specific sample type is clicked then the SensorSample.java activity is created. There are parts of the SensorSample activity that are going to be the same no matter what type of sample we are taking. That’s why those are also fragments. Code/UI elements that will be the same for all — Geocoordinate, for example — are on the SensorSample activity’s layout file, but there’s a FrameLayout in there that can be swapped out depending on the type of sample. It really helps with stopping the creation of repetitive code.

In the SensorSample activity, I’ve already implemented a LocationListener and Manager that will listen and update the user’s location. That will be used for the Geocoordinate. It doesn’t get written to the database yet, but I have implemented in both the code and UI so it shows up and does change. I tested it!

Time for a cup of Java
by on with No Comments

Week 2 began with copying and reading trough the old files for the $FIELDSCIENCE program. Once on my local machine I was able to load the program and begin to sift my way through the app’s source code. One challenge that I was made aware of is that the original code was written using Eclipse IDE and the current supported system is Android Studio IDE. Luckily, the book (The Big Nerd Ranch Guide to Android Programming) that I chose to learn from is written entirely for Eclipse IDE and I will be translating the learner’s programs to ones working within Android Studio (to quote Charlie “sometimes its like drinking from a fire hydrant”). With this being the case, I should have a firm grasp on the differences between the two IDE’s.

My time this week was spent learning through google searches and reading/attempting the programs within the book. Progress is going well and I am feeling fairly comfortable using Android Studio and the basics of java with the help of a cheatsheet for syntax. My goal in the next week is to have a firmer grasp on the program we already have and the direction/updates that we plan to make in the future.

In any case, all this talk of java really makes me crave coffee.

Jumping headfirst into Android Dev
by on with No Comments

This first week has been all about learning the environment in which I’ll be working in, mainly Android Studio. Having done some minor iOS dev in the past the concepts are not foreign to me and instead of being completely fresh its going to be an exercise in how to apply knowledge to a new syntax.

Much of my time has been spent getting to know how android apps functions, both behind the scenes (the code) as well as how to use the device (completed apps and such). I began viewing forums, guides, and videos to better my understanding of the mechanics and the tools available to me. Following that I started where every self respecting programmer starts, with a simple “hello world” program.

Once I felt I had a basic understanding of who things worked I started to wade my way through github in search of interesting code to read. I am a tinkerer at heart and learn new code through working my way through existing code to get a feel for whats what.