Menu

I think I have the start of an invoice tracker. The user may define clients and define actions (punch in/out, arrive, depart, etc). You track events such as “I’ve arrived at client X” and “departing location on client X”. In the end, I hope to export a CSV (comma separated file) to the sd card which later could be imported to a spread sheet.

So I’ve added an audible alert to when the clock hits zero. This is controlled through the application’s preferences by a check box shown to the left here.

Coding was interesting for this because I throw most settings into the Session Storage scope, which as of now only saves information as strings. I struggled a bit with this thinking I was saving a boolean variable. But I digress.

For documentation, sharing, and my own learning process, I want to show significant code bits here. The first bit occurs early on during the init process. I bind the check box to the following function. The variable sessionStorage.buzzerPermitted takes the value of the box’s checked state. An important thing to note is that sessionStorage items, at the moment, store contain strings. The this.checked returns a boolean value. So that boolean (true or false) will be converted to string value.

The second piece follows as such. The function ttNotifications.buzz() is called as the clock restarting either manually or by the count down reaching zero. We first check to see if the notification ability exist and if the user has set that as a preference.

Although, in my last post favored, I argued for the open web. I still do favor this overall; though, to stretch myself a bit, I’ve coded a version on the TerpTimer for Android using PhoneGap and released it to the market. Though I do feel like I’m cheating, it does offer some advantages. If I decide to add the full build out of TerpTools to the mix, the code is closer to the hardware.

The problem I’m looking to solve is alerting the interpreters of an impeding session change. The interpreter in the rest/support role should not have to look down at the phone. This is just distracting during a teamed assignment. Additionally, the screen should not stay on the entire time. That eats up the battery. So I’m looking bit better hardware control for the next few versions.

I’m growing so tired of this debate and I’m sure in some unknown span of time, it will no longer matter. But, recently someone asked why I was targeting TerpTools as a web application instead of building a native app. I wish the answer was simple and straight forward, but as most decisions are, it’s one-part pragmatism, one-part core belief, and one-part feeling the ever increase squeeze of time in my adult life.

First, I am a web developer. I considered my first language to be Perl. As my career progressed, I added other tools to my belt as various projects and managers deemed them worthy of the task. The mobile market is fragmented and diverging. I’m still amazed at programmers who are able to design simultaneously in Java and Objective-C. Really, I hold these programmers in high respect. Their audiences are potentially huge and they can spend time catering to one segment at a time. However, my audience (free-lance sign language interpreters) are a tiny, wide-spread bunch who use various phones, on different platforms, across multiple carriers. To build something that benefits the community, I want to focus at the task in front of me. So, one code base to serve a small community is what works for me right now.

Second, any good coder should respect the user and the user’s device. Programming on the open web does this. If you want to know what I’m doing on your device, look at the source code. If you don’t want the application to track your location, instruct your browser accordingly. Browsers are (supposedly) built to limit what code can do on your device. Native apps have more control in the device and the source might be closed. Granted this argument is still open to debate and will change. And frankly, it should be debated.

The third is time. I can do more to mock-up an idea in an evening using jQuery Mobile than I can in the Android SDK. This might be different from other programmers. However, as HTML5 and the associated JavaScript API comes of age, I can do more in a shorter amount of time. And isn’t that the end goal of programming and coding. As fun as these tools and libraries are, our duty, calling, and privilege is solve a problem or simplify a task for someone else and move on to the next.

Imagine when Thomas Hopkins Gallaudet traveled across the pond searching for methods to educate deaf children. Imagine if the Braidwood family in Scotland had been open about their methodology in educating deaf children. Imagine if Gallaudet had not traveled with Sicard to Paris. Things might be surely different today. While the former group happily celebrated their results, they kept how they achieved those results secret. The latter openly shared their ideas and methods, and because so, spread those ideas to another continent. That is, because one group operated in an “open source” fashion, they changed the course of history.

I’m moving towards a more customizable interface with this application. Users may now enter their own custom categories into their logger database. Again, the logger has different benefits for different audiences. For the individual interpreter, the Logger data could easily become the beginnings of an automated invoicing system. For agencies, the combined time and geographic data from interpreters in the field might help the agency better plan future resources and account for such information vectors as travel time.

After a bit of research, I found the wonderful function which appends a new option to the original select menu and update the JQueryUI/Mobile widget.

So I’m actually trying to use this application in my daily life. I am writing this from outside of my office and the gps was not on. Therefore no position was captured. The remedy was to turn on gps and refresh. I will have to add a field showing the current location and an option to manually refresh.

When displaying the ten most recent entries, if GPS coordinates where captured, they will be displayed as a link. If viewed from a mobile web browser, the link will render maps.google.com. Android devices may intercept the link and prompt the user to use the native Google Maps application. Either way, you have a record of each place you checked in (logged) during the workday.

I’ve decided to break out functionality between the Timer and Logger. New tools will be added under this main screen. Perhaps we’ll brand this as TerpTools.

This has been a very fun project so far, using jQuery Mobile and many of the newer APIs included around the HTML5 spec: SQLlite, geo-location, and session storage to name a few. At present the most useful, is offline access. That is, even if you don’t have internet connectivity at the moment, this application will still work. It merely requires an initial sync with the browser memory, and it will continue to function (record data).

Though real value may be seen by doing something with your data. That is the next step in this project. Stay tuned for more details.

The TerpTimer Logger area now shows the last 10 entries logged for the workday. It includes a time stamp, GPS coordinate, and activity. Activities are still up for debate at the moment. At current they include two main categories Transit and Job Site and sub categories Arrived, In transit, and Departing Future development may lead to custom activities that an interpreter or agency could preset.

The idea is to use this data for a number of things. Once the data is exported and GPS coordinates mapped, a freelance interpreter could reconstruct the workday for easier billing and schedule tracking. Agencies might find use for this data in the arrogate and resource deployment.

Future development will include an export feature to one’s desktop. Other thoughts include showing the last three to five locations pinned to a map on the handheld.