I am starting to have mixed feelings about this. It feels like I either have chosen the wrong technology or there is something wrong with me.
Had to drop support to every other platform and only working on the
commonMainandandroidMainsource sets (so what’s the point of KMP after all?) and still the app is not on par with purely native counterparts (main pain points: navigation, l10n, image loading/rendering, video players, markdown rendering using Compose multiplatorm, resource access especially for typefaces, using mocks in tests, and the list could go on…).Maybe Compose multiplatorm is the real culprit but God, have mercy on me please…
Uh-oh heretic spotted. Recant everything you’ve said or I’ll make you justify every line of your manifest to a robot!
I hoped to be burned alive like in the good ol’ times.
I hereby sentence you to writing exception handling code in viewmodels with the following requirements:
- exceptions may be native
- exceptions must be defined in separate modules for Clean Architecture
- all calls to native methods must use callbacks for Objective-C compatibility
- you must launch a separate coroutine when rethrowing some (TBD) exceptions to prevent the exception from being caught by a parent other than the root exception handler (or the calling thread!)
- you must use ViewModelScope except
when writing to SharedPreferences - you should be using DataStore, heathen
wtf man
That was painful even to read…
throw NotReadingThatException
based
So this is why they dropped multiple flutter devs from the team. RIP Flutter!
I see this as a positive for Flutter. Android tends to publicly execute its favorite libraries and ignore the ones that actually work properly.
I called it in the layoff announcement and people said I was crazy
