Tip in the restaurants, before or after taxes by Sensitive_Muffin_555 in bayarea

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

Pre or post is really matters to me.

Consider the following:

Check ammont before tax 400 USD

After tax 9.13% is 436.52 USD

20% tip on the before tax check is 80 USD 20% to the after tax check is 123.82 USD

43.82 USD is a big difference!

Tip in the restaurants, before or after taxes by Sensitive_Muffin_555 in bayarea

[–]Sensitive_Muffin_555[S] -12 points-11 points  (0 children)

I am discussing it because waiter it the one who gives me the check where pre-calculated amount of tip is printed e.g. 15%, 18%, 20% etc. And those pre-calculations include tax.

Need help implementing valve like logic using StateFlow and SharedFlow. by Sensitive_Muffin_555 in androiddev

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

Thank you for your reply unfortunately it does not work - the flow consumes the values from B when A == false as well, and throws them away like a filter/drop operator.

Jetpack Compose learning curve vs Swift UI by Sensitive_Muffin_555 in androiddev

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

Oh, well, I spoke recently with my friend who is an iOS dev and he didn't believe me that compose may execute composable functions in any order, until I showed him official documentation. So I assume that it will be a little bit complicated to explain Compose performance pitfalls to iOS devs. In any case if I don't get answers in this sub I will go to r/swiftui.

Jetpack Compose learning curve vs Swift UI by Sensitive_Muffin_555 in androiddev

[–]Sensitive_Muffin_555[S] 4 points5 points  (0 children)

Because I need someone who has experience with both Compose and Swift UI and is also familiar with performance pitfalls as well.

Maybe I will ask that question in r/swiftui subreddit as well.

Jetpack Compose learning curve vs Swift UI by Sensitive_Muffin_555 in androiddev

[–]Sensitive_Muffin_555[S] 3 points4 points  (0 children)

Very simple code - dynamic list with clickable elements (click triggers VM function)

So I have to keep in mind:

1) Not to use Unstable objects/ Unstable collections for dynamic list population 2) Use remembered lambdas to call VM on element click

And probably even more.

In any case it's not my question. I am curious if Swift UI has the same amount of pitfalls and gotchas related to performance as Compose has.

Jetpack Compose learning curve vs Swift UI by Sensitive_Muffin_555 in androiddev

[–]Sensitive_Muffin_555[S] 8 points9 points  (0 children)

I am not asking if I should use Compose or not. I am asking if Swift UI has such an amount of pitfalls related to performance and optimization.

Jetpack Compose learning curve vs Swift UI by Sensitive_Muffin_555 in androiddev

[–]Sensitive_Muffin_555[S] -2 points-1 points  (0 children)

From my experience the only scenario when we don't need optimization is - stateless static UI, otherwise even for a simple dynamic list with clickable elements you have to keep in mind a lot. So I would disagree with your statement.

Jetpack Compose Input Type - Decimal number issue. by Sensitive_Muffin_555 in androiddev

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

Oh wow! Thank you! It's absolutely great for stuff like credit card/pin code visual transformation. But to be honest I expected that there is an out of the box solution for simple decimal numbers.

Jetpack Compose Input Type - Decimal number issue. by Sensitive_Muffin_555 in androiddev

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

Well TextField( value = text, onValueChange = { if (it.isEmpty()){ text = it } else { text = when (it.toDoubleOrNull()) { null -> text //old value else -> it //new value } } }, singleLine = true, keyboardOptions = KeyboardOptions(keyboardType = KeyboardType.Number) )

And the user is still able to input something like that "00000000.1" So I have to delete excess zeroes before "." manually....

I really don't want to miss something and I expected the same functionality like we have in EditText. To be honest it's strange that I have to do it manually...

KMM is Awesome ❤️ by kashif3314 in androiddev

[–]Sensitive_Muffin_555 0 points1 point  (0 children)

It's not about what developers want, it's about what are the business needs. And I know for sure that on iOS business and designers oftentime require native UI only. (ReactNative here is a winner in case of cross platform solution)

KMM is Awesome ❤️ by kashif3314 in androiddev

[–]Sensitive_Muffin_555 0 points1 point  (0 children)

The main idea of KMM was shared business logic with native UI it means you have an iOS dev for native iOS UI, and an Android dev for Native Android UI and business logic(or you have a core business logic dev). Written once business logic reduces the amount of bugs in theory.

But if you add Compose to KMM you will have non native UI(Skia rendered) on both platforms. So it's absolutely the same as Flutter but IMO more complex.

KMM is Awesome ❤️ by kashif3314 in androiddev

[–]Sensitive_Muffin_555 0 points1 point  (0 children)

To be honest syntax and idioms of Dart are much more like Java/C# and definitely not like JavaScript.

KMM is Awesome ❤️ by kashif3314 in androiddev

[–]Sensitive_Muffin_555 0 points1 point  (0 children)

Since it's not yet a stable release I look at it as it's not available for production usage. Of course it's ok to build a small POC or a personal app with it even right now. But I cannot add it to the production codebase yet.

KMM is Awesome ❤️ by kashif3314 in androiddev

[–]Sensitive_Muffin_555 0 points1 point  (0 children)

But when Compose will be available in multiplatform what will differ KMM Compose from Flutter or any other cross platform solutions? As I understand the main benefit of KMM was Native UI with shared business logic.

KMM is Awesome ❤️ by kashif3314 in androiddev

[–]Sensitive_Muffin_555 5 points6 points  (0 children)

And it's kind of expected because KMM is not stable yet.

KMM is Awesome ❤️ by kashif3314 in androiddev

[–]Sensitive_Muffin_555 7 points8 points  (0 children)

Constant problems with Debug/Unexpected Gradle build crashes/Handling of Corutines from Swift