Accountability(); Pt. 2 From failure to success

I've written many drafts of the second part of this, but in truth most of the development was pretty boring.

I mean, I found it fun, but it's incredibly boring to write about so instead I am just going to do a quick overview of the development.

It started out with me learning the Android SDK, which works a lot like C#, however is WAY more flexible and hands on, which I love. Instead of being limited to only designing the interface with the WISYWIG like in C#, you can manually design it will XML, and really dive deep under the hood to tell everything how to link together.

I then built a "Server" application in C# that could be used on the desktop to add and edit the master list of students, and transfer it over to the tablets using .JSON with a push of a button. It was also planed to have this app be the main base for handling the inter-tablet communication.

The app would read these .JSON files from local storage, and display this list with a few extra buttons attached to it. The app ended up looking like this:

How it turned out

Obviously I blurred out the names, as they are names of peoples actual kids, but you can kind to see how the finished app works. You would Start out with a blank list, and you could click the "Add Student" button in the top right corner [+] and it will bring up the list of students that you can mark off by clicking the (+) button next to their name.

When you are done checking all the students, you click the "Add" button and it adds them to the original list. When they switch rooms, or go home, you simply tap the (-) next to them and the student is taken off the list, as well as the count automatically adjusted.

If a ( ! ) appears next to a kids name, tapping it will bring up special considerations for that child if there are any, IE: Allergies, special needs, "This kid needs to be reminded to get a drink of water every 45min or he will pass out again," etc.

There were some problems that couldn't really be solved though, and had to be compromised.

• In order to communicate we would have to use the schools WiFi. For an official project this would be no problem, as I could get official network exceptions added for the app and be fine, however like I've said many times, this is unofficial, meaning no matter how hard I tried to dance around the security, inter-tablet communication just turned out to be unreliable and somewhat impossible.
• Even if the tablets could reliably communicate, we still have 3 or more rooms open at a time, and only 2 tablets + one server computer. This means that at any time SOMEBODY is going to be using the old whiteboard method, which will make syncing useless as we will still need to use our walkies to communicate everything. This is a side project, and convincing my boss to buy another tablet is out of the question.

How it is today

I wrote this app last summer, so a lot has changed since then.

Originally I was the only person that used it, while the other staff preferred the method which they were used to, and I marked the project off more or less as a failure, but a good learning experience.

This didn't really surprise me, as the final version was harder to pitch with the lack of added features compared to a whiteboard. Really the only 2 benefits over a whiteboard are how it's easier to update the list when new students come to the school, and how it automatically keeps count of how many people are in the list.

At least so I thought. Turns out there are quite a bit more that I didn't intend!

• It's a lot easier use with one hand
• You don't have to worry about markers dying (which happens a lot)
• While it takes a little bit longer to add names, it's a lot faster to remove names
• You can "Lock" the tablet so you don't accidentally erase names with your elbow.
• And finally, like I mentioned before, it automatically adjusts the room count every time you make a change. I didn't think this was a big deal, but holy hell it is

Once other people started realizing this they started to switch one by one over to the tablets, and now everybody uses them, even the old lady who I though never would! It's turned from a failure to a success, and I'm really proud of it now :)

The future of the App

Right now, I'm the only one who updates the app. If a student gets added, I have to take the tablets home, and add them manually to the master list. This is due to how frankenstiened the software is, and how much other stuff was planned but ultimately got cut. I don't have a lot of time to work on it currently, but by next school year I would like to make 2 improvements to the app, before I can comfortably give management of it over to somebody else.

1) The server app that manages the master list of students is hard to use. There are a lot of options that are now useless such as "Push to tablets over WiFi" that need to be removed, and a bunch of buttons and things that were named as a programmer, and not a user like "Parse to .JSON on Save" which is the button you need to use to save it to a tablet. I'm also hoping to build a few other features into this, such as exporting the list to a printable format and such, in case it was ever needed. Basically I just need to prepare this software for actual human use

2) While I have done a lot of updates over the year which fixed bugs, memory leaks, and improved the speed of the app, there is still one major problem. Currently when the app first opens, it loads the master .JSON file from internal storage into a list of student objects which is contained in the main "Activity." If you haven't developed for android before, each screen or window in an app is it's own "Activity," which is sort of it's own self contained sub-program. So in my program the "main" screen, and the "Add student" screen are individual activities. The problem arises in the fact that the only data that you can pass between activities are Integers, Floats, Strings, and a few others, so something like say... a list of students, has to be converted into a REALLY long string, sent to the "Add students" activity, re-parsed into a list of students, and then when you hit the "Add" button, all that has to be done in reverse to get the data back to the first activity. This is ridiculous and takes a lot of time, but until recently I was told there was no other way to do this in order to prevent data loss, however I save the list after any changes are made anyways, so I think I would be safe saving the list in some sort of intermediate storage.

I am probably going to have to wait until this summer to do any of this, because of the cosmic horror that is calculus homework, but to wrap things up, it was a fun project, and it actually managed to get a lot of the kids interested in programming, so I will count that as a total success :)