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!

SQLite DB for Data.
by on with 1 Comment

On Saturday, Charlie and I discussed the notion of persistent data for the Field Day android application. Previously, we would stream all of our data to a CSV — even empty lines or entries that are missing data in some spots, and this would cause data to be in a bunch of different data models.

I recently read a chapter on SQLite databases in Android and it seems really powerful. We’ve decided that we are going to use a SQLite database instead of just writing to a CSV file. With this, we could create primary keys and easily pick out all the lines that have empty fields for one column or another. Using a SQLite database will also be useful for our plans to implement an ‘On-Bench’ and ‘In-Field’ option for the soil platform. There are some sensor data that you wouldn’t take in the field and would need to do later that day — like pH or organic content. Using a SQLite database, we’ll be able to simply ask for the sample ID from earlier that day and update it with the pH and Organic Content. Our data will be less messy and we’ll have less random lines of data floating around.

Android Architecture
by on with No Comments

Nic, Charlie and I have been struggling with finding a time to meet so we can talk about the Field Day android application. We were able to briefly talk about it on Saturday morning, and decided some things about the architecture of the application.

Currently, the main screen of our application shows all 8 “skins” (Earth, Ambiance, Gas, Water, Settings, About, Notepad, and Protocols). We’ve decided that we want the main screen to have just 4 skins (Settings, ‘Take a Sample’, ‘Lab Notebook’, and About). The Take and Sample and Lab Notebook skins, once clicked, will open up into a variety of options underneath. All of the types of sample skins from before (Earth, Ambiance, Gas, and Water) will now move underneath ‘Take a Sample’ skin. Under ‘Lab Notebook’ we are going to move Protocols, Notepad, Checklist and whatever else we decide.

Having a separate page for just sampling will make using fragments a lot easier. I’ve started on making icons for the new skins we decided on, and will implement those in the code as soon as they are ready.

Hopefully today we will be able to talk and get more work done in the meeting.

Field Day Application :)
by on with No Comments

We’ve begun work on the new $FieldScience Android application! This application is yet to be named, but what do people think of the name FieldDay? I think it’s snappy. 🙂 I created a shell in Android Studio and pushed the code to our Gitlab repo. All of the developers have been able to checkout the code locally to their machines. The old application has been archived and made read-only in Gitlab.

The current developers of the application — Nic, Charlie, and myself — met last week to discuss the details of the application. During the meeting we discussed the basic outline of what we want the application to do. There will be ‘skins’ for each sensor, and all of those will interact with a basic communications library that is built to interact with all of the sensors that we have. There are many things that the old application — Seshat — did well and we discussed those and the pieces of code we want to keep — camera option on sensor skins, writing to csv, sending to database. Android applications have very particular states and processes that they go through. Through some research, we have figured out that they way our old application handled those could have been part of the problem with it crashing a lot. There is still more research to be done in that area, because we don’t fully understand it but we are getting closer.

We are not going to focus on the aesthetics of the application right now, but we did decide that we liked the front/main screen of the old app and will keep it. I’ve added that to the new application with a few enhancements. I made the skins circles and made the colors stand out more. You can see the difference and changes below (Seshat is on the left, new application on the right). Prettier, don’t you think? 

Seshat Main ScreenNew App Main Screen

 

What has changed?! $FIELDSCIENCE & YoctoLib
by on with No Comments

In our $FIELDSCIENCE Android application we use a library from Yoctopuce.com called YoctoLib which works with hardware purchased from them. We use Yoctopuce hardware in our Ambiance platform, and in the Ambiance skin in the app.

This library and code was working — recognizes the USB Yoctopuce devices that are plugged into the device and reading sensor data from them — the last time I used it (~July). Since then, something has gone wrong. The application will no longer read data from the sensors plugged in. I finally got it to at least recognize the device, but no data is being read. I suspect that this happened because of the move to Android Studio. Android Studio must have internally changed the way it uses APIs, which is what I am trying to figure out.

This further pushes me to believe that switching to Bluetooth to use the Yocto devices is necessary. Since the Yocto devices have to plug in via USB, each time I need to test the code, I have to upload the code to the Android device and then unplug the device from the computer so I can plug in the Yocto devices. This makes it difficult for debugging. If the device is plugged into the computer, Android Studio will constantly log messages from any application in real-time to the screen. Android keeps log messages even if the device is unplugged, and will load them once the device is plugged back in, but it’s all the messages (which is A LOT) from the test at once. It’s hard to go back through and figure out where something went wrong.

Did I mention Android Studio?
by on with No Comments

This past week I’ve been working more on Android development for the $FIELDSCIENCE application that we develop.

I mentioned in my last post that we’ve moved from Eclipse IDE to Android Studio IDE, and that involves migrating projects. The migration from Eclipse to Android Studio is not as straight-forward as Google sets it out to be. Android Studio uses a different build process (gradle). The project architecture is set-up differently, and different files are created during the build process.

I finally think that our Android application is in the form that Android Studio needs, with an updated YoctoLib library! This code has been pushed to git on hopper and can be checked out from any machine, with authentication. I’m working on a ‘to-do’ document of getting the code and importing it into Android studio.

Android, Android, oh yeah and some more Android
by on with No Comments

The past week, I worked on a variety of things — setting up the wordpress, researching archaeology surveying techniques, and setting up our field science application with Android Studio.

In previous years, the IDE that we used for Android was Eclipse. As of earlier this year, Google is no longer supporting Eclipse as the Android IDE and has switched to Android Studio. Things are different in Android Studio and I’ve been working on trying to set up Seshat and get it working. I’ve been running into errors about gradles and builds and libraries, so I’m trying to figure out what’s going on there. I had it working, but realized that I needed to update the YoctoLib library, and when I did that things went down the drain again. Once I have it working I’m going to create a document that will explain what to do.

1 2