Write the whole project in Javascript and webgl so it works under every OS

[goatchurchprime]

It's not too late to add the "script" onto the technology, and it would avoid the competition with applications like topodroid. Also it would be a lot easier for get other contributors because you don't have the heavyweight load of the android dev. environment and compiler.

An example of Webgl for caves (which works best on the phone) is here: http://goatchurchprime.github.io/groundwindow/groundwindow.html#caves/expoloser.js

The recommendation is to make it work through the lower-level canvas than using the svg engine because it has much better performance even for very large numbers of elements. http://smus.com/canvas-vs-svg-performance/

Admittedly this is a recent development that makes it possible https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web

[richsmith]

It is far too late in the project's development to consider rewriting the application and starting from scratch in Javascript. Java is a very different language.

I would expect performance to be much worse running Javascript in a web view and considerable problems getting round security limitations.

[goatchurchprime]

Any opinion about the limited performance of Javascript and its access to the hardware platform (aka getting around security limitations) formed more than 6 months ago will be out of date. Case in point: html5 can't access the bluetooth connection. The direction of travel has been clear for some years.

I can't find the direct comparisons of performance (eg frame rate and responsiveness for 2D drawing, which is what this is), but there's huge improvement and development occurring each year https://www.sencha.com/blog/5-myths-about-mobile-web-performance-2/

It might not be long before the Java Android platform is as obsolete as Silverlight (which only ran in MS browsers) or Flash (which, like Android, was never deployed onto iOS).

The Javascript tech opens up considerably more capabilities, such as compiling Survex into Javascript using Emcripten to get the whole of that operation for free, and it would also mean that the topo interface could appear as part of the webpage on the cave registry, not as a special installed and deployed app.

Anyways, it's important to get this opinion on the record here (even in a closed issue) so that anyone coming along later understands why it was not done, and why this gap in the market still remains unfilled, and that some people think it's worth filling.

I'm afraid it's part of the game these days that all of one's past work can be rendered obsolete by a new idea or piece of open source software that one hadn't been paying enough attention to. This happens to me all the time!

[richsmith]

The Bluetooth API looks like it's incomplete, and only partially available on one browser. I imagine it won't be (well) supported on a WebView Android component. Also, Bluetooth is only one IO connection; I also need (or would like) gesture support, acceleration, vibration, compass, GPS, audio, camera, plus any other sensors that might become available. I don't know how well JS will support all those connections.

Android is the most popular O/S in history, with over 2 billion active installs. I don't know of course, but I suspect it's not going anywhere soon. Even if Google switches to Chrome OS or something I would expect backwards compatibility.

If we really want online SexyTopo I think there are embeddable Android emulators but a specialised tool would probably be better.

Javascript might be reasonably performant these days but it's always going to be slower than Java on Android. I've worked on some major applications in JS to good effect and it's probably slightly more pleasant to work on than Java but I don't think it's suitable for this case.

I did actually look into writing it in Clojure, but the annoyances in writing non-Java Android code looked considerable. If I was starting SexyTopo today I'd look into Kotlin but a bit of a moot point now :)

[goatchurchprime]

The most important thing that can move a project forwards is the recruiting of additional developers who make a positive contribution. This effect would seriously beat any of the fixed marginal benefits of one programming language over another. The only thing that matters is whether the language is capable of the features -- or very likely going to be capable of the features in the near future. All of the sensors you have listed above are already available to javascript (I used half of them in the groundwindow app linked to in the first comment).

The market for willing/capable developer/volunteers for cave drawing software on the android platform was, I'd argue, pretty well tested out with topodroid. sexytopo doesn't seem to have revealed a larger pool of developers yet, though maybe there needs to be some marketing. (having a bunch of easy low-lying issues on the github repository is a good way to attract them, as well as some honest technical discussions on strategy, like we are having here.)

The truth is nobody knows the size of the market for contributors for a cave survey project written in javascript/webgl, because there is not yet been one written.

(I can speak for myself that I -- personally -- am in that market, and not in the android-java market, due to having done too much classical-java and not getting along with all these gradle build environments particularly well. I have to be honest that there is an android-C++ app called xcsoar I have tried to compile/hack which gave me a very hard time, and this has put me off.)

A Javascript topo compatible app might be a huge success (for recruiting other contributing-developers), or it might be a bust. It can't be predicted, and it's not under anyone's control. One day it will be tested, because it's such an obvious missing platform.

I'm not trying to get the last word in here; just laying down these high level concepts in case someone else comes along and has a read. It's like tripadvisor reviews for a hotel for the next folks who have to decide to make an informed choice.

Kotlin? How can there still be new languages all the time? A few years back the folks in my company were all into Coffeescript and did a big expensive project in it, and I said "that's all very well, but what happens when that stops being the latest cool language in favour of the next shiny new thing?" They're all into Golang now, and the Coffeescript project has been entirely binned. Not one line saved.