Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TreeViewer Bugs on Android and iOS #461

Open
PatrickNass opened this issue Oct 24, 2017 · 1 comment
Open

TreeViewer Bugs on Android and iOS #461

PatrickNass opened this issue Oct 24, 2017 · 1 comment

Comments

@PatrickNass
Copy link

Hello Tabris team,
on playing around with the TreeViewer element I have found 3 bugs. 1 on iOS, 1 on Android and 1 on both sides.

Tested with: iOS11, iOS10 and Android 6.0.1

I have created a TreeViewer with the flags 'SWT.SINGLE' and 'SWT.V_SCROLL. The content provider implements 'ITreeContentProvider'.

iOS
After "clicking" on an element with childs, the "child view" is no longer scrollable which makes it unusable, because one can not reach/see every child element. Only the "root node view" is scrollable. This does not occur on Android.

Android
After clicking on a child element, no "back" button is created like in iOS, so it has to be created manually. Additionally elements which have child elements are not automatically marked (e.g. with an arrow like on iOS), so this has to be implemented manually too. This means that on writing a code for both devices one always have to implement a "device switch".

Both
If an element is selected which does not have any childs, this element keeps selected. No flag or something else changes that behaviour.

@mpost
Copy link
Member

mpost commented Dec 6, 2018

Thanks for reporting the issues.

The scenario you described on iOS should work and it should be considered a bug.

The Android behavior works as intended. There is no top bar with a synthetic back button since you can use the physical back button. The Android style guide also does not apply a arrow icon so we honor the native look and feeld.

The selection behavior you described in the last section is in line with our intended behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants