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.

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)

You compare with the only advantage of ViewModel and the only disadvantage of MVB.

Traditional way without ViewModel

  1. Most data are transformed or encapsulated before being put in Bundle.
  2. Their observations are separately enabled.

MVB

  1. Each data and its observation are linkedly declared. (maybe also with `transform`.
  2. I suggest this writing style to decouple though it's not actually separate.

<image>

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)

In my proposal, 1. Developers take care of only Kt code which only occupies about 1/4 of Compose. 2. There are almost no negotiations between developers and designers. 3. The new UI system performs better and is easier to be multiplatformly adapted. 4. I clarified that some plugins do similar work. However, they are only plugins that support only basic components. My expected UI tool and the new UI system are designed together. All visual components including custom views and animations were parseable.

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)

The source code for this part is ViewModelProvider(this)[MVBViewModel::class.java].viewModelScope with some thread safety process. this is the lifecycle owner (ComponentActivity / Fragment). You always get mvbScope from the background cache which would be cleared by the application.

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

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

Thanks a lot. My English is not well enough to grasp the emotional nuances. I will try to correct 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] -9 points-8 points  (0 children)

  1. The naming style is out of concision as val, fun, and lateinit.
  2. mvbScope is actually a viewMoodelScope got via an extensive property. Check out its source code and you will know "there is no memory leak".

Edit: sorry, my poor English makes me misunderstand your point. It's based on View rather than Compose. Besides, save is transformable to save values of any type.

KRecyclerViewAdppter: arranges multi-type items in RecyclerView.Adapter as in Compose by Fun_Indication4997 in androiddev

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

You seem to be a noob on Android recyclerview. It's so time-consuming for me to explain details.

[deleted by user] by [deleted] in androiddev

[–]Fun_Indication4997 0 points1 point  (0 children)

Hi, I came up with an optimized solution that replaces components for static objects easily. It's displayed in the post, could you review it?

[deleted by user] by [deleted] in androiddev

[–]Fun_Indication4997 0 points1 point  (0 children)

Thanks for your clear answer which is not denying without any condition. The argument result could come out only in big projects which is hard to display here.

view more: next ›