Collect: Copy/paste using long-press on text field

[getodk-bot]

Issue by Gkreindler
_Wednesday Feb 03, 2016 at 14:29 GMT_
_Originally opened as https://github.com/opendatakit/opendatakit/issues/1194 (2 comment(s))_

---

Currently, long press on a text field opens a menu to "edit prompt / remove response". It would be helpful to be able to paste a string, and possibly also to copy its existing contents.

Can the copy/paste options be added to the long press menu for text fields?

This issue came up recently:
https://groups.google.com/forum/#!topic/opendatakit/f9nINg8x81Y
I encountered the same issue when I needed to copy a location from Google Maps to clipboard, and paste it in an ODK question.

[getodk-bot]

Comment by andris
_Thursday May 26, 2016 at 15:01 GMT_

---

+1 - this would be really helpful!

[getodk-bot]

Comment by adzucker
_Friday May 27, 2016 at 01:11 GMT_

---

+1, this would be useful when using other applications alongside ODK.

[jnordling]

Ill take this issue.

My guess is that this is a artifact of time and technology progressing. The phones today have the longpress intergration for copy, paste etc baked into the core OS. Im sure when these widgets were developed that was not a feature by default of all phones..

Could be as easy as removing a override function.

[jnordling]

I have looked into this a little further. All the widgets when a long press is applied a dialog for editing appears. It also seems that the dialog is different depending on the widget. For example, long press for an image is differnent then a long press for a select 1 or a text field... I think adding the ability specific for the text field to copy and past is fine, as other widgets seem to have specific functionality?

Dose that seem right or do you have any thoughts on this @batkinson

[lognaturel]

@jnordling I think adding copy/paste for text-based fields only sounds great. The only weird case I can think of is making sure it's also available for text fields that are in groups.

[grzesiek2010]

Hi Guys,
I've worked on that in my last project (ODK based). It's nice to have such option and we should do the same at the ODK level. As I remember it's not as easy as you @jnordling think beacuse we can't get rid of an override function setOnLongClickListener as it exists in abstract QuestionWidget class but it's not a bigg effort too :) we should check in FormEntryActivity#onCreateContextMenu() if it's StringWidget and is focused or not and then show the dialog or not. Probably it will require some small additional changes too but I'm not sure I can't recall.

@lognaturel I'd be happy to do it.

[lognaturel]

Thanks, @grzesiek2010, great that you have this experience!! I'll let you and @jnordling decide how you want to split it up or collaborate.

[grzesiek2010]

@jnordling You were first so you decide :) If you want I can do that by myself otherwise I can help you too.

[jnordling]

@grzesiek2010 if you have already implemented this via your last project, have at it, thats great news.. Alot of tickets here, the more we do the better ODK will be... Look forward to seeing the PR.

[grzesiek2010]

@jnordling thanks. I'll start work with the code soon.

[lognaturel]

The current behavior is that it's possible to access the copy/paste menu by double tapping any text that an EditText contains. This is incomplete because it's not possible to paste into a blank field.

Here are a few possible approaches to getting complete copy/paste behavior:

1. Make it so a long press on a String Widget whose EditText has focus brings up the copy/paste/etc menu and that a long press on one that doesn't have focus brings up the context menu.
2. Make it so a long press on an EditText regardless of focus brings up the copy/paste/etc menu. A long press on the parts of a String Widget that are not the EditText (label) would still bring up the context menu.
3. Add an option to paste in the existing context menu when it's triggered from a String Widget. This is probably a bad idea because it's not clear what the behavior should be if there's already text in the EditText.
4. Make it so double tapping a String Widget with a blank EditText shows the paste menu but don't change long press behavior. This maintains the consistent "long press to clear an answer or group" behavior across widgets but it's not standard Android behavior so probably not something we should do.

The difference between 1 and 2 is subtle but it may be slightly easier to train people on 2.

@grzesiek2010 Did I capture the options? I believe you have built 1 previously and are trying out 2 currently.

@Gkreindler @andris @adzucker @jnordling would love your thoughts on this.

[grzesiek2010]

Yes I've implemented 1 in my last project and now I'm trying out 2. 1 is ok in my opinion but it will require additional changes as we keep EditText focused (highlighted) even if the keyboard is closed now. As you prefer 2 I'm trying it out now.

[Gkreindler]

I do not have any substantive comments as such but wanted to thank you @lognaturel
and @grzesiek2010 and everyone else. Especially @lognaturel for suggesting to paste by entering some character in the text field and double tapping. This is obvious (ex-post!) and easy enough to do/teach, and immediately available. Thanks!

[andris]

@lognaturel thank you thank you for the suggestion on the double tap! I did not know this. I will immediately train my field teams on this and it will be a huge help!

I would agree that if it were possible to support 2 above it would feel more natural to the android interface. Case in point - a number of my field guys are quite mobile tech savvy. We and they together had never figured out the double tap option (even though now that we know, we will definitely use it).

[grzesiek2010]

@lognaturel I've implemented the second option.