Been playing with Metro, great so far!

🤔 interesting 🧐

I am on the mobile side and for this past month I have seen a lot of openings. Many are asking for multiplatform stuff like RN, KMP and Flutter but pure native as well. It seems that is picking up after a long time being very slow

🙌🏻🙏🏻

😆👍🏻

👌🏻

Lmao 😂

👌💯

👍

I agree 💯, so in terms of time I would say pre-2017 and post-2017
The game changed 180 degrees.

You said migration of massive codebase. Sorry but this is the last thing I would use AI for. My life as a Soft Eng has circled around this subject and I tell, is really complex and you can mess up badly.

A sad reality no software company wants to face.

Sounds like a must to read

🔥

😅

They too expensive for the average consumer but as a product is great

Wise move

It seems like Flutter, Avalonia and RN are on "check mate".

😍

The official docs don't say much about nested or recursive modules.
Is it supported more than one level of project dependents.
P1 -> P2 -> P3, if P1 includes P2 and P2 includes P3. Will all be merged when I publish P1? It wasn't clear to me what happens in this scenario.

Nested NavDisplay please

🔥

Gotcha

Oh you mean announcement in the post, I thought it was release 1.0 date

So it is 2 years older than compose.

Not just mock it but unmock it. If you forget to unmock it could cause issues in the next test.
I believe even people from the JB team has mentioned object and companion objects were a mistake. They didn't want to do it but were forced to, basically for java compatibility and java influence.

Which is a good thing. However, when you use an actual Kotlin "object" is not remotely the same. An object is accessed directly with syntax MyObject.funcionX(), there is no injection here. So your class is strictly depending on the object function. And you can only mock it as I described previously.

Right but let's make a clarification. A Singleton in a DI framework isn't the same as a plain object singleton. There are implementation details that matter.
As you said in Spring, you "inject" the instance. The word singleton here means the scope of the instance but you are actually injecting it.

So code outside the class has to be aware of what is used inside the class.
Is the same problem of using singletons at the end of the day.
You can do a research on it. There is rich information about this subject.
Why singletons, objects , companion objects are bad for testing

First, it is hidden from outside the class. So is not evident you need to mock these 5 companion objects since they are not part of the class inputs.
So now in every test, you have to mock and unmock these 5 objects.