UKC

It's fortunate most climbers use iPhones.....

For the last almost 3 years half of phone users have been unable to use mobile Rockfax!

https://www.statista.com/statistics/262179/market-share-held-by-mobile-oper... 

I hope the SMC made it a condition of providing their data to Rockfax that an equally supported Android version was made available.

That reads like you believe Rockfax are deliberately sitting on a fully functional Android App as part of some Pro-Apple conspiracy. I'm pretty sure that if they could 'make an Andoird version available', they would do so.

That said, I do wonder if it's sensible to commit to, and widely advertise, a co-venture with the SMC when their development resources are clearly limited, but then I'm not privy to their development practices.

Excuse my techno-ignorance, but does one need a phone signal to use this? Is it possible to print off topos and so on at home?

Agreed, however I've always wondered why they developed it specifically for iPhone, when there are numerous frameworks / libraries out there that allow you to write code once and then simply deploy versions for iPhone, Android, PC or Mac (even in-browser in some cases).

I've always found it actually easier to do it that way anyway 'cos I can do the bulk of the development, testing and debugging on my laptop without having to faff about getting it onto a device and setting up a remote debugger etc. every five minutes.* Much simpler. It also massively reduces maintenance overhead and costs as there's only one code-base.

Phil

*You obviously need to run full and thorough tests on each platform at the end of the process for anything you're planning to ship.

Converting existing information for the app, and developing the app, are very different things for us. Converting the data requires layout work and a nerdy obsession with Logbooks and data accuracy  - so that is my job mainly! Developing for the app requires real technical coding knowledge which is out of my league!

Alan

Can you confirm whether or not you are making any effort towards producing an Android version?

It seems to have been promised for an awfully long time.

No. Once you have the data on your phone then you get full use of the guide information on the app. There are some added features that require a data signal - like checking the UKC Listings or uploading your ticks to UKC Logbooks - but these are only 'extra' features and all the crag descriptions, approach, route descriptions and topos are downloaded on the phone.

The geo-located maps we have on many of the app packages require a gps signal to show your location, although the work fine as normal maps without this. The SMC maps are geo-located though.

You can't print anything out from them since the data is never displayed in large 'pages' and it would defeat the point of the app.

Alan

My understanding is that the Rockfax app is way to complicated to work from libraries and would be cripplingly slow and no where near as sophisticated had we gone down this route. 

However I will get Martin to give an Android update.

Alan

As Alan has said, perusing this project in using some sort of cross platform approach I don't think would work. Most of the time sinks in the Android and iOS version have been around UI performance. I can't imagine the headache when you look at developing this cross platform over native.

But on the Android app front the big piece of work that we have is the UKC Logbooks integration and having UKC routes on the phone. The Rockfax guidebook side of the app is pretty much done. We do need to setup a system for delivering the data to the Android version, the iOS app gets the data via Apple, although we want to move away from this eventually. This bit of work will involve myself and Stephen, the iOS developer, so having 2 hands instead of 1 should mean that we can get through this at a much quicker rate.  

Regarding Rockfax having limited resources, that is indeed true, but is also true for pretty much anyone else in this space. The Rockfax app is more complex than it might look. In terms of collaboration with the SMC we are working very closely with them and they know all the details on the state of play.

These frameworks have come a long way in recent years, and I would even consider using FaceBook's React Native now. However, when the app was originally developed they were all pretty crap, and RN didn't exist, so the decision was made to go pure native. This means ultimate control for us at the cost of slower development. This was my decision and I still consider it to be the correct one.

None of these cross-platform solutions come without tradeoffs. Many are hard to debug, rely on a third-party to keep them up to date and may limit what you can actually achieve by only allowing you to do things that can easily be done on all the platforms. React Native is good in that it allows you to write your own 'widget' (my term) using the platform's native libraries and hook it up to the RN plumbing, but the RN plumbing is still JavaScript and frankly, I'd prefer not to have to maintain massive applications written in JavaScript.

Because we had no idea wether the app would be successful when we started, we chose to write for iOS first and then port it over to Android. This choice was made simply because I was familiar with the user experience of that OS due to having an iPhone and using a mac for the Rockfax publishing work I was employed at the time to do.

Rest assured that we're not purposefully holding back the Android version. It's been in development for some time, but we're a small company building a fairly large and complex app, so it takes time. Hopefully it will meet the expectations of the waiting Android users when it's ready.

Interesting. I haven't seen the issues you talk about with slow UI response, and an awful lot of very complex apps are written in a cross-platform way. To be clear - I'm not talking about writing it to run in a web-container. I can see how that might lead to the issues you have concerns about.

Anyway, none of my business. I have no doubt you guys made the best decisions at the time, with the constraints you then had.

Forgive me if I've got this totally wrong (as I may well have as a non-techy dinosaur) but are you saying you have the guidebook element - surely the most important bit - ready(ish) but are holding it back while you work on logbooks? Perhaps I'm missing the importance of logbooks, but frankly I don't care what routes  people have done and it seems to  be the tail wagging the dog if such a relatively unimportant part of  the app is holding back making the much more important guidebook element available to the many android users.

Just a question about that Sneachda example. What does the S stand for next to the grades? I can't for the life of me work out what it refers to. 

One of the principles we work to in software development is that developers made the best decision they could, given the information and constraints available. That's not to say that they were correct, or that now there might not be a better way of doing things, but too many projects have ground to a halt when some developer decided to write their app again from the ground up "because reasons".

It's easy to say that a project should have been designed in such and such a way in retrospect, but commercial programming requires making pragmatic decisions.

I'm not sure what decision I would have made had someone brought me the project, probably written the whole thing in Qt and C++ just to be awkward. I'm sure Stephen made the best decision he could given the information available.

I've used the iOS version of the app for a few years, but have now made the move to Android. When the Android version eventually gets released will I have to re-purchase any of the packages, or will it be like Viewranger where the maps are cross platform? I still have access to my iPhone and would buy a couple of the packages if they would be transferrable in the future. 

Snowy.

as opposed to...?

This is what I was told.

'The S is there to recognise that it’s Scottish not UIAA alpine grading, and will be hidden when the next upgrade of the Rockfax platform goes out.'

Thanks. Does seem a bit odd! 

This is correct although I think we might have produced an update without that addition. Distinguishing between different grade systems is quite a headache.

Alan

We are aiming to make this possible. That is why we need to bring the distribution of the app packages back to our own server since that is the only way we can control them and assign them to a user id rather than an Apple ID. This is quite a big job though.

Alan

It is not that simple. Without the logbook link-up the app doesn't work for various reasons. 

Alan

I see Alan said no below about printing directly from the app. However if I wanted to print I would screen shot on a phone (or ideally tablet as the screen is bigger) and save to then print off the picture on my computer.
Does the Rockfax app work on tablets?

it does on an ipad

You may find use in the share button in the route cells (the blue arrow going up and right) for making a print off for multi-pitch routes for example. This generates a pretty hi-res image of the topo with just the shared route marked on it. Sharing via WhatsApp doesn't work as expected because they stopped accepting the standard format for some reason, but email, message, copy etc all work.

Here's an example: https://imgur.com/a/Oxr3j

because I don't see it written above, I just wanted to say a huge thank you!!!

I've whinged on here before about the lack of coverage for Scotland on the app and this seems like a hugely positive step forward for both Rockfax and the SMC.

Not easy I'm sure and so well done on all the work so far.

I'm really enjoying the Dunkeld package and have already seen where i've gone wrong on a few of the routes there, meandering the wrong way.

That and despite the understandable disappointment of the android users you all clearly played the percentages when you first started work on this project, no one can fault you for that.