I still find myself thinking like a C programmer, even though I’ve become immersed in the syntax and grammar of Java over the past five weeks. I’m sitting in a coffee shop here in Harrisonburg, but guess even I can’t C the Java..
O.K., I admit, that was a truly awful attempt at punning. Forgive me. However, the fact that I’m sitting in a coffee shop is true. While I’m enjoying both the atmosphere and my coffee, I’m reminded of the time I went to Charlottesville on a field trip of sorts, with a professor and some of my colleagues. We had gone to an event hosted for local folks in the computer science industry, for which my professor had been invited to bring some of his students to attend as well. It was a more or less unstructured event where we engaged in whatever conversation we happened to talk about, although the nature of the attendees being as it was, the subjects generally tied into the computer field in some way, shape, or form. One conversation I’d encountered talked about, in essence, coffee dates, where someone bought someone else a coffee and then sat down with them to have an intellectual conversation or learn something new. In this person’s hometown, these coffee dates were organized online, but it sounds like a fun idea and a good way to meet and learn outside of the classroom. Maybe such an idea could make its way to my area, wherever I physically end up.
Success! I figured out how to insert my sensors’ data into my project’s database correctly, so now it works and I have no related runtime errors. After isolating parts of my code and continuously experimenting (and looking at Android Studio’s “logcat,” which is their output log for errors and debugging, along with other channels), I realized that one of the values I had been inserting into each row of my tables was always null (which the database didn’t like). After fixing the source of that value, everything ran smoothly: background sensing worked, repetitive sensor activation and deactivation occurred, database inserts – pretty much everything was right on track. Of course, I then started working on adding in location services mid-week and I broke my code again. And so, the cycle of strife continues….
After fixing my code for the motion sensors, I spent a great deal of time this week learning about Android’s location services API. I wholly believe this week that I made an important discovery: I’m convinced now that there is such a thing as over-organization. See, Java is an object-oriented language that separates everything into classes. Android’s framework is primarily written in Java and since Android applications can do a great number of things, the number of classes is equally as large. However, if I want to use, for example, a motion sensor, I can’t just create an instance of a single class to set it up and use it. No, the way Android’s API works is that I need one class to manage it, one class to use it, and, if I want to use certain methods, even more classes as needed for those methods’ parameters. I believe in being well-organized, but it seems like Android separates slightly more than they should. Then again, maybe they separate things as they need to, but just do a terrible job at explaining what to do with everything and why. The latter, I think, might be truer than the former.
At any rate, my application now inserts motion sensor and location data into their respective database tables both asynchronously from the main process and separately from each other. At this point, I’m having trouble closing the database when I’m done inserting both kinds of datasets. If I close too early, I end up crashing, since the other part still needs to write. If I don’t close it at all, I lose access to it, holding hostage valuable memory and potentially (eventually) slowing down my system. In my attempt to close the database at the right time, I hacked my way into making global boolean variables so that I can test for the right condition before I close the database. The next thing I need to figure out is when and how to test for that condition so that it works. After that, Dr. Rahman wants me to pull the information stored in the database and spit it out into a CSV file so she can work on finding the right algorithm to detect wandering in a user off of the device itself. Since there’s less than three weeks left in this program and I want to help her in whatever capacity I can while I’m still here, I’m feeling especially motivated to see this work. Remember to stop and smell the coffee every once in a blue moon and I catch y’all next week!