Synthetic MviPresenter generated classes instances not GC cleared after Activity/fragment destruction about mosby

[sockeqwe]

Hm, need to check this more in detail but that issue is new or it broke because of missing androidx compatability.

[ruieduardosoares]

Not sure androidx compatibility is an issue because only the package name were changed from android.support to androidx.

But this is just a guess, I am only aware of what android documentation states

Also I have jetifier enabled so mosby byte code is change to access the correct package from android.support to androidx.

I want to continue to use this library and with a few tweaks I am able to use it with Android Navigation component by only using fragments.

Thanks for the reply.

[ruieduardosoares]

More digging i found out the INSTANCE might be a "constant" referenced somewhere that is the Synthetic class itself

See

I just hope this is not kotlin's fault.
Neither mosby, but i still dont know how is this happening.

[ruieduardosoares]

At first sight this seems to be the View interface object which is the fragment 🤔

But this is not possible because the subscription to View is being canceled when fragment is onStop().

And TakePhotoFragment already was GC

I can only see companion objects here

And the TakePhotoFragment$Companion doesnt have any reference to any presenter except to a TAG string field

[sockeqwe]

No idea what this companion object is. Do you use any kind of dependency injection or could share the source code somehow? Rui Eduardo Soares <[email protected]> schrieb am Mi., 9. Dez. 2020, 10:45:

…

At first sight this seems to be the View interface object which is the fragment 🤔 [image: image] <https://user-images.githubusercontent.com/13103244/101611862-f08bbc80-3a01-11eb-8974-6d3cf4a3e9f9.png> But this is not possible because the subscription to View is being canceled when fragment is onStop(). And TakePhotoFragment already was GC [image: image] <https://user-images.githubusercontent.com/13103244/101612064-2630a580-3a02-11eb-8a64-900f4b63be1a.png> I can only see companion objects here And the TakePhotoFragment$Companion doesnt have any reference to any presenter except to a TAG string field [image: image] <https://user-images.githubusercontent.com/13103244/101612695-d6061300-3a02-11eb-81c5-d79ea9b9f242.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#343 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEOPLVDR44NQA3LDYB7HRDST5BKXANCNFSM4UQLZ2PA> .

[ruieduardosoares]

The companion object is the one declared in the TakePhotoFragment, it only has a TAG property to use in logs.

There is no big issue with this companion object

My concern is only those synthetic classes from bindintent() method from the previous screenshots I posted, that have an object allocation for each view method.

Like I said, not sure if is kotlin or mosby the source of this issue, but the profiler is telling that those synthetic classes have one corresponding instance and are using 40 bytes on shallow size and 40 on retained size.

By themselves they are not referencing any other object in the heap, but are stuck there still don't know why.

They must be being referenced somewhere as the GC cannot collect them.

This is some dark magic.

I will need to dig more on this

[ruieduardosoares]

Checked kotlin issue tracker and found this.

• https://youtrack.jetbrains.com/issue/KT-34125

[ruieduardosoares]

Instead of using lambdas with SAM conversion, I will use object expression for the intent() ViewIntentBinder and check what happens

[ruieduardosoares]

My suspicions are true after all.

Converted all Lambda SAM conversions into object expressions making the code a bit ugly and larger
(Changed Android studio Theme BTW)

But after GC all previous synthetic classes instances are no longer allocated 😕

So this seems to by a kotlin issue rather than mosby.

[ruieduardosoares]

Now, to reduce the code size i will try to use Anonymous functions instead of Object Expressions and see if this also works

[ruieduardosoares]

And their are back with Anonymous functions 😢

[ruieduardosoares]

Never mind

The issue continue....