Persistence in Android Field Triangulate

Android Field Triangulate has historically stored events (collections of readings comprising a triangulation) in memory. The intention was to create a few readings (in a relatively limited timeframe) and create a triangulation. Job done, triangulation shared. In actuality this isn’t how things always work, and wasn’t always sufficiently reliable.

Despite attempts to save these readings to instance state, in memory storage could lead to lost data … say if the application is unloaded (e.g. by a battery saver killing applications.) Lost data is never good, and this was never the intention.

Android Field Triangulate 1.3 now utilizes a persistent database in order to store readings. Sign up for a Beta Testing version, if you are interested in checking it out.

Setup persistent storage

Note: The reason for network connectivity at first setup is because the persistent store utilized is a cloud synchronized database. In theory (given a named account) this could be used to synchronize events (readings and triangulations) between devices. Please contact me if that seems of interest.


BTW: If/when asked for location permissions, Android Field Triangulate doesn’t need more than “Allow only while using the app”.

No background locations needed.

Response Utilities – Create Incident

Many response teams work in remote locations where mobile networks are not available, or are available sporadically. Being able to create an incident offline (a placeholder, if not full details) allows capturing incident attendance.

Response Utilities version 1.0.8 has an option to create an incident, attach members (even offline) and queue that incident until on network and the information can be uploaded to D4H.

This ability is available for beta testing. Please check it out and provide feedback.

Note: This ability is (of course) dependent upon the user having the required permissions for their account in D4H.

New option to press “+” to create an incident.
Add title, reference identifier, a short description and attach attendance (from list of membership, available offline.)

D4H API

The D4H API (Application Programmer Interface) is a powerful way to access and interoperate with your organization’s D4H data, and enhance your organization’s D4H usage of it with your own developments.

For example you can create your own mobile application for D4H (in additional to the D4H mobile applications, that use the API.) That, or you can craft your own simple scripts, e.g. to provide a custom quiz to your users via the whiteboard.

The simplest way to get started is:

A more flexible (but marked as experimental, and quite likely soon changing) approach is to implement a user “login”, to gather a token on demand. Note: This isn’t quite as simple as it first appears, it is two step not one. ( When we log in to D4H first with an account it is second our membership in an organization/team that we then use for most API calls, and some accounts are members of multiple teams. ) The authentication API grants an account token, and to call the main APIs one needs to use the account token to acquire a membership token from that account token. (The generated token above – from the team website – is already a membership token.)

Once you have a working token you can access most of the team data; and update some.

  • Activities (past and future)
  • Duty records
  • Member records
  • Groups
  • Equipment (and more)
  • Tasks
  • … and more

What do you want your D4H data to do?

You might want to create a simple an app or webpage to allow your membership to submit maintenance reports your way, or you might want to display call statistics or some recent incident information (or available tasks) on a display in your building. The D4H API allows you to decide what is important to you, and enhance D4H towards that goal. (I’d love to hear your thoughts and ideas. Let me know.)

Powerful, but still ‘Work In Progress’, I hope…

Much as the D4H API is very powerful, the API is incomplete in a few key areas: incident updating, qualifications, tags, custom fields, and more.

Hopefully those will be coming because without them activities can be created, but not updated in any way (not adding a location, a tag, a description, nothing.) This limits any field-based tools for incidents.

No access to qualifications means we cannot create our own qualification reminder systems, and qualifications (we have many tens for every member) are a key challenge for our membership.

Share Triangulation Android

After considering offline sharing (to offline capable maps) of the triangulation on iOS, I realized the same should be possible on Android.

The share coordinate button on the beta version of the Triangulation application, now offers a chooser to allow any installed applications that support the geo:{LATITUDE},{LONGITUDE} scheme to be opened to that location.

Please join the open beta for Field Triangulation and check it out…

Open triangulation in application…

Some application that support this scheme are:

Incident “Credits”

Our annual membership requirements include training (across all disciplines), some safety requirements (e.g. mask fit testing) and 20% incident attendance. That 20% … 1 in 5 calls … can be hard on some responders. Calls drop at odd hours of the day or night irrespective of life, family and work schedules.

We offer “Incident Credits” as incentives / rewards for above and beyond shifts (Christmas & New Year shifts … one credit atop any calls), for critical conditions patrols in hot/dry summer months, and for other worthwhile causes.

To apply an incident credit:

  • Create an incident, allow D4H to set its unique identifier (we don’t typically use the CAD identifier, but we might add an “a” or “b” to the end of one to associate it with that incident, e.g. stayed overnight to monitor the fire.)
  • Tag the incident as “Incident Credit” (we create that tag)
  • Invite *only* those getting the credit (do NOT invite the rest of the team, hence a bonus for those present, and no negative for others not present)
  • Approve the incident as/when your process dictates.

D4H shows “percentage attendance” which mathematically is a numerator of “number of attended incidents” over a denominator of “number of invited incidents”. Adding an “incident credit” is technically not fully 1 incident attendance since it adds to both the numerator and the denominator, but it is a valuable credit (and close enough.)

D4H Incident Percentage in Reports…

We tag incident credits as such, mainly so we can pull them out from regular incidents to get accurate response numbers for (say) grant applications.

D4H does a good job of maintaining individual response numbers, and incident credits allow us to give credit while keeping things simple (the presented numbers correct) for the volunteer.

On-boarding new members to D4H and more…

With today’s training requirements on new firefighter recruits it take a couple of years to develop new/promoted firefighters. We do annual recruiting and annually hold classes for structural firefighting, medical response, hazardous materials and wild-land firefighting. We are about to start on-boarding almost a dozen new recruits…

On-boarding is a process. We have an orientation day where we take a photo of the firefighter (for identification, but also for us to put a face to a name) and we add them to D4H, and provide them a login so they can get acquainted with what is going on. We then have a bunch of other tasks per recruit…

We chose to use Asana for our task management. D4H has task management but we wanted a bit more sophistication in grouping, assignment & deadlines. (We use D4H tasks for equipment/station maintenance tasks.) One thing we do with Asana is group on-boarding tasks for a new recruit, and then clone that whole group of tasks for each recruit.

Our tasks look like this, and we clone them (with assignments / deadlines) one per recruit:

  • [IT] Add to Everbridge (as non-Operational.)
  • [IT] Add to D4H. Check groups, permissions. (Station group, mentee group, Full Fire-fighter or Wildland Team group.)
  • [Admin] Add ID photo to D4H.
  • [Admin] Add to Training Sheet.
  • [IT] Add to Google Groups – including dispatch group.
  • [IT] Add to Wild-land IQS – for qualification tracking
  • [IT] Add to Group Me – for dispatch messaging.
  • [IT] Add to Evite.com (for annual award dinner, family picnics, etc.)
  • [IT] Add to online training system (as needed.)
  • [Admin] Add to FPPA portal (pension)
  • [Admin] Get coded for County Fuel Key (once ready.)
  • [Admin/IT] Get Knox Box code (once ready.)
  • [IT] Add to Everbridge Operational Group (once ready.)

… and this is just the list after we’ve done the initial health / background screening, and paperwork. Actually, there is likely even more.

We found that if we did not explicitly add a task for each step of each new member we’d overlook something for somebody, and it is hard to catch these things after the fact. (New recruits don’t initially notice when they aren’t getting notifications they don’t yet know about.)

One gotcha we have each year with D4H and newcomers …

We are 4 fire stations, one fire community but two main teams (full firefighters FFF and wild-land firefighters WLT) and we are one D4H team. (I’m not sure we’d change to one D4H Organization and two D4H Teams, even if we could. It’d feel wrong to separate things.)

Anyway we do tend to create exercises where we invite FFF and/or WLT as appropriate, and we cannot not use “Full Team” so we use “Selective” attendance for the activity. We lay out our training calendar at the start of the year, which is where the problem arises: Our new recruits get added to D4H and these groups after the exercises are created, so they are not added to the exercise’s attendance … they are not “requested” and they don’t have permissions to add their attendance. It hits us every year.

We have no easy fix for this we just (after on-boarding) create a D4H group of the new recruits and manually updating the exercises they want to go to, requesting the members of that group. New recruits usually have more than enough of their own training, but there are a few (boat training, pack tests, mask fit tests) that they want to attend. It catches us every year.

We are very grateful for the new recruits, however on-boarding is quite a process…

Volunteer Engagement…

As an active Fire Department with up to 300 calls a year and lots of training / qualifications / equipment to manage, we have a lot of reasons for our volunteers to log in to D4H. We’ve found we can get a sense of current engagement (especially with the newcomers) by seeing how long it has been since they last logged in.

https://YOUR-DOMAIN.d4h.org/team/members/lastseen

To get here go to “Planning” / “Members” then “Manage Access” under “Usage & Logs”.

Most newcomers are eager to get involved and check in daily. Some who are busy might go a week between visits. Those who are a month or more away might need a check in themselves. (We’ve implemented a mentorship program where experienced firefighters help new firefighters navigate the – these days – challenging first couple of years of training; structure firefighting / medical response / hazmat / wild-land firefighting. Mentors will check in on new responder to help them remain engaged and make it through those hardest first years. )

Most volunteers experience up and downs in their career, “up years” and “down years”. These show in response numbers, and attendance numbers, but also here.

If volunteer retention is an active issue for your organization (and we are actually very lucky in this regard) then this is a screen you might wish to check on now and then.