How to get a location function working

Making Packs
1

Hello fellow coders,

I have to admit that my javascript knowledge is very rusty, I have gone through all the samples and even though I understand them to a certain degree, I am kind of wondering how I will go about writing them from scratch. But I will try.

Triggered by a question in the community I looked up a very small piece of code on W3schools.com and I tried to make it work in a pack. And I failed. I think it should be fairly simple, but javascript can be pretty tricky.

I hope that someone is willing to transpose the following to a working pack and leave a text copy of the pack-code in this thread. This bit of code works and returns the coordinates of your (device’s) location. Thank you in advance for your help!

Greetings, Joost

HTML/javascript:


<!DOCTYPE html>
<html>
<body>

<p>Click the button to get your coordinates.</p>

<button onclick="getLocation()">Try It</button>

<p id="demo"></p>

<script>
var x = document.getElementById("demo");

function getLocation() {
  if (navigator.geolocation) {
    navigator.geolocation.getCurrentPosition(showPosition);
  } else { 
    x.innerHTML = "Geolocation is not supported by this browser.";
  }
}

function showPosition(position) {
  x.innerHTML = "Latitude: " + position.coords.latitude + 
  "<br>Longitude: " + position.coords.longitude;
}
</script>

</body>
</html>
1 Like
2

To the best of my knowledge, Coda packs are run entirely on a sandbox-ed environment on a server, and not on the client (i.e. user) device. Any JavaScript code you run will not have access to information about the user’s system (like traditional browser code can), without specifically using the Coda APIs.

1 Like
3

I think you are right about that - and it certainly explains why I couldn’t get this to work. This means we still need some more native Coda formulas to address this type of functionality. I hope that some of these not all to complicated requests will be addressed.

Thanks for your insight in this matter.

1 Like
4

@loucadufault is correct. Being server-side JavaScript, the browser-based APIs that a lot of courses and site will teach you won’t work. Even if we would build a method to get a user’s location, it’s not clear which user it should be. Unlike most apps where a user interfaces with it directly, in Coda a Pack runs in the doc, even when there is no user looking at the doc.

2 Likes
5

But keep going @joost_mineur! I’m sure there are other Pack ideas that you could come up with!

1 Like
6

This is an interesting use case and I can imagine that there are many cases where a Coda doc would need location context to be more useful and productive. Think about the new Tesla Giga plant in Texas. There are huge opportunities to utilize location and data and content from mobile devices with Coda “apps”.

The challenge - as you have found, is that web apps don’t have frictionless access to the device at a hardware level; sort’a similar to the blood/brain barrier that we all enjoy as humans. And there’s no easy way to overcome or work around this issue. But, there are some clever things that one might imagine at least in the context of known spaces. For example, at Tesla, there will be QR codes throughout the plant and these are useful as arbitrary point markers for any apps to take advantage of.

My thinking is that the way to solve this is inside the Coda iOS app - it should be able to access and continually make available to developers the lat/lng depending on user acceptance settings. We need to petition some Codans for this like @Eric_Koleda .

Another approach that is slightly kludgy but may work – is to use an iOS app such as Workflow to call a custom webhook service that shares the location in a way that can be easily accessed by Coda (in a Pack perhaps). I don’t have the time to investigate this deeply but I’ll bet there’s a pathway using the Workflow API that would allow geo-location to be available to a Coda Pack.

Lastly, Coda should also consider supporting Custom URL Schemas. This would allow arbitrary iOS apps to convey information to the Coda iOS app.

7

If I understand your use case correctly, I would argue that this would be best handled by some external service that provides user location, that Coda can query. Ultimately Coda is a tool to operate on data, not to read sensors and gather data…

For example, there are use cases for documents that might operate on temperature data, that doesn’t mean that Coda should itself provide features to query the weather, or the system’s current temperature…

2 Likes
8

Indeed. But there are Coda binary clients that are literally running on the sensors. A Coda app running on an iPhone or an Apple Watch Stream It just such a case; the sensor is the OS. In those cases, it may make sense to bind the app with the sensor.

GPS and orientation are two sensors that tend to be exactly where Coda is running and these are commonplace relationships involving data that is indigenous to business apps. Weather, while all around us, is not generally indigenous to business apps.

not to read sensors and gather data…

Coda already makes many data values available that are gathered - how is identity or time any different than location?

1 Like
9

@loucadufault I kind of dislike this type of conversation, because your comment is not really an attempt to answer my question, but an opinion about the way Coda should work. That doesn’t offend me, but it really belongs in another thread or in a new posting.

That said, I think it is good te elaborate a little bit on this subject. Coda can store, process and display different types of data, from pictures, to stock quotes to work flows and many more - and this data can come from many different places, like the cloud, your devices internal storage, external data providers (through API), your devices camera (a lot of people might not realize that in a file type column you can use your own camera to add pictures) and of course the most obvious, your (on screen) keyboard.

So, regardless of my business case, what argument could there be against using all the available data collection possibilities of your device, not only the camera and the keyboard, but also temperature, gyroscope, location, wifi access, clock and who knows what else.

In this particular case I was triggered by a question in the community to check if it could be done with a custom pack (and I am tempted to think it can be done by accessing an app on my phone with a request to a localhost or something like that). In my document/app, we are processing actual process data and I would use location data the moment it became available, for logging and for triggering other actions.

Coda is extremely versatile, so I really can’t see any reason why I would not use sensor data if they are available. If they are available, you don’t have to use them - you can use them if you desire to do so.

I don’t agree with your statement that getting these data is best handled by querying an external service if Coda can acces these data directly. I don’t see any advantage going the external route.

1 Like
10

A Coda app running on an iPhone or an Apple Watch Stream It just such a case; the sensor is the OS. In those cases, it may make sense to bind the app with the sensor.

I don’t necessarily see it that way. The OS provides access to those resources, but ultimately they are entirely external to the OS.

I do agree that a Coda client specifically built to target a mobile, sensor-rich device like a smartwatch or phone might diverge from the core app and have a different set of concerns and features. In my personal opinion this is already quite far from Coda’s wheelhouse, but who knows :wink:

It’s a fair point that some rudimentary data is already gathered like the time, although I don’t think those really open the door to cover all other sensors (also identity is not something gathered from/about the system, but rather is intrinsic to the relation of the user within the Coda product.)

11

So, regardless of my business case, what argument could there be against using all the available data collection possibilities of your device, not only the camera and the keyboard, but also temperature, gyroscope, location, wifi access, clock and who knows what else.

There is a non-trivial development cost incurred with creating and maintaining the pipelines to expose this data in docs from the various underlying supported platforms (different desktop/mobile browsers, desktop/mobile OSs). Even as users, it means that their bandwidth is decreased for tackling other features or issues. There are also things like bloat or the permissions requested to consider.

I guess it boils down to where you draw that line in terms of what should/shouldn’t be natively supported. In the context of a data management solution like Coda, in my opinion things like sensor readings or device info should remain external data sources that can be imported and processed within docs using the channels like packs.

12

Absolutely the case and the Codans know this better than anyone. It’s a thing and we shouldn’t try to coerce them to add such features without careful consideration.

The nice thing about retrieving hardware-based data from all platforms is that the privacy settings are not the developer’s concern; they simply adhere to whatever the device owner has established and they are free to change such settings. Bloat is certainly a thing though.

This was precisely the answer Steve Jobs leaned on when iOS (v1) was announced in January 2007. He was adamant that the web had everything a mobile app developer could ever want. In less than ten months, he caved and agreed that he was wrong; hardware possess valuable data that apps need from time-to-time.

I think the term “practical access” should be considered in this context. Is it practical to call a time server to get the current time? Or, would it be more expedient (and more reliable) to ask the device what time it is? It seems the former is both practical and more reliable especially since time is really important for data/content apps even in disconnected situations. Coda does this for us, of course despite the fact that we could easily create such a feature in a Pack.

Determining location using an external service or device-based app is almost impossible. As such, I think it is impractical to ask users to contrive a system that surrenders location circuitously because there are so many challenges when trying this. Please describe how you would go about achieving this from Coda.

1 Like
13

For many users, this too is changing. Mobile users are increasingly adding hardware based security tokens to provide identity.

14

@joost_mineur I noticed you marked this challenge solved - can you share how you achieved location access? Same code as you published in a Pack?

1 Like
15

Actually, I meant my question has been answered, not solved. I figured that it didn’t make sense to leave the ticket open, since we seem to agree a pack is not the answer.

3 Likes
16

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.