Repository update interval (#158)

This is issue #158 (closed) https://gitlab.com/fdroid/fdroidclient/issues/158

I have modified the update interval to include "weekly" and "Every 2 Weeks" and removed "Hourly" as update frequencies. THe maximum interval was daily which was still too often for me. I have removed "Hourly" as you probably have to pay for your bandwidth and that is insanely often :-). Every 4 hours should still be plenty often.

2 Languages did not have the right amount of options there anyway, and I fixed those.

Please check, test, judge and ... hopefully ... merge.

I use hourly. It's not insane, it uses almost no bandwidth, it simply has to do an etag check.

OK, fair enough. Would just providing a "Weekly" and "Bi-weekly" option be acceptable?

I have no objection to the longer options. I'm not sure it would be a good idea for someone to use them (would someone want to go two weeks without a critical security update for something?). But I'm all for choices - maybe someone knows they haven't installed anything via F-Droid where security is a potential problem, for example.

My wife gets nervous if there are too many popups. And I don't need to update the Terminal app daily either :-). Will update the push request.

One other thing, no need to change the localised arrays, they'll get updated automatically. Only the English needs changing. (We should probably have a "don't change these files README in there somewhere).

The two languages with missing values is due to a bug I'd forgotten about (issue #152 (closed)) - thanks for the reminder. :)

Funny, my wife completely ignores them. Last time I looked at her phone, I had to upgrade it from something like version 0.40 of the F-Droid client. (And you should set the terminal app to 'ignore all updates' - at least until we fix #122)

Added 1 new commit:

• 1895d2f9 - Allow to check repositories less often

Thanks. This looks good to me. I'll leave it a short while before merging in case anyone else has anything to say...

Sounds good to me.

Thanks @sspaeth, looks good. @CiaranG - do you have any ideas about a way to prevent this problem of the Android code relying on string-array-resources which are not checked at compile time (other than by lint) causing fatal errors?

After a quick internet search, my inclination is to do the following:

• Only put string arrays in values/no-trans.xml
• Make each entry point to a string value (like this)

This way, any non-translated strings will revert to the default English translation until it is translated - exactly like any other string.

My only question is how to migrate the current two string-array's in F-Droid to this, without busting the translation system. I could do a single commit which refactors all the values from the relevant values-*/arrays.xml into their respective values/strings.xml if you'd like. Would that break things, or owuld the translation system then work as expected after commiting that change? I'd of course need to notify people on the translation forum so they don't think I've nuked all their good work.

Glad you like it. By the way, does fdroid honor the "background sync" option that one can set system wide? Right now I have disabled background data for fdroid (I don't want to spend precious 3G data with fdroid), but that is a rather brutal solution. If yes, sorry for the noise. If no, would that be tricky to implement?

@CiaranG, is the short while over? :)

@pserwylo There's not really a need to prevent that, the translation system is supposed to handle it.

Status changed to merged

@CiaranG: Could you please elaborate on what you are referring to? I'm unsure if you are suggesting to "don't worry about putting string arrays in no-trans.xml", or "don't worry about migrating the existing translations - the media-wiki translate system will deal with it after moving to no-trans.xml".

If the former - I'd agree that the translate system does handle this to some extent (e.g. through lint errors), but that is a big difference from compile-time errors and also the inability for people to specify the wrong number of translations.

If the latter, I'm not sure I understand.

I'm still keen to do what I've described above, because there have now been at least two bugs in my memory caused by this.

@pserwylo I mean it's specifically coded into the stuff that pushes translated arrays back to the client source code that the arrays sizes will match those of the English version. Specifically, for example, if there is an array with 5 entries, and only two get translated, it should be pushing back an array with the two translated entries, and the other three also there, but with the non-translated text.

(The first time this happened, there was no such system. This time, something has gone wrong with it, which needs looking into.)

Ah, I understand. I will not worry about this any more :) Thanks for the info.