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.

The ball starts moving!
by on with No Comments

Earlier this week we had a programmers meeting to decide the direction for the app such as the mechanics and architecture. While we initially will hold off on the graphic designs for the app there is still much to be done!

I’ve started researching the process states within Android and how the app will interact with the hardware of the Nexus. So far the developer webpage has been most beneficial in understanding the way that processes work by default and how to tweak that to individual needs. I also found a very valuable system service called prostats that allows you to see how RAM is being allocated and gives you to the tools to analyze it for specific features.

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

 

App dev thoughts
by on with No Comments

Im slowly coming to the conclusion that the android platform is a tinkerer’s dream and that there are hardly any restrictions to get in your way (iOS I’m looking at you). I’ve spent the week continuing to learn the ways of java and android studio but have started to shift my thoughts to how to implement and set up the new $FIELDSCIENCE app. Through exploring the source code and the app itself I know the general nature of what is needed (i.e., ambiance, temp, notepad, etc) in the app and brain storming on new ways to implement them as well as taking note on the things I like from the original app. Things feel like they are starting to get rolling!

Gitlab, and archiving!
by on with No Comments

FINALLY, we have a stable Git environment. On hopper (cluster.earlham.edu) I’ve set-up something called Gitlab. Gitlab is an open source git repo hosting environment. For those of you that are familiar with Github, Gitlab is like a self-hosted version of that. I chose Gitlab because it’s private (in Github, you have to pay for a premium membership to have private repositories) and it’s cleaner and has better access control than just doing it through a user’s directory on the machine.

You can see the Gitlab setup here – Earlham Gitlab. There’s a group called field-science where we are going to host all our code. I’ve already created projects for our Android work. The old android code is now in the archive-android project. This means that it is read-only! Yay! Starting fresh for Android $FIELDSCIENCE app. There’s a new project called FieldScience that we will use for the new app, which I’ve already created the shell for in Android Studio and pushed it to the Gitlab. Yay for cleaning and organization.

On Gitlab, we will store the visualization code, the database code, the arduino/sensor code. All the code! This makes it a lot easier when trying to find stuff later (our old Arduino code is all over the place).

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.

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.

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.

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.

1 2 3