Closed csehtamas closed 2 years ago
Understandable :) The issue is with null values themselves. This library aims at, and is built for not having to deal with nullable values from sharedpreferences, ever, because they do more harm than good. If you use sharedpreferences the way they are intended, you shouldn't need to deal with null values.
This being said, I acknowledge it would come in handy to have nullable methods. I'll see if and how they can be implemented in the safest way.
Yes, I saw that the aim of the project was to avoid nulls at all :) I hesitated to create this request because I had a feeling that it wouldn't fit into the project vision. The unfortunate thing is that since everything is handled internally (like deriveKey
), it's not possible to do this outside the library (except for that suppressed ugly thing I wrote :D).
However, I can understand if you wouldn't like to implement this because it would go against what you would like to achieve with this project.
I fear that from the moment I implement this, people would just default to pullOrNull
and will then incur in the same exact pitfalls this projects aims at ironing out.
If there is a way this can decently safely be implemented without major issues or nuclear teardown I'll do it. And thank you for your tact :)
Sometimes it would really ease the job if there was a method like
pullOrNull(key: String): T?
. The only workaround I've found is something like thisbut obviously I would like to avoid this :)