Deep linking

[MP0w]

Matrioska lets you build dynamic UI, this can make deep linking complicated since every Component doesn't have a fixed place and depends on the current structure defined by nested Components.
We want to support deep linking, defined in the model (and JSON #3) trying to not add logic for deep linking to the views or their ancestors (clusters, wrappers)...

• Create concept for deep linking
• JSON supports Deep link description

[joanromano]

@MP0w after brief discussion w/ @markushi & @ChristianOrgler we agreed on some features for this to be accomplished:

• Matrioska should allow the registration of deeplink ids on it's Components, most likely via JSONFactory.
• Each composed Component (Cluster or Wrapper) should be able to navigate until a specific Component from deeplink id, traversing the hierarchy.

For the deeplink id, not sure if this should be an optional associated value of each Component or, again, another kind of wrapper (same as Rule).

[MP0w]

Sorry no time these days because I'm still relocating

[ChristianOrgler]

Do we want to do the deep linking within Matrioska or do we want to give the developers the freedom to use their own maybe already existing deeplinking system?

So either we just provide a property(-ies) so each Component can identify itself or we fully integrate a deeplinking systen which would limit maybe other parts of the app which do not use Matrioska (or other apps ;-))

Because on the time of the deeplink is happening the UI is already built and we don't have the ComponentMeta information anymore, correct?

[joanromano]

@ChristianOrgler Components have always their associated children and meta with them, yes.

I think providing the ability to each Component which is not View to tell how to show a child should also work together with having your own deeplinking system, am I wrong? @ChristianOrgler why do you think it couldn't work?

[AndreasThenn]

@joanromano If I am correct, then we have the Component tree during the build process, but after we set the rootViewController, the UIViewController tree was created and is separated from the Component tree. In our current implementation, the Component tree is not even stored.
Deeplinks also have to work during runtime.
At the time we need to resolve deeplinks, the app structure might be different to the initial structure, depending on rule and maybe other factors.
I think this adds some complexity to the issue.

[joanromano]

@AndreasThenn yup, was aware of that. Since Matrioska only provides Components that produce ViewControllers I think it's up to the clients to use them as desired: nothing prevents you from retaining a Component for later usage.

I am afraid the only thing Matrioska can do is to, given a deeplink id, give a Componentthe ability to say how to show a child. But I didn't have a deep look into it, so maybe I am missing something.

[ChristianOrgler]

@joanromano we need the component meta data during run-time. So we can handle the deep link according to some outside factors as well.

We have two options IMO:

1. only provide ComponentMeta to the created Views so that each VIewController needs to handle the deeplink on it's own
2. The StackView or other ClusterViews can handle linking to childrens (so this step would be handled by Matrioska)

[AndreasThenn]

@ChristianOrgler I agree, how the app identifies a target ViewController, does not matter to Matrioska.
So we need to implement for the StackViewController the possibility to scroll to a specific child. Or at least make the scrollView of the StackViewController accessible from the outside.
For the TabBarCluster I don't see the need for now, since the resulting UITabBarController already has the option to set selectedViewController.

[ChristianOrgler]

So my suggestion would be to keep the addition we do to Matrioska as little as possible in terms of deep linking support. Components can have Meta information which can be used for deep linking. and we support (e.g. for StackVC or TabBar) to navigate to their children by maybe using the ComponentMeta for identification.

cc: @joanromano @AndreasThenn

[MP0w]

I agree with @ChristianOrgler we should provide some APIs that make it possible to implement deep linking with the standard & custom components. Otherwise everyone would have to use Matrioska's implementation and implement the same in every custom Component.

[joanromano]

@MP0w @ChristianOrgler yup, I think that's been basically the idea since the beginning 😄

[AndreasThenn]

I created a branch, to allow the StackViewController to scroll a child ViewController into the view. For the tabBar we can directly call selectedViewController. The selection of the targetViewController happens in the app itself, by using the meta information.
Any input on that, especially how to test it? @MP0w
Already had some issues when I added one StackViewController into another StackViewController.

[MP0w]

@AndreasThenn replied there, do we have to recursively try to select a component?
A component might be inside a stack inside another cluster that is inside another stack, etc.... not sure if stack only is okay.......

[AndreasThenn]

Thx @MP0w for the reply. For now its enough to be able to scroll to a specific child ViewController.
The Selection however has to be done by the app.
The idea: Our app Components support an internal routing protocol. With the information provided by the meta information, we can then identify directly the ViewControllers that support the target (e.g. DeepLink). So its completely open to everyone how to identify the target.
To make this easier I wrote an extension for the StackViewController, that checks for components that support our protocol. This requires the StackViewController to be public - would this be ok?

[MP0w]

I don't think that we should mess up with the views produced by the Components so they shouldn't be public, as we discussed in the other issue needs to be something that enable the use of the library to implement deep linking or focusing on one view. If we add stuff to that cluster (stack) like ability to scroll to another component, it shouldn't be an hacked solution I guess.
Eventually if you need any Component to be able to focus on a child you can require this with a protocol

[MP0w]

Regarding #17 I don't completely see how it can help with deep linking, the only thing I see is that it would enable a sort of selectedChild setting.
Can we have a plan for deeplinking and how is going to be shaped before starting the implementation?

[AndreasThenn]

The plan is to keep DeepLinking out of Matrioska. ChildSelection is just a step that has to be done before handling the deep link navigation.