Select to view content in your preferred language

Pulldata() calculation triggering when it's not supposed to causing app hang

223
4
3 weeks ago
LorenHutchins
Emerging Contributor

TL;DR I use a pulldata("@layer","getRecordAt",...) calculation to query attributes of a feature at a given geopoint. This calculation should only occur when triggered by another question (Question A). To achieve this, I use the "Relevant" column to make the question only relevant once Question A has been answered. However, the pulldata() calculation will trigger prematurely when the geopoint question is answered (since the geopoint in referenced as an input in the pulldata() calculation), ignoring the "Relevant" criteria and causing the app to hang.

Hello, I have a survey that follows roughly the following workflow:

  • Travel to a field
  • Drop a geopoint in that field to set a location
  • Use that geopoint to query an online map layer for information about that location
  • Record additional details about that location (pictures, ect)
  • Submit the survey

If the user has cell signal, then the pulldata() calc works great. If they are offline, then the pulldata() calc never gets to try, and the user enters the info manually, which also works great. However, my users work in remote areas where they have weak cell signal. The key here is weak, and not none. If the signal is weak, then the pulldata() calc tries to pull the data over the weak signal and the entire survey becomes unresponsive and freezes/hangs for several minutes. The user can't even exit the survey, they are just stuck.

To try and elegantly handle these three scenarios, I implemented a text question with a "calculationMode=manual" qualifier that requires the user to trigger the calculation process to start. Once the button is pressed, it begins by querying the geopoint location for a specific attribute (a unique ID), which once obtained triggers a separate calculate question with that unique ID passed to it in order to pulldata("@layer","getRecordAt") the appropriate record so it can be referenced internally with the "@json" function. This second calc is restricted by a condition in the "Is Relevant" to only run once the unique ID is present in the first quesion.

The problem occurs when the geopoint question gets involved. I utilize the "press-to-locate" appearance for our geopoint question. So when the survey is first opened, no geopoint exists and the app works as expected. But when the user presses to aquire their GPS location, it appears that the calculate question (the pulldata("@layer","getRecordAt",...) calc) gets triggered despite the conditions in the "Relevant" column not being satisfied. This results in the app hang.

I've tried so many fixes to get this question to NOT trigger. I've tried changing question types, explicitly specifying "calculationMode=auto", adding if() statements in the calc to only calculate if other conditions are met, but the darn thing still triggers EVERY TIME the geopoint question changes. I'm at the end of the line here, I can't seem to find any solution to prevent this calculation from triggering. I've included a screenshot of the problematic line below (scrubbed for company info). 

pulldata() Example.jpg

 

Any suggestions?

 

 

0 Kudos
4 Replies
DougBrowning
MVP Esteemed Contributor

Could you post what Question A looks like?  Hard to tell why the relevant is not right without it.

I am also wondering if calculate is not respecting the relevant due to its type.  I would also test setting the type to text and then set the appearance to hidden instead.  That may then respect the relevant.

0 Kudos
LorenHutchins
Emerging Contributor

Sure, here is an abbreviated photo showing the relevant fields. Let me know if it covers what you're looking for:

pulldata() Example 2.jpg

 

As far as question types, I have tried changing to the following without success:

  • Text (with "hidden" appearance)
  • Hidden
  • Note (with "hidden" appearance)
0 Kudos
DougBrowning
MVP Esteemed Contributor

Oh so the question the relevant is based on is also a pulldata?  I could see how this would always a string-length > 7 then since that pulldata is in fact a string bigger than 7.   How would the form know the difference?

Hmm well one idea is try != to pulldata(stuff) and test that.  That may then only be relevant if it has a value.

Next idea is create a manual field for the user that is something like "lookup the id now?" with a yes/no.  Then use that for the relevant.  Extra tap but the bonus is the user can not fire the pulldata if the signal is weak.  They could also toggle it to have it refire if the signal improves or it fails.

Just some ideas

LorenHutchins
Emerging Contributor

So, the question the relevant is based on can either be manually entered, or calculated via a pulldata(). The reason the condition is >7 is because a manually typed number will be exactly 7 characters, whereas when I use the pulldata() function, I concat the retrieved value with an appended letter (A) to make it 8 characters long as an indicator that the value was auto-generated instead of manually entered.

Regardless, your suggestion spurred a thought that possibly that some white spaces were existing that were causing an issue. But upon further testing, it looks like the string-length for the value before being manually triggered is as expected (just an A). 

I also tried the manual field you suggested, and it still seems to fire regardless.

0 Kudos