When volunteer ski patrollers are out on the hill, they need fast and easy access to critical trail information to respond quickly to emergencies. Ski Patrol is an app designed to provide life-saving information to first responders whether they are connected to a network or battling a snowstorm the field.
Ski Patrol provides critical trail information to first responders including trail maps and statuses, snow conditions, weather and avalanche forecasts, toboggan and mountain phone locations, radio codes, live cams and much more.
Gary Mayer, Creator of Ski Patrol: I’ve been an application developer for many years as well as a volunteer ski patroller. Ski Patrol is designed to meet the needs of ski patrollers. It’s a unique environment out there. There’s a lot of data that you need to know: we need to know lif status, trail status, where toboggans are stashed on the mountain, where each AED (defibrillator) device is, what the avalanche forecast is, we might need to contact a fellow patroller, etc. Some of this is real-time data, but there’s also a lot of static data that would be useful in an in-pocket reference, and what better place to store that information than your phone?
The idea for the app stemmed from a fellow patroller. One day a few years ago we were working and he approached me and said, “you know, we capture all this information for incidents, we have to make all these measurements about what happened, is there a way that we could record this in our phones?” I thought, maybe next year I could do that, so during the next offseason I got started.
I think the first pass I coded the backend three different times by hand. I started coding on a Linux-Java backend stack, coding everything myself, all the database tables, the CRUD access, the security, and had to go through all the user management profile, password reset by hand and I got so far into it and thought “I do not want to do this anymore by hand, there’s got to be something better.” So I started to research and came across mobile backend as a service and started evaluating different products.
When I started evaluating different mBaaS products, the features I knew I needed were data storage, the ability to subscribe to some feeds, and I knew I had a unique situation where the user would be occasionally connected so I knew I needed to cache data locally to be transmitted when the user reconnected. I also wanted to be sure I was picking a stable service provider where I wouldn’t write something and have to panic-rewrite it later. I wanted a vendor that provided stable performance, predictable response time and high availability. Perhaps more significantly, but maybe a little bit later on, was good documentation and examples because this is yet another API to learn, yet another technology to learn and if there are examples that I can look at, whether in documentation or an active forum, then I can just copy and paste to get going quickly.
I had started the app with another product and the primary reason I switched over was that they had some quality issues. I was hitting some defects and log files weren’t telling me anything and documentation wasn’t helping me. So I started looking for a new alternative because you need something where your time can be used productively. To migrate from another vendor to Backendless I think took only a few weeks and that’s working part-time, less than a month in total.
I used the security, I used the user management and certainly the data and having a console there to change the data in the backend really helped a lot. One thing I learned with Backendless is that it’s true that you really don’t have to write your own backend for a lot of applications. It’s exciting where the industry is going in the future and it will be easier and easier to build pretty sophisticated applications and not really write anything on the server side except maybe some mapping or filtering, just some pretty basic code.
At first, I had some difficulty with the Backendless pagination in an asynchronous model as it was a little bit different than I was used to. I had a few use cases because I’m working in the backcountry and the device itself needs to have a copy of all of the data. There were a few scenarios where I needed to get thousands of records onto the device so that the user could go through them later when the connection might not be there. Getting those records asynchronously was a minor-to-moderate challenge. I think I only contacted Backendless support on one issue and that was regarding how dates were formatted and the response was quick, professional and technically accurate.
The advice I would give to mobile developers who are kind of struggling about what product to use or not use is to experiment, timebox, try a few alternatives, come up with an easy use-case and a hard use-case that’s core to your application and evaluate from there.
Mobile devices are everywhere, even where there’s limited or no network connectivity. The Backendless mobile backend as a service provides the functionality that apps like Ski Patrol need to be able to serve critical life-saving information to app users when and where they need it.