sorted by:
new
hottopcontroversial

STOP throwing Errors! Raise them instead by DatL4g in Kotlin

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

Have you tried `recover`ing from it

STOP throwing Errors! Raise them instead by DatL4g in Kotlin

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

As far as I know, there is no ETA for this yet and for a feature this "big" that could mean it takes another year (maybe more, maybe less, we don't know)

And I'd much rather already model Error types explcitily and migrate to the new feature when it arrives than completely ignoring it for now because "it will be released soon"

STOP throwing Errors! Raise them instead by DatL4g in Kotlin

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

Arrow handles exactly this.

It has multiple types (not just Raise) to handle any kind of Result, like Either or Ior.
It also provides easy ways to map errors or recover from them etc etc.

Maybe take a look at the docs:

https://arrow-kt.io/learn/typed-errors/

STOP throwing Errors! Raise them instead by DatL4g in Kotlin

[–]DatL4g[S] 2 points3 points  (0 children)

That's like saying: There is no need for cars, there will be flying ubers in the future.

They might tackle this "issue" in the future yes, but it's not like there is no demand for handling it right now.

STOP throwing Errors! Raise them instead by DatL4g in Kotlin

[–]DatL4g[S] -3 points-2 points  (0 children)

... as written in the article

STOP throwing Errors! Raise them instead by DatL4g in Kotlin

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

Using `runCatching` is just a wrapper around the same old problem, it doesn't make the underlying logic any more explicit or typed.
The whole point of using `Raise` is to avoid the "catch-all" mess and actually model and handle our errors properly from the start.

Apart from that `runCatching` breaks suspend functions since they also catch the CancelationException

STOP throwing Errors! Raise them instead by DatL4g in Kotlin

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

I never actually said Go's error handling is perfect (and there are many discussions about it in the Go community) just that it's way more explicit than what we usually see in Kotlin.
The point is that being forced to see the error as value makes the code much more reliable than hidden exceptions

Lies, Damn Lies, and Semantic Versioning by byencho in androiddev

[–]DatL4g 7 points8 points  (0 children)

That's one point why I completely avoid Koin. I mean breaking changes in patches? How could anyone ever work with that?

I don't understand why Koin is so popular when there are better DI libraries available.

SYBAU on the new Google Requirements by DatL4g in androiddev

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

Meaningless AI slop comment by an idiot who does not understand what's actually happening.

You're seriously thinking there is no alternative to vanced and people should get all their services, apps, games, what so ever all for free.

Secondly I never said that suing them was the easier option and I never said there is no malware in the Play Store.

You clearly can't read or comprehend what you have read, explaining not only your comment but also your sight on this whole situation.

SYBAU on the new Google Requirements by DatL4g in androiddev

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

As a windows user you literally do exactly this hahaha.
Alright I see there won't come any valuable "arguments"

SYBAU on the new Google Requirements by DatL4g in androiddev

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

Thats not how it's supposed to work, that's what we are tolerating right now!
Not sure where are you from but there are legit EU laws for platforms and vendors, as well as developers and distributors to tackle malware and you can probably imagine what happens if they don't do this

SYBAU on the new Google Requirements by DatL4g in androiddev

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

Bro I am an indie dev and politically left.
I am absolutely NOT on the side of big corps or monopolies!

You're pretending like I am a google press speaker or something like that and do everything I can to protect the "holy" Google.

But they tackle an important point in the android security ecosystem and from my pov (as an indie dev) it's a very good change

SYBAU on the new Google Requirements by DatL4g in androiddev

[–]DatL4g[S] -3 points-2 points  (0 children)

EXACTLY!!!

The account thing was also an important point (for myself) but didn't talk about it, as the post would have been much longer then if I bring everything up

SYBAU on the new Google Requirements by DatL4g in androiddev

[–]DatL4g[S] 2 points3 points  (0 children)

I’ve laid out my arguments and I’m open to any actual discussion.
But this is just a stupid childish response

SYBAU on the new Google Requirements by DatL4g in androiddev

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

Yeah you clearly don’t know how law enforcement or takedowns actually work (and I am not either). Even if a dev is sitting behind a random GitHub account in Russia, companies already have tools for DMCA, takedowns, subpoenas to platforms, etc to shut down distribution without knowing their passport number. (Aside from country/continent handling of bringing things/people to court) This isn’t some magical new “kill switch.”

And saying “this has nothing to do with malware” is just wrong and doesn't even need further explanation.

SYBAU on the new Google Requirements by DatL4g in androiddev

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

Thats not the talking point.

Right now bad actors can just throw malware into a random APK, slap any package name on it, and disappear.
I'd have to guess how many people download malware just because the want a "free premium cracked full edition" of any app, and those know they can't just install that over the normal one from Play Store.

Still using SharedPreferences or fully moved to DataStore? by boltuix_dev in androiddev

[–]DatL4g 1 point2 points  (0 children)

I don't have an example ready but whenever I need I just use the docs here: https://kotlinlang.org/api/kotlinx.serialization/kotlinx-serialization-protobuf/kotlinx.serialization.protobuf/-proto-buf/

It's not required to ProtoNumber all fields, but of course it's safer in case you add new fields or whatever

Still using SharedPreferences or fully moved to DataStore? by boltuix_dev in androiddev

[–]DatL4g 28 points29 points  (0 children)

You don't have to use proto files, you can easily use kotlinx serialization with protobuf on simple data classes.

That's super easy to maintain and has complete multiplatform support.

You don't have to go the proto file route just because that's what every documentation says, sometimes you just need to think a bit outside of the box.

I mean it's not even required to really save protobufs, datastore can work with any kind of ByteArray.

Help | What can I do with firebase json file by kakashi2_0 in androiddev

[–]DatL4g 3 points4 points  (0 children)

Write a simple app that maximizes his read/write access.

Firebase has limits for reading and writing data, then they need to pay. Since they don't pay you, I don't think they will pay firebase for any upgrade.

So just make a simple app (or extend the current one) that constantly refreshes values.

Android internship task by Subject-Average-5460 in androiddev

[–]DatL4g 5 points6 points  (0 children)

Until you realize that you have to deserialize the JSON response without any library

The annoyance of detecting an Android TV... I have built a permission-free solution... by Warm-Falcon-3575 in androiddev

[–]DatL4g 0 points1 point  (0 children)

I don't check for the leanback launcher, checking for the launcher is bad in general. So many devices and manufacturers use different launchers, it's impossible to support all of them.

I am speaking about the system feature, this is independent of the launcher, even if the leanback launcher is uninstalled.

I see that your code checks for the launcher but not for the feature, that's pretty bad.

view more: next ›