Repeat Hierarchy Design

[joeldean]

Greetings everyone! So I am actively looking at the best methods that can be utilized to design the new form hierarchy/repeat group view. There's a detailed discussion over on the ODK roadmap repository that started the high-level conversation of how the functionality should work in theory.
So now it's time to look at the programmatic approaches that we can take to get this done.
@Shobhit_Agarwal did some really interesting work on this as well so @Shobhit_Agarwal you are a key person who can help me with making some of these decisions

Based on the mockup created by Tom Smyth, the general idea of the changes that needs to happen with the navigation is once you are on the screen with the list of questions and you click on a HierarchyElement then it should go to a separate screen/list that has all the items of that repeat group. Currently. when you do this the HierarchyElement expands and collapses so now the Children should be displayed on their own screen.

To go back to the main list you simply use the jump button that will allow you to navigate upwards in the hierarchy until you are back to the main screen.

From an Android API standpoint the approaches we could take modifying the way how the FormHierarchyActivity handles hierarchy navigation are as follows:

1. We could continue to use the same RecyclerView that has all the HierarchyElement models and then when we press a repeat element we simply set the current index of FormController to the repeat group and then the current list of HierarchyElement models that are powering the hierarchy list would be cleared and elements of the repeat group would be added so when the list is notified of changes it would appear that the app navigated to the repeat group itself. Of course, the refreshView logic would probably have to be modified to support this.

   n.b Currently, I am not too clear on what happens within that function in its totality so I need to use some breakpoints to figure that out, but for sure I can see that it's very important with handling the different types of indexes and such forth.

2. We could set the current form index and spawn a new FormHierarchyActivity' that would then only display the repeat` elements within the list if the logic is customized as such. What I like about this approach is that it would be visually obvious to the user that they are navigating to somewhere else i.e deeper into the form due to the new activity transition taking place on the screen. Also, we would be able to tie into the Android back stack to navigate up out of the whichever depth the group is currently at. The drawback is that we would be spawning a lot of activities for a really big form.

3. We could use Fragments in a ViewPager. So each fragment would basically represent a depth of the form and each time the user clicks a repeat item a new fragment is added to the ViewPager.

These are just some general ideas! I will update this some more as I delve deeper into how this can be done but I just want to get the discussion started so we can all contribute to this important change!

[LN]

Great to see this getting under way!

It seems the last option you mentioned (Fragments in a ViewPager) is the more idiomatic way to go when it comes to modern Android (at least as recommended by Google). It also leaves open the possibility of eventually adding a tablet-friendly view that does something like display the different levels side by side rather than on new screens.

What I like about [the new Activity] approach is that it would be visually obvious to the user that they are navigating to somewhere else i.e deeper into the form due to the new activity transition taking place on the screen.

This would be the case with Fragments as well, right?

we would be able to tie into the Android back stack to navigate up out of the whichever depth

This also seems like it's the same with a Fragment-based approach.

drawback is that we would be spawning a lot of activities for a really big form.

Whether it's Activitys or Fragments, their count will be determined by the maximum depth of repeats in a form, not the form's size, right? That is, a form with three levels of nesting would result in at most three levels even if it has 3000 questions. In practice, it's not common to have more than 2 levels of nesting as far as I know. I don't think this needs to be a concern.

As far as I know, the Activity vs. Fragment question has been contentious in the Android world but is recently less so as Google has been more vocal about building single-Activity apps and going all in with Fragments to enable tablet layouts and the like. Collect has moved more towards using Fragments so doing so here would be in line with that move. Have you also explored some of the new Android architecture recommendations and libraries like the Navigation Architecture Component?

[joeldean]

Thanks for the response @LN

@LN

This would be the case with Fragment s as well, right?

Yes it would!

@LN

In practice, it's not common to have more than 2 levels of nesting as far as I know. I don't think this needs to be a concern.

Awesome! Good to know!
So yes, I am in favour of the fragments approach as well!

@LN

Have you also explored some of the new Android architecture recommendations and libraries like the Navigation Architecture Component?

Yes, I have seen what Google has been pushing via Android JetPack. I am gonna explore it in more detail and see if it's something that we could utilize to accomplish what we want. I am gonna weigh the benefits vs cons here when I get it to it!