Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bulk Set/Observe #46

Open
Maradox opened this issue Jun 8, 2016 · 6 comments
Open

Bulk Set/Observe #46

Maradox opened this issue Jun 8, 2016 · 6 comments

Comments

@Maradox
Copy link

Maradox commented Jun 8, 2016

Is it possible to bulk set/observe several values?

For example I have one string and two enums, which I set at the same time.
Currently this causes as to be expected three emissions (I use combineLatest) .

Is there a way to delay the apply so all three values are set together, and observe this set as a whole, while still using different datatypes?

@JakeWharton
Copy link
Contributor

Not at present.

A quick way to work around this is to debounce the notifications by, say,
100ms.

On Wed, Jun 8, 2016 at 12:06 PM Martin Perebner [email protected]
wrote:

Is it possible to bulk set/observe several values?

For example I have one string and two enums, which I set at the same time.
Currently this causes as to be expected three emissions (I use
combineLatest) .

Is there a way to delay the apply so all three values are set together,
and observe this set as a whole, while still using different datatypes?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#46, or mute the
thread
https://github.com/notifications/unsubscribe/AAEEET8amUECAZpPol6NKnwK6Pzxdh_Kks5qJuiEgaJpZM4IxIRP
.

@bemusementpark
Copy link
Contributor

If you can guarantee they are always set together you can use zip.

Otherwise you could consider storing them as one object or String, perhaps as JSON.

@Maradox
Copy link
Author

Maradox commented Jun 13, 2016

Thanks for the suggestion, but I can't use zip, since if one of the fields is overwritten with the same value, it won't emit an item, and thus zip won't work.

@bubenheimer
Copy link

TL;DR: rx-preferences drops atomicity of multi-preference commits.

If I need atomicity I'd want access to the wrapped SharedPreferences object to use the standard Editor builder approach. However the object is not visible; I'd have to keep track of the original SharedPreferences object separately.

For the time being I am forking the project to give me the customizations that I need - I find rx-preferences very useful otherwise. Sadly I doubt that my changes (besides the trivial object visibility change) would be acceptable to this project, as they are not very "reactive".

@PaulWoitaschek
Copy link
Contributor

If they really belog together, just create a model class that holds these 3 values and store that.

@saket
Copy link

saket commented Nov 8, 2018

@PaulWoitaschek Using a model sounds like a good solution, but you that introduces different kinds of problems. For storing models into SharedPreferences, you'll have to serialize them in some manner. If the models ever change, you have to ensure you don't forget to handle the migration. If you start writing migrations, it might just be a better idea to store them in a DB so that your database abstraction (Room for e.g.,) complains if you forget to write a migration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants