Client merge requestshttps://staging.gitlab.com/fdroid/fdroidclient/-/merge_requests2015-04-15T21:29:31Zhttps://staging.gitlab.com/fdroid/fdroidclient/-/merge_requests/67Change some "defaultValue"s2015-04-15T21:29:31Zusername-removed-124398Change some "defaultValue"sKey "theme": I also use the dark version of F-Droid but I think the most users would prefer the light version. This is also standard in the
most used apps on Android, I think, see GApps, Flym, K-9, Telegram, ...
Key "localRepoBonjour...Key "theme": I also use the dark version of F-Droid but I think the most users would prefer the light version. This is also standard in the
most used apps on Android, I think, see GApps, Flym, K-9, Telegram, ...
Key "localRepoBonjour": I never used this function and I think it's better, if the user manually activates it when he wants to use it.
Key "localRepoHttps": I see no reason why it should not use https over http, it's better of security view, I think.
Key "cacheDownloaded": The most smartphones today have enough storage available to allow to enable this function. This would decrease the
traffic on both sides, as the user does not have to download a app and the F-Droid server does not have to send it multiple
times.
This is somehow related to #221, I think.https://staging.gitlab.com/fdroid/fdroidclient/-/merge_requests/101simplify RepoUpdater and use more streams2015-07-13T20:50:54Zusername-removed-24982simplify RepoUpdater and use more streamsThis is an overhaul of `RepoUpdater` to make its code match the architecture that is in use now: only download and use a signed index.jar. It also streams index.xml directly out of the index.jar and directly into the XML parser. That m...This is an overhaul of `RepoUpdater` to make its code match the architecture that is in use now: only download and use a signed index.jar. It also streams index.xml directly out of the index.jar and directly into the XML parser. That makes the update process quicker and more reliable because it no longer has to write out an index.xml to the filesystem, then read it in. Ultimately I hope to stream the index.jar download directly to the XML parser, so not even the index.jar needs to be written to disk. You can see that work in my git repo under the branches SKETCH-JarURLConnection and SKETCH-verify-with-JarInputStream for two different approaches.
This also changes the index parsing process to be based on bytes for now. The progress is based on the stream now, and this will still work once the full streaming mode is implemented. It also simplifies `RepoXMPHandler`.
This includes tests for index.jar signature verification. The tests all pass on my machine and our Jenkins.0.95username-removed-25042username-removed-25042https://staging.gitlab.com/fdroid/fdroidclient/-/merge_requests/112Prompt for beta updates2015-08-09T18:33:21Zusername-removed-124398Prompt for beta updatesReady to get merged. :+1:
~~This MR is ready to get merged, the last thing that needs to be fixed is [this](https://gitlab.com/fdroid/fdroidclient/commit/72ed814a739b15c62868a72fc835aedea22409e3#note_1726274).~~
This closes #313.Ready to get merged. :+1:
~~This MR is ready to get merged, the last thing that needs to be fixed is [this](https://gitlab.com/fdroid/fdroidclient/commit/72ed814a739b15c62868a72fc835aedea22409e3#note_1726274).~~
This closes #313.https://staging.gitlab.com/fdroid/fdroidclient/-/merge_requests/177Search as the user types2015-12-16T11:50:37Zusername-removed-25042Search as the user typesFixes #323.
This does away with the separate `SearchResult` and instead applies the search to the currently viewed tab on the main screen (Available, Installed, Updates). When filtering the Available list, it filters the currently sel...Fixes #323.
This does away with the separate `SearchResult` and instead applies the search to the currently viewed tab on the main screen (Available, Installed, Updates). When filtering the Available list, it filters the currently selected category.
Note however that there are still times when the old style `SearchDialog` will be shown over the top of the action bar rather than the `SearchView` within the action bar. These times include:
* When a user with a hardware keyboard starts typing from the main screen.
* On older devices with a "search" hardware button.
* Probably some other cases (I think when there is not enough screen real estate, but haven't seen that happen).
In cases where this dialog is shown, filtering the lists as you type does not seem to be an option. I tried to figure out how to do that, but failed. If someone else figures it out, that would be great. However, when the search is submitted, it will hide the `SearchDialog` and populate the `SearchView`, focus it, and apply the search appropriately.
There is a script in the `F-Droid/tools/` subdirectory which will consecutively send various intents to F-Droid relating to search. This includes Play, market, Amazon search links. For good measure, I also made it send intents to do with viewing app details. This should probably be made into a proper instrumented test at some point, but I didn't have the time to figure out how to do that. Maybe a project for future @pserwylo.
One unknown is the performance implications. There is no problems on my Nexus 4 with Android 5.0. My Chinese/ebay/$30/Android 2.3.4 device seems good enough too.https://staging.gitlab.com/fdroid/fdroidclient/-/merge_requests/297Add template for e-mail2016-12-12T17:37:25Zusername-removed-124398Add template for e-mailSubject: [App] on F-DroidSubject: [App] on F-Droidusername-removed-22388mvdan@mvdan.ccusername-removed-22388mvdan@mvdan.cchttps://staging.gitlab.com/fdroid/fdroidclient/-/merge_requests/416WIP: modernize update scheduling2017-09-29T13:50:14Zusername-removed-24982WIP: modernize update schedulingThis is just the first step towards modernizing the scheduling of updates, including index and auto app updates. Android 5.0 introduced `JobScheduler` which will try to opportunistically schedule jobs based on whether the device is idle...This is just the first step towards modernizing the scheduling of updates, including index and auto app updates. Android 5.0 introduced `JobScheduler` which will try to opportunistically schedule jobs based on whether the device is idle, there is good wifi, its connected to power, etc. This can help us drive the update process entirely to when the device is plugged in, connected to the home wifi, and idle.
The annoying part is that this requires putting the work into a new `JobService`. `UpdateService` is currently an `IntentService`. So in this merge request, there is just a shim `JobService`. Ideally, the full update procedure would happen in the `JobService`, and heed its `onStopJob()` callback.
This is only very lightly tested, I'm posting it for feedback on how its implemented @commonsguy @relan @pserwylo @ssinelnikau1.1https://staging.gitlab.com/fdroid/fdroidclient/-/merge_requests/422Add new index format to support localization and graphics2017-03-31T17:44:13Zusername-removed-24982Add new index format to support localization and graphicsWe have been talking about a new index format for a long time. Adding support for localization and graphics is the straw that broke the camel's back for me, so I finally dug in. I also took this opportunity to change the flow on both c...We have been talking about a new index format for a long time. Adding support for localization and graphics is the straw that broke the camel's back for me, so I finally dug in. I also took this opportunity to change the flow on both client and server side to take advantage of some really great libraries out there, like Jackson on the client side, and python-yaml and python-json on the server side.
There is a test repo here with the new index: http://testy.at.or.at/fdroid/repo/0.103 - UX Overhaulusername-removed-25042username-removed-25042