I am working with ODK Collect 1.4.3 and I am trying to get it to recognize
a custom formList. Essentially I have a filter I want to pass ODK
aggregate's formList through. The main issue I am running into is that ODK
Collect crashes every time I point it to the custom formList servlet with
the ambiguous message:
"Unfortunately, ODK Collect has stopped."
I can confirm that the server is contacted and gives a response. Further I
experimented with different response to see when it would error:
this response does not error it simply gives an empty list in odk collect
as we would expect.
xxx
this response, although not a valid response, does not cause collect to
error either -- it again offers an empty list
xxx
this response cause odk to crash. Also if I take the aggregate formlist
response verbatum and return it from my custom servlet it also causes odk
collect to crash.
To me the above responses eliminate xml formatting as the problem since
some work and others don't (all above responses use a text/xml application
header). I have not implemented any authentication on the servlet yet as I
was trying to get the basic functionality to work first (and I am not sure
where collect is passing user/password). But if authentication were the
problem then the blank form list response would also error. So I am left
thinking there is a secondary check that it is doing on each form entry and
that the check is causing the error. But, then if I use the same exact form
as the one used in ODK aggregate (including urls pointing back to
aggregate) ODK Collect still crashes.
Any help in this matter would be appreciated. I've been poking around this
for a month now.
Also, compare the headers that Aggregate sends out with what your
servlet sends out and see if there are any differences.
Yaw
···
--
Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.
I am working with ODK Collect 1.4.3 and I am trying to get it to recognize a
custom formList. Essentially I have a filter I want to pass ODK aggregate's
formList through. The main issue I am running into is that ODK Collect
crashes every time I point it to the custom formList servlet with the
ambiguous message:
"Unfortunately, ODK Collect has stopped."
I can confirm that the server is contacted and gives a response. Further I
experimented with different response to see when it would error:
this response does not error it simply gives an empty list in odk collect as
we would expect.
xxx
this response, although not a valid response, does not cause collect to
error either -- it again offers an empty list
xxx
this response cause odk to crash. Also if I take the aggregate formlist
response verbatum and return it from my custom servlet it also causes odk
collect to crash.
To me the above responses eliminate xml formatting as the problem since some
work and others don't (all above responses use a text/xml application
header). I have not implemented any authentication on the servlet yet as I
was trying to get the basic functionality to work first (and I am not sure
where collect is passing user/password). But if authentication were the
problem then the blank form list response would also error. So I am left
thinking there is a secondary check that it is doing on each form entry and
that the check is causing the error. But, then if I use the same exact form
as the one used in ODK aggregate (including urls pointing back to aggregate)
ODK Collect still crashes.
Any help in this matter would be appreciated. I've been poking around this
for a month now.
CascadingSelect
Cascading Select Form
2012072302
2012072302
md5:d4750440f463f31ba1de0b918d3a5582
https://opendatakit.appspot.com/formXml?formId=CascadingSelect
.
Yaw
···
--
Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.
Thank you for the fast reply. The headers ook pretty much identical (except
for the file length. Here are the response headers from ODKAggregate and
from my filtered form:
ODK Aggregate:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Content-Length: 3860
Date: Mon, 16 Nov 2015 04:46:26 GMT
My filtered form: ()
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Content-Length: 28
Date: Mon, 16 Nov 2015 04:46:29 GMT
The headers I am using are directly from the version of ODK Aggregate we
have (which is from June 2014). I'll try to use the new schema and see if
that works. It would not explain why the old schema works when coming from
ODK Aggregate and does not work when coming from the custom list.
To be clear, I think somehow you are either sending the wrong headers
from Collect to Aggregate. You can also try a test servlet in
Aggregate 1.4.7 and see if that helps.
Yaw
···
--
Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.
The headers I am using are directly from the version of ODK Aggregate we
have (which is from June 2014). I'll try to use the new schema and see if
that works. It would not explain why the old schema works when coming from
ODK Aggregate and does not work when coming from the custom list.
I just noticed that if I go to the ODKAggregate/formList directly using the
web browser I get one version of the xml and if I go from my phone I get
the version you posted. So that is probably the crux of the problem there.
It looks like the presence of X-OpenRosa-Version: 1.0 in teh request header
might be changing the xml output.
Correct. That's what I was trying to get across. You need
X-OpenRosa-Version to get the proper form list. The old forms list
that you are seeing is just there for backwards compatibility.
Yaw
···
--
Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.
I just noticed that if I go to the ODKAggregate/formList directly using the
web browser I get one version of the xml and if I go from my phone I get the
version you posted. So that is probably the crux of the problem there. It
looks like the presence of X-OpenRosa-Version: 1.0 in teh request header
might be changing the xml output.