Collect: animations to form entry

[getodk-bot]

Issue by mitchellsundt
_Wednesday Jul 08, 2015 at 22:44 GMT_
_Originally opened as https://github.com/opendatakit/opendatakit/issues/59 (3 comment(s))_

---

Originally reported on Google Code with ID 58

it would be nice to get some visual confirmation (shake left to right) when at the beginning
or end 
of form entry

Reported by yanokwa on 2010-04-29 22:29:14

[getodk-bot]

Comment by mitchellsundt
_Wednesday Jul 08, 2015 at 22:44 GMT_

---

Reported by wbrunette on 2011-06-07 22:50:03

• Labels added: Type-Enhancement, Collect
• Labels removed: Type-Defect

[getodk-bot]

Comment by mitchellsundt
_Wednesday Jul 08, 2015 at 22:44 GMT_

---

Reported by yanokwa on 2012-05-25 15:46:39

[getodk-bot]

Comment by mitchellsundt
_Wednesday Jul 08, 2015 at 22:44 GMT_

---

Reported by yanokwa on 2012-05-25 19:09:13

[IanUme]

So I took a peek at this one. Is there a way to decide the best way to show the beginning and end of forms? There are a few ways I can think of:

• Shake left to right (suggested in issue. I don't quite understand this)
• Page numbers
• Dialog pop-up
• Tilting view (not sure if this is feasible with the current implementation)
• Add START and LAST on the top or bottom of respective pages.

[lognaturel]

I think the shake suggestion is to do something like this but with the entire view.

I think the most standard approach would be to show a "glow" like the OverScroller class provides. For example, I just looked at the Google apps tutorials which have horizontal scrolling and that's what they do. This is what the screen looks like when I scroll left past the beginning of the tutorial:

This library uses a bounce interaction but I think that's more of an iOS standard and that it would be best to stick to Android visual elements.

My vote goes for the overscroll glow. What do you think @IanUme @yanokwa?

[yanokwa]

I'm for whatever interaction is common in Android, so let's go with the OverScroller glow.

[IanUme]

@lognaturel, great thanks for the advice! I'll try to work on this one at a snail pace (but if anyone really wants it feel free!)

[IanUme]

So I looked into this issue and it may be something I might have to pass on. The way the forms are currently setup is by custom ODKViews with animations to transition between each one. The way I read to implement the first and last page glow effects was through the EdgeEffect class (introduced in API 14). There is also an EdgeEffectCompat in the v4 support library, but it uses swipes to determine when to start and end the animation (the current implementation is through flings which only detect when they are finished).

I don't want to make or advocate major design changes but from my experience using a ViewPager (also from v4 support library) with custom views is generally the best and recommended way to implement this functionality (but I didn't dive deep enough to understand how the sub-views work in this app). It automatically detects all the swipe gestures, allows multiple pages to be "partially" read at the same time, and shows animation for the beginning and end.

Overscroller was also not an option because scrollview is not used for the horizontal swipes.

[lognaturel]

That's super helpful, @IanUme. You are definitely most welcome to suggest significant design changes! Then we can discuss here or in Slack if it's something that needs to have community input.

I'm not sure why ViewPager isn't used but it could be as simple as that it didn't exist when the code was written (some of it was developed before Android's release). If you had some time and interest in exploring whether a switch to ViewPager would be possible and how much work it would take, that would be fantastic. If you'd rather take up a more straightforward issue, that's great too!

[IanUme]

Thanks for the info! Writing before Android's release must have been tough. Well then, I'd like to propose adding v4 support library for view pager functionality. The main downside is if you add the whole v4 support library, the app size goes up by about ~1MB (I know app size is very important for this project). With Proguard settings and a specialized gradle configuration, it's possible to drop the size down a little more.

I haven't dug deep into the ODKView creation and the "sub-views" I saw yesterday so I'm not 100% of the feasibility of switching to a view pager. The FormEntryActivity.java is a beast though, so without deep knowledge it might be easy to introduce bugs.. Let me know what you think or if this idea should be in slack or its own issue @lognaturel and @yanokwa

[lognaturel]

I had a thought about this but just realized I never wrote it down! Is it accurate that if we update theminSdkVersion to 14 as per #293 we could use EdgeEffect relatively easily @IanUme or would that require a more significant code restructure than using the support library? If EdgeEffect is feasible, I'd rather wait until resolution to #293 before tackling this.

[IanUme]

@lognaturel Although I don't have experience using it with gestures, it should be fairly trivial to add the EdgeEffect with a min SdkVersion of 14. I think the cleanest implementation is still a ViewPager (overscrolling is built-in) but we can make it work.

[lognaturel]

Thank you @IanUme! I think we should spend some time actually looking into what it would take to switch to a ViewPager implementation and whether there would be other benefits to making such a drastic change. For it to be worthwhile, I think it would have to do something like make future improvements easier or make testing easier. I know @carstendev has expressed some interest in refactoring and he may have some opinions here.

If that isn't looking good, we can consider the EdgeEffect route but I'd like to take the support library option off the table since we have to do a minSdkVersion increase at some point anyway.

Perhaps a good step before even doing that would be to explore putting in some behavioral testing so a major change is less likely to have bad side effects.

[carstendev]

From what I can gather, using the ViewPager seems to be the recommended practice by google to implement Swipe Views.

I haven't had the time, to look at what it would take, to switch to a ViewPager implementation though. The v4 support library only works with the v4 version of FragmentPagerAdapter and FragmentStatePagerAdapter. The v13 version has both the v4 and the v13 version of FragmentPagerAdapter and FragmentStatePagerAdapter. If we want to use native Android fragments, we have to go with the v13 version.

Adding tests to decrease bugs and bad side effects should definitely be a prerequisite, if we decide to make any major changes.

[IanUme]

Ahh great point @carstendev. I've only used the v4 version of Fragments (as they were the recommended way by Google even after native Fragments came out). I definitely think ViewPager would be a little tough to switch over to at the moment and I'm definitely down to add EdgeEffect only. As suggested, I think we should wait for issue #293 so we could possibly implement it without a support library (but I still really like the support libraries!).

[lognaturel]

Some notes from @seadowg about potentially making ODKView a Fragment which would make using ViewPager much easier here.