#metabrainz

[musicbrainz-server] 14mwiencek opened pull request #2821 (03master…mbs-12860): MBS-12860: Fix "Two relationships with the same key" error https://github.com/metabrainz/musicbrainz-serve...

[musicbrainz-server] 14mwiencek opened pull request #2822 (03master…mbs-12832): MBS-12832: Improve edit submission batching in the release relationship editor https://github.com/metabrainz/musicbrainz-serve...

akshaaatt: ping again

[listenbrainz-android] 14akshaaatt merged pull request #46 (03main…main): Feat: Added recently played music and feature to add favourites from music player. https://github.com/metabrainz/listenbrainz-andr...

[listenbrainz-android] 14dependabot[bot] closed pull request #37 (03main…dependabot/gradle/room_version-2.5.0): Bump room_version from 2.4.3 to 2.5.0 https://github.com/metabrainz/listenbrainz-andr...

hi akshaaatt

What’s up?

You wanted to discuss something right?

yupp

akshaaatt: about the app architecture

Tell me

so when glazing through most of the app

stuff isn’t done as per the architecture we ise

plenty stuff done inside activities composables

i also kinda realise why we shouldn’t use context

We just can’t conduct ui tests unless we abstract the whole app as per the architecture

The main enemy right now is sharedPreferences

why you may ask

because it uses context which we can’t mock if we want to make tests dependent more on the codebase itself

now this line might seem confusing

so lemme explain

usually i may test a composable by just declaring it

Let’s go step by step

testRule.setContent { MyComposable() }

yuss

What do you mean by “testing a composable”?

lemme login from from my pc hang on

I can already see the preview, I don’t need any more tests for the UI of the composable

no no

Go on

There's two ways we can test a screen (UI)

1) We just start the activity which is independent of external factors

or

2) We define limited contents of the activity inside our test and set the content of our activitys navitgation or composable

An app can’t be independent of stuff. Only components can be, but an activity can’t/shouldn’t be independent

like viewmodels

yupp

thats why i am going for the second approach\

2 sounds good to me

so

the problem here will be

if we just let our viewmodel run itll run into errors because tests are offline and some components should be mocked

so

we mock those components and instantiate the viewmodels

but still

Shouldn’t we use our mock viewmodels for these UI tests?

Right

No viewmodels shouldn't be mocked until necessary because

any change in the codebase then must be edited again in the mock

Think of it this way

that is not good practice but i wont say its not necessary

I have a button in my UI, which on clicked, makes a POST request using retrofit and returns me back a response, based on which, I decide whether to navigate that user to screen A or screen B

I need to test this navigation through my UI tests

I will have to make a mock viewmodel in this case because I won’t be able to make my request, right?

no

mocking the repository is enough for this

Alright

Sounds good

so now we are at viewmodel(mockrepo())

Also, it just clicked to me that these UI tests will run on emulators, right?

yes

Yes jasje_

so

now another problem still persists

as i mentioned

sharedPreferences

Sounds good

sharedPreferences require context

Yes

our Preferences object uses app.context which causes the app to crash

what i propose is

I’m pretty sure most of the apps use shared preferences. We can’t/shouldn’t get rid of them

since sharedPreferences are also "Single source of truth" as mentioned in the docs

What’s the solution then because we are not removing those

we move them to repository that we then inject to our viewmodel

Hmmm. That sounds doable to me

now you may ask

how does this help?

No I understand how it would help

We cant mock context

bbut we can mock repos

also another benefit is that

sharedPreferences would be collected in a good place that i dont need to import every now and then

Fair enough

This good so we move next?

Do you any github repos with the relevant architecture in mind to share?

I would like to have a look

Also, I would want us to restructure the codebase with proper folder structure

Unfortunately i don't have any such repos as of now

its just me

model

model as in preview of what it would look like?

Ui -> screens, components, entrypoint

Viewmodel

That’s the folder structure I’m thinking of

Utils

Services

Repository

These 6 should do for us

di

important

our di modules are scrambled right now

Hmmm. iOS doesn’t need libraries like hilt though I wonder

I was just reframing the arc I use for iOS in general

di should do for our android repo as wel

7 then

look look

for now the structure is good

most important thing is to

abstract sharedPrefs

then

create viewmodels for some features i was glazing through (best convert to compose)

No jasje_ the structure currently isn’t too clear because we have the ui and viewmodels all under the features folder

Even the data folder is messed up

Only a few people can understand the codebase rn

Converting the viewmodels to compose you mean jasje_ ? That doesn’t make sense

no no

the xmls to compose

Aligned on that

also

could you get the new guy to create a component of caching service?

which also includes auto cleanup

or we could just use a third party lib that does just that

Sure we should ask him

If you have any good third party libs in mind, let me know jasje_

i have just have to search them up again

will do in some time

https://youtu.be/JyUJZvJ-OV8 jasje

UI tests can get an activity/context jasje