Honor default preferences instead of using hardcoded defaults

[fgndev]

Contrary to the default preference value of 2000 iterations a hardcoded value of 1000 is used. Only after opening the settings dialog the 2000 iterations will become effective. I fixed it here. The 1000 default value is hardcoded into
app/src/main/java/org/secuso/privacyfriendlypasswordgenerator/activities/SettingsActivity.java
as well, even though it does not seem to have an effect here.
Both my Java and Android knowledge are very limited so far, so this is rather a suggestion that I basically copied from Stackexchange, so someone should look into this,

I strongly vote for turning the hash algorithm / number of iterations into per-account settings, too. I do unterstand that from a technical point those are rather per-device settings, but making them per-account settings would
a) serve as a reminder that those values actually effect the generated password (I know its in the docs, I'm leaning more towards practicality here)
b) Would allow to open the 'old password / new password' dialog as right now, changing the hash value 'corrupts' the entire db
but goes otherwise unnoticed
c) Users can choose to wait longer for the generated password if the use-case for that password is worth the sacrifice

[Kamuno]

I strongly vote for turning the hash algorithm / number of iterations into per-account settings, too. I do unterstand that from a technical point those are rather per-device settings, but making them per-account settings would

We actually discussed the same thing. So this will be done in the next update.

I'll look at your changes later :) Thanks for the PR

[udenr]

Sorry, I didn't see your PR before working on my changes in #50
I guess this PR is no longer needed then, or what were the changes to the dialogs supposed to do? was there also an issue?

[fgndev]

Sorry, I didn't see your PR before working on my changes in #50 I guess this PR is no longer needed then, or what were the changes to the dialogs supposed to do? was there also an issue?

Sorry for confusion, the changes to the dialog should have gone into a separate PR. The (perceived) issue here is that a generated password remains visible even after a lock/unlock cycle, if I remember correctly. This is arguably paranoia, but at least it should be configurable.