#metabrainz

akshaaatt: btw, did you want the Android updates shared to MeB social channels?

mayhem: don’t forget to look at my proposed press release re. metadata matters. Because it’s ‘spicy’ I want to run it by you before sending… https://docs.google.com/document/d/1ONWFAgDebp-...

“Press Release 2023-07-14 - The music industry is failing musicians”

🌶️

Anyone who cares: I’m going to start reposting stuff we put on Twitter via my personal mastodon account, see what the engagement is like (even if we never make an official account there I might just keep it up anyway)

Holiday news: Watched a national emergency go down here in Japan yesterday! Dog poo in the train station! Five employees, a gallon of disinfectant, and we are safe again - the offender is in newspaper, in a plastic bag, in another really big plastic bag, and safely disposed of. Great work tīmu

Last.fm x Spotify integration is apparently very bad? My takeaway: ListenBrainz devs kick ass + let’s make sure we never overextend: https://www.reddit.com/r/lastfm/comments/14y7qr...

Pretty nifty - apparently you can swipe right to scrobble a whole album (to last.fm) on this Discogs-centric app: https://apps.apple.com/jp/app/discographic-for-...

Sure aerozol! That sounds like a good idea

Akshaaatt: yus, let's do it! Fill out this form for me please, don't spend more than a minute on it, no need to fill in text just link to the blog post: https://community.metabrainz.org/t/breaking-new...

On it

sorry aerozol , I've now read it and damn, that quote is spicy. who wrote that stuff? Lol.

Looks great to me, fire at will!

akshaaatt: merge with main pls so I can work with latest main. Some bugs im facing that i want to make sure are not caused by my code.

if you want I can do it

man I wish they put in a quarter the effort japan does about dog-poo here. it's gross some places

Hi jasje

You had mentioned about a discussion on github

akshaaatt: will ping you outside rn

Cool

akshaaatt: yo

Hi

so

about the singleton annotation

Yeah

Any reasoning you have for removing it?

i would like you to give this one a read: https://dagger.dev/hilt/components

I have

Please point out the reason for the removal of

Omit of*

So basically when we scope all of our stuff to singleton

stuff -> dependencies

one instance is created

which reamins until app is destroyed

Yeah that is correct

since we have listen submitter service

which causes the app to never call onDestroy

those dependencies remain forever (metaphor)

thus memory is always occupied for those objects as long as onDestory isn't called

even though they aren't even being used

From my understanding, singleton just prevents the application from creating more than one instance and reuses the existing resources

How is it related to the lifecycle?

but it still retains the instance even though it isn't being used'

lifecycle is what the Installin() part defines

Even if I were to create multiple instances, do you mean to say that even those won't be destroyed?

akshaaatt: if we scope them to singleton, no

but any other should be good

I think service component should be the one to use here then?

usually hilt recommends don't scope bindings that don't require concurrency or are not heavy to create instance of

service component is used for brainplayer

yellowhatpro made sure of that

for rest

I think no scoping should be good

because hilt says

thus decreasing the performance

also

a component is only scoped if it has component and scope defined

if we just do Installin(singletoncomp){ // and not annotate @singleton here }

then the dependency wont be scoped

it'll be factory

i.e., new instance is created

everytime

I think the services we create should be scoped

this is very interesting to me and if you'd give some time figuring this stuff out i'd love to improve the code

Interesting read https://stackoverflow.com/a/39154297/14790459

bec my interpretations are half baked as well

Don't get too much into this rn. Focus on the gsoc project first

I feel we would end up falling off track with the project if you don't focus

These changes can be done in a day or two later

But yeah, I do think it'll be good

akshaaatt: dw

I don't think services should be allowed to have multiple instances, and the way I see it is scoping them currently or resuing somehow.

alright

first of all

lets call the repositories something else

Im getting confused with the android services again and again xD

so

Like?

in your above sentence, you mean the retrofit instances right?

Yes

yes

so we need to scope retrofit instances to something else

not singleton agree?

I don't agree yet. Need to read more on this

alright

But I know for sure that these should only be created once throughout the app

i mean we can

because retrofit is heavy'

but can we scope it to activity?

because our app is single activity arch

No. Multiple activities can use one service/repo

architecture

our app has only one activity

jasje we need to do something about it though. It's not perfect yet

yess

No. About, etc are separate activites for now

Compose is still new and we need to see what is the best practice for all this

akshaaatt: our main activity isn't destroyed when we open about tho

so no problem there

I hate that a composable cannot manage it's lifecycle yet

akshaaatt: true (fragments are noice)

yeah

our main activity only gets destroyed when we close our app

thats what we want

except for the service (retrofit instance) that our submitter uses

that should be singleton

Google should be working on getting compose right there. Because iOS has swiftui (jc counterpart) which does all of this perfectly

Not just the submitter, but other stuffs are also a singleton

yim service doesn't need to be singleton

Okay. That sounds fair

But social and login stuff does

social service also doesn't need to be singleton

only listensService is required to be singleton

for now it doesn't. But soon it will

how?

any future plans i don know hehe?

Let me just look at how service scoping and singletons are different

refer the screenshots above

for quick snippets

If the listens submitter were not there, singletons would have been fine for the app

akshaaatt: yes

But I get your point as to how resources are left even though the app is closed

I mean, if our app is single activity, we can scope all these services to the activity then

yes

But I am certain this is not how things are going to be for long. Single activity app in itself is bad currently.

akshaaatt: why?