| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Load more comments from /morechildren endpoint
Previous implementation requested comments from /api/info which returned the comments themselves but did not include any information about their children. Also /api/info does not allow to specify sort type. On the other hand /morechildren supports sort type and it will be added in a later commit.
I am not proud of this implementation, but I had to fight with both Reddit api response and existing code. The problem with api response is that it is a flat list of comments, not a tree structure. So the tree has to be rebuilt on our end. And the problem with existing code is that it merges "more children" node into its parent but then adds a placeholder anyways.
The code relies on the fact that parent comment will be located before any of its children in the response. The code sequentially processes comments, tries to find their parents and either adds them to the tree or puts in a "top-level" array which will be handled by outside code.
One possible problem is the removal of `depth` argument from parsing as I couldn't find a way to fit it in the new logic. However I also didn't experience any problems with it during my testing and the response seems to always contain depth key. Moreover current depth handling logic in ParseComment#parseCommentRecursion is broken because it does not increment depth when making a recursive call.
* Store moreChildren ids instead of fullnames
/morechildren endpoint accepts ids instead of fullnames so there is no point in converting ids to fullnames and back
* Send all comment ids to Reddit so it can select what to display itself
Sending all ids allows Reddit to sort them properly. Since the number of comments can be very bing, it requires using POST request instead of GET.
This commit changes the meaning of Comment#moreChildrenIds field, now it stores only ids of comments that are not yet loaded. This simplifies the code and removes the need for Comment#moreChildrenStartingIndex
* Fetch more comments with current sort type
|
| | |
|
| | |
|
| | |
|
| |
|
| |
It used position of viewholder during binding which could get outdated by the time user clicks on the button. This would result in retrieving wrong comment or even null. Replaced with getting comment based on current position of vieholder.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
When extracting sort type loading logic the shared preferences that are used to load sort type got accidentally changed to the wrong ones. This resulted in always using the default value which is displayed as Best.
Fortunately the saving code was not changed so only reading has to be fixed.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
HistoryPostFragment. There are bugs in HistoryPostPagingSource so duplicate posts will be fetched and more posts could not be fetched. Will be fixed.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
* Superscript parser overhaul
* Make superscript work with tables
* Fix some issues with Table compatibility
* Some bug fixes
* Re-enable Autolink
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Add a gradient from the primary theme color to transparent so that if a
subreddit or user profile has a very light background, the usually light
text and buttons are not obscured or in some cases invisible.
The gradients don't appear for immersive mode so that the app remains
immersive.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* Rename CONFIDENCE comments sort type to BEST and remove old BEST type
The Reddit API supports only CONFIDENCE sort type for comments but displays it
as BEST.
I renamed CONFIDENCE name to Best and added a migration step for loading
correct sort type.
* Clean up sortType usages in ViewPostDetailFragment
Removed unnecessary null checks, object creations and most case conversions
|
| |
|
|
|
|
|
|
|
| |
Condition in callback for loading avatar url is almost always true[1]. So it would load avatar even if the viewholder got bound to another comment.
Ideally the solution would be to update the comment just like now, then find current position of the comment and call onItemChanged. However you cannot call onItemChanged from onBindViewHolder and that is a problem because callback can be executed synchronously.
So instead we just check that viewholder is bound to some comment and that bound comment's author matches initially requested author.
[1] The only case I know when it is false is when that comment got deleted and its author got replaced with "[deleted]" before the callback got executed
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
* mux videos with and without audio
* move variable to inner scope
* rename argument to catch block
|
| |
|
|
|
|
|
|
|
| |
* handle wiki links with dashes and index wiki page
* properly handle w vs wiki and links with wiki in it twice
* remove beginning and end of line tokens from wiki regex
* optimize wiki regex
|
| |
|
|
|
|
|
| |
* Added oauth to fetching rules
* Added getRulesOauth for users that are logged in
Co-authored-by: Abi <u7290897@anu.edu.au>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
* Fix removed comment shown in the wrong position.
* Handle index out of bounds.
|
| | |
|
| |
|
|
|
|
|
| |
* feature/ability to hide karma
* only hide karma in nav bar
* center account name vertically when not showing karma
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Slidr works by adding its own view in the hierarchy and listening to touch
events in `onInterceptTouchEvent`. Once it detects movement in the correct
direction, it returns `true` and handles all the events itself.
Adding scrollable view detection to Slidr would solve the problem, but it is
not possible and would probably have performance impact.
Fortunately Slidr does not intercept the very first event, which is
ACTION_DOWN, and it reaches scrollable view. So the scrollable view itself can
decide if it should disallow the swipe.
This also has a performance benefit over `OnScrollChangedListener` because
the listener is triggered for every scroll of every view even if the child we
are interested in did not scroll. On the other hand `on(Intercept)TouchEvent`
is triggered only when the view is touched.
There is a possibility that swipe won't be unlocked if view never receives
ACTION_UP or ACTION_CANCEL. However the docs say nothing about the probability
of this happening. Anyways, one possible solution is to post a runnable that
will unlock swipe soon after locking.
|
