Refactor issues #380
No reviewers
Labels
No Label
Priority-high
Accepting-merge-requests
API
API-dependency
Backport
Blocked
Brainstorming
Breaking
Bug
Changelog
CI
Cleanup
Confirmed
Discussion
Documentation
Duplicate
Enhancement
External-dependecy
F-droid
Feature
Google-play
Improvement
Invalid
Investigate
LGTM-done
LGTM-need
Long-term
Major-release
Minor-release
Needs-cleanup
Needs-feedback
Needs-help
Priority-critical
Priority-low
Priority-medium
Question
Ready
Refactor
Regression
Release
Repository
Security
Suggestion
Support
Testing
Translation
UI/UX
Upstream
Website
WIP
No Milestone
No Assignees
2 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitnex/GitNex#380
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "refactor-issues"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Will close #309, #373 and #173
To do:
@ -0,0 +9,4 @@
// issues variables
String TAGIssuesList = "IssuesListFragment - ";
int issuesPageInit = 1;
int resultLimitNewGiteaInstances = 50; // Gitea 1.12 and above
I think it should be the other way around. since gitea < 1.12.0 sometimes accept limits but has no pagination.
so if we limit the result to 10 it could happen that we can no longer access the 11th issue and so on.
suggestion: since we have to pass a limit falue to the API: set 100 or so for old installations. an old gitea will ignore it or deliver us at max 100 results. For Gitea v1.12.0 paggination works just fine so we can limit each api call to a smal number of items
Adding different limits has many reasons here. 1st of API does not return something like
has_more
ornext_page
etc. So these variables are used inside the app to decide what to do next on scroll etc.These are not strictly for sending to the API, but the recyclerview to know if there is anything to load. Below 1.12 as you mentioned does not take limit to consideration and always returns 10 no matter what. So passing that param as limit is useless(I know that). But it is used inside the load next calls to properly know the exact length of data returned.
As for 1.12 and above there is a limit param now, which is useful if in future we add a setting slider to load how many entries per screen(10 to 50).
But for old versions it will be always 10, and no user interaction is needed.
In 2.4.x there is a bug for pagination when we introduced limit 50, but I ignored it because I was looking forward to fix all these in 2.5.
Hope this does make sense. :)
Note: there is missmatch with translation - I'll look into this later
Ok