In the previous versions of ODK Collect we were able to make a date to have an appearance of no-calendar and default it to now() and make it ready-olny.
Now in the latest version of ODK collect if we do the same, make the date to be no-calendar, make it read-only and default it to now(), it does not bring the default date. Is there a way defaulting a date to today's date and at the same time make the date have an appearance of no-calendar in the new version of ODK Collect?
Below are the screen shots for the date with no-calendar appearance and default of now() in the new and old versions of ODK collect.
I'm not sure if this is connected - apologies if not - but in recent versions of Collect, Time fields now require the user to press "Select Time", rather than being automatically populated with the current time as they used to be.
Is there a way to make a Time element value default to the current time? If so, where exactly does that parameter need to be added?
Thanks
NIk
Collect does default to today's date/time, but it requires user intervention. See this thread for an explanation of why we do that.
It sounds like you need a default date/time that is read-only as a way to do timestamping. If so, the link above has a workaround that might work for you. If no, then it'd be good to understand your use-case in greater detail.
Yaw - thanks for the thread pointer, I can certainly see why the implementation has changed in the way it has, and I have observed some issues with timezone accuracy in my own data-collection.
The use-case is simply to save the user having to enter the current time, since the current time is the correct option most of the time, and a small time saving in filling out the form is significant - but users also need the flexibility to enter an arbitrary time occasionally, so a read-only timestamp wouldn't work.
Maybe there's something useful I could do with a "calculate" parameter in the binding - I wasn't aware of this parameter before, so I'll have to read up on it properly.
Thanks
Nik
@Blitheringeejit The intent is that when a user taps on the widget button to select the time, the time shown by default is the current time so that the user can tap ok to set the current time. Is that what you're experiencing but you'd like to avoid the two extra taps by having a dynamic default? That is certainly worth exploring.
I have a vague memory of noticing on a particular device that the time was set to 00:00 instead but unfortunately I didn't take any notes on the conditions. If this is what you're experiencing, it's not what is intended and it would be helpful to know the device and Android version used so it can be tracked down.
I'm sure that if Collect had always required a couple of taps to enter a current time, no-one would have mentioned it - but the transition from just swiping on to tapping twice and then swiping on has been a little traumatic for some users!
But getting a bit cleverer with bindings to produce the behaviour I want would be a good learning experience, and if I come up with a way of setting up time element bindings so that they behave as they did up until about Collect 1.5, I'll be sure to post details. I'm much better at forms than I am at Java.
On your other question - in Collect itself, I've never seen a time element defaulting to anything other than the correct device time. I think my mileage has varied because of how that data is interpreted by my form data parser in conjunction with my server time/zone setup - probably my bad.
On the newer version of ODK Collect, when i am using calculate="now()", i got a problem when user edit a form the next day. it replaces the date with the day you opening.
A solution was to complete the date using the hidden variable of the date time when the form is open.
