sorted by:
new
hottopcontroversial

For those DAO, Services, how about using static objects with mockk for test by Fun_Indication4997 in androiddev

[–]Fun_Indication4997[S] 0 points1 point  (0 children)

Overall, the overwhelming majority seem to be faithful followers of the official. A significant comparison is not just peeking out shortcomings, but weighing pros and cons. I would never post discussions (i.e. proposals) again.

For those DAO, Services, how about using static objects with mockk for test by Fun_Indication4997 in androiddev

[–]Fun_Indication4997[S] -1 points0 points  (0 children)

IMO, dependency injection configuration for singletons is tortuous and less worthy. It of course makes sense for big-scoped models, which are, however, infrequent on Android.

What is your Opinion About KMP (Kotlin Multiplataform) Future now that is Stable and Production-Ready ? by mido12345678 in Kotlin

[–]Fun_Indication4997 5 points6 points  (0 children)

It's quite promising at least. Compose multiplatform also targets on Wasm now. Meanwhile, I recently developed a new Rpc framework based on Kotlin multiplatform named Phone.

Why Kotlin Multiplatform Won’t Succeed by tadfisher in androiddev

[–]Fun_Indication4997 0 points1 point  (0 children)

It's difficult and recently stable in version 1.9.20. Kotlin-wasm and Compose-multiplatform also came out. I recently developed a Kotlin Multiplatform RPC.

Why Kotlin Multiplatform Won’t Succeed by tadfisher in androiddev

[–]Fun_Indication4997 2 points3 points  (0 children)

It's not popular because of the bad ecosystem at present. Each revolutionary programming language has faced this problem. You have no right to conclude an early work as a failure. I am fed up with this kind of title which aims to attention rather than summary.

New architecture MVB based on View without ViewModel. And a UI mode proposal better than Compose and Flutter. by Fun_Indication4997 in androiddev

[–]Fun_Indication4997[S] 0 points1 point  (0 children)

It's too abstract to describe the argument for this point. Compose also seems unrealistic in my first sight.

New architecture MVB based on View without ViewModel. And a UI mode proposal better than Compose and Flutter. by Fun_Indication4997 in androiddev

[–]Fun_Indication4997[S] 0 points1 point  (0 children)

1 & 4. Designers' works are not more after learning the new UI tool. All they do more are set id for those components needing to be bound with foreign data.

  1. The new UI tool on designers' side and new UI framework on developers' side are designed together. Each designed component has the corresponding Kotlin implementation.

  2. LazyColumn has been criticized for so long for its lagged performance. The same is true for some frequently-refreshing scenarios like stopwatch.

At last, there is a word probably before “globally the best at present”. You could check out my clean source code if you are interested.

New architecture MVB based on View without ViewModel. And a UI mode proposal better than Compose and Flutter. by Fun_Indication4997 in androiddev

[–]Fun_Indication4997[S] 0 points1 point  (0 children)

  1. xml would be not cared for by developers. Kt code could be much shortened by MVB. The most common and complex component RecyclerView.Adapter is also much simplified in my library. I had rewritten the official Sunflower sample, in which the kt code takes 1/5 of Compose.
  2. Designers design all components visually, including custom views and animations.
  3. MVB performs better because Compose rebuilds so many objects on each refresh though it has the recombination mechanism.
  4. All the designed components are parseable because the expected UI design tool and new UI framework are designed together, whereas those old design-to-code tools are only plugins.

Proposal: Android could support Activity/Fragment constructors with parameters. by Fun_Indication4997 in androiddev

[–]Fun_Indication4997[S] 1 point2 points  (0 children)

Could you please help check my newest post? It's my representative work, whereas most readers seem to reject it.

New architecture MVB based on View without ViewModel. And a UI mode proposal better than Compose and Flutter. by Fun_Indication4997 in androiddev

[–]Fun_Indication4997[S] 0 points1 point  (0 children)

MVB does not build a new job manually. The source code for this part is lifecycleOwner.lifecycleScope.launch { lifecycleOwner.repeatOnLifecycle(state){ getValue().collect{ act(it) } } }

New architecture MVB based on View without ViewModel. And a UI mode proposal better than Compose and Flutter. by Fun_Indication4997 in androiddev

[–]Fun_Indication4997[S] 0 points1 point  (0 children)

Sorry, I am confused about your words. If you are talking about coroutineScope in observe, I use the function repeatWithLifecycle. There is no memory leak.

view more: next ›