Hi all, was wondering what is the best approach to access android Activity context in a kotlin multi...

# multiplatform

[Alexandru Caraus]

Hi all, was wondering what is the best approach to access android Activity context in a kotlin multiplaform repository. So I have a repository interface in KMP, with an implementation in android sources, which should query the scoped storage, this means calling startActivityForResult with android activity context as parameter. The android application context is provided through di (koin) and the activity context cannot be provided the same manner since the instance is changed on rotation. How do you people approach such things?

[Blaž Vantur]

Even though it looks limiting that you can not straightforwardly access activity context wherever we want, it is actually really beneficial for us developers to rethink what we are doing when we end up with such a use case. Calling a code that needs activity context in the repository layer is not the best approach. The responsibility of the Repository should be only delegating data to and aggregating data from different data sources and mapping them(if you are following clean code guidelines) to an appropriate domain type. What you are describing should be done in the UI layer with the optional usage of a presentation layer. So the only place where you should call stuff that needs activity context is within the UI layer.
To the repository layer, you should already bring only the selected data then that you want to store to your database or maybe send through API call. In your case selected files in a type that you need for further processing.
You should avoid having dependency between repository and UI layer.

[Alexandru Caraus]

Yes, so one data source would require current activity context, to get the data I need in order to map it to the domain entities.

[Blaž Vantur]

How is your data saved and what is the code that will map your data to domain entity?

[Alexandru Caraus]

So my data is not saved, it already exists in the file system. I am trying to work with files, and the android scoped storage would not allow me to browse through files just having the File("sdcard/") handle, it shows me the directories but the content is empty. Now a way to do that is to start activity with Intent.ACTION_OPEN_DOCUMENT_TREE, that returns an Uri which allows me to run queries on this uri and extract the files info, and then map them to a tree structure, or any other domain object I want. So the challenge is to get that uri, which depends on a ephemeral activity, which can die while the repository is still alive, and if I will hold a reference to it, this is BAD 😄 . So the challenge is to get that data without holding the reference long term, that means not exposing it from the abstraction.

[Blaž Vantur]

I didn’t worked much with scoped storage and it was a long time ago when I did. I suppose that the result of starting activity with Intent.ACTION_OPEN_DOCUMENT_TREE is that Android system provides you with file picker UI dialog(or maybe whole screen picker), right?

If that is a case, you shouldn’t do that from Repository layer, but you should do it from UI layer where you have access to activity context. Because in the end opening of such pickers should be done after user perform some action usually after some button is clicked. So that part should be done in UI layer, and then collection of URIs that user selected should also be done in UI and Presentation layer.

Maybe it confused you that LocalDataSource should be responsible of providing local-based data to repository, but selecting which files/folder user wants to use within the app is completely different action and should be done in UI layer.

[Alexandru Caraus]

It's been a long time since I worked with FileSystem access in Android, and the things changed drastically this days. Yes definitely the there it is an entire new activity which lets me pick a folder, and surely, it happens in the ui layer. Just I want to abstract this process behind a data source, since according to clean arch the DataSource job is to provide data, which are the file tree in my case, and all this process depends on the activity and the clumsy scoped storage api. I understand the challenge and I am curious the approaches people take. What would be your approach?