Hey guys, any github projects that can be a good learning resource for good architecture Mvvm prefer...

# android

[Nikola Milovic]

Hey guys, any github projects that can be a good learning resource for good architecture Mvvm preferably, DI, room etc..

[Jeremy]

https://github.com/android/architecture-samples

[Jeremy]

https://github.com/android/sunflower

[Jeremy]

https://github.com/android/plaid

[Pablichjenkov]

I think is valuable taking a look at these MVVM derivates:

Square*: https://github.com/square/workflow

Netflix: https://github.com/julianomoraes/componentizationArch

Uber: https://github.com/uber/RIBs

AirBnb: https://github.com/airbnb/MvRx

Chris Banes: https://github.com/chrisbanes/tivi

[Jeremy]

Agreed. The MVVM+ViewModel that Google promotes has tradeoffs

[Pablichjenkov]

That is correct, be careful with Google's naming.
Google named ViewModel a class that basically persist configuration changes like rotation. But it has nothing inside so you start building whatever you want on top of it.
The major confusion I see in Google's MVVM+ViewModel is that they treat Fragments as View where many people consider them as Controllers. Specially iOS developers usually map UiViewController to Fragment.
Seeing the Fragments as View is fine but then if you start using the Navigation Component. You see most of the samples out there they write Navigation Logic in the Fragments. Meaning your app is driven by Views. It shouldn't, an App should be driven by Business Logic, more scalable.
In my personal opinion and what I currently do is treat Fragments as Controllers. Well not really controllers. With the new Navigation API I treat them as Nodes in a State Machine. Each Node/Fragment of the Navigation Graph represents a State in a State Machine. The Nav Graph is my State Machine.
Of course there is a lot of workarounds on top of the existing API to make it to work the way it should. But Hopefully Google keeps improving the Nav Graph API in such a way where you can see it more like a State Machine.

[Jeremy]

Also getting ViewModel working in a MPP app is challenging

[Jeremy]

And the fact ViewModel don't handle process death so still dealing with fragment, viewmodel and app lifecycle

[Pablichjenkov]

What you mean by MPP app?

[Pablichjenkov]

Massive Parallel Processing?

[Jeremy]

multiplatform

[Jeremy]

I like your definition

[Pablichjenkov]

oh ok I got you. Yeah right

[Pablichjenkov]

It was the first that pop up from google 🙂

[Jeremy]

I think in next few years there will be a rethink of architecture patterns and libs if multiplatform becomes mainstream

[Jeremy]

The patterns and libs Google is promoting don't work in that ecosystem

[Pablichjenkov]

I do agree on that. Although not sure if Apple is gonna like it.

[Pablichjenkov]

Honestly Multiplatform sounds more like a Eutopic dream than a fact. It's been 10 years of mobile existence and still is on baby steps. Don't know adoption percentage these days but I don't think they any high.
Not even Flutter which is pretty decent has shown respect in the market.

[Jeremy]

Yes, but to be fair KN is fairly new and still in beta

[Jeremy]

KN is the first solution I've encountered that actually solves the problem in a pragmatic way

[Jeremy]

j2objc is the closest

[Pablichjenkov]

Well, I don't mean you can't run multi-platform code. That is not new, in fact you can compile C++ binaries that run on almost every platform out there but the Web. Then you can consume this binaries from the platform through the different APIs like JNI.
I think there is some work done for Swift too.
However, my point is a Unique Universal API or something closer to this concept. That is not gonna happen any time soon. We can get closer by writing a bunch of platforms adapters to wrap a Universal UI API, that's Flutter. But you still gonna get hit by performance issues and such stuff.

[Jeremy]

Flutter performance is good my issues were def interop with native platform

[Pablichjenkov]

Even making a single app that runs for iPhone and Mac is hard and you are talking about the same language and similar APIs.

[Jeremy]

Yes you def end up w/ a lot of abstractions to make it work

[Jeremy]

Best case maybe 20-50% of app code would be cross platform, maybe as low as 5-10%

[Pablichjenkov]

Don't have enough data but apparently Flutter performance is ok. I don't like their Widget based API though. I wished they had provided a plain main() function as entry point to the program and all the UI painting stuff as a separate library. The same thing for Android Framework though 😸

[Jeremy]

Wrapping the entire sdk and app into a common api is a pipe dream

[Jeremy]

UI greenfield apps in Flutter are ok but if need a lot of of platform api like legacy code, networking, notification, authentication it gets painful and death by a thousand cuts

[Jeremy]

Interop with platform in KN is much less boilerplate

[Pablichjenkov]

Humm good to know. Haven't experiment with it yet

[Jeremy]

Depending on type of app. Flutter is competing w/ mobile web not true native apps

[Pablichjenkov]

I got to put my Arduino and Raspberry pi to work these days 😁

[Jeremy]

I think all solutions can co-exist, no winner take all just like serverside

[Jeremy]

Python doesn't need to lose for Kotlin to win. Its a big world

[Pablichjenkov]

It is a big world right. Although there is always tech evolution. Learning from mistakes new languages get better and better. Then it starts replacing old ones little by little. Not sure if that statement apply for C and C++ anyways. But the reality is that modern languages look more similar each day and they copy each other good features.
There is always elephants in the room C++ and Scala 🤣

[alex009]

https://kotlinlang.slack.com/archives/C0B8M7BUY/p1569610522245500?thread_ts=1569604951.242200&cid=C0B8M7BUY
we already port viewModel to mpp 🙂 https://github.com/icerockdev/moko-mvvm
in our projects use, all good)