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

Shelley extensions #209

Open
ondrejhanslik opened this issue May 13, 2013 · 1 comment
Open

Shelley extensions #209

ondrejhanslik opened this issue May 13, 2013 · 1 comment

Comments

@ondrejhanslik
Copy link
Contributor

I have worked with Frank for a while and I noticed there are many things I can't do and they would be nice to have so I would like to open a discussion about possible Shelley extensions (I am willing to implement any of them).

Accessibility elements

Shelley can currently inspect only views. However, some of the user interaction can be done only through accessibility elements. One example is the iOS native keyboard which uses elements with type UIAccessibilityTraitKeyboardKey and UIAccessibilityTraitButton.

It would be nice to have accessibility selectors, e.g. uiaelement:button marked:'Hide Keyboard'. This could be easily combined with the view hierarchy, e.g. view:'MyCustomView' uiaelement:button

This would also require to add some additional interaction selectors (e.g. FEX_touch) on NSObject. There is already a similar code for Mac.

Custom predicates

Currently there are predefined predicates, e.g. marked:, markedExactly:, isAnimating etc. The all have to return a BOOL. There is no possibility to use logical operations (NOT, OR). It would be nice to allow custom predicates without the need to add custom UIView methods.

Proposal example: view filter:"tag = 10"

This could be easily implemented using NSPredicate and -[NSArray filteredArrayUsingPredicate:], automatically enabling comparisons and logical operations.

This could be actually implemented in Frank using -[UIView filter:] method but implementation directly in Shelley makes more sense.

Inspecting views returning from methods

Some of the views are very difficult to describe only using marked. It would be nice to have the possibility to find a view and then get next views using selectors on the first view.
Cons: The grammar could get complicated

E.g. view:'UITableView' {"tableHeaderView"} or view:'UITableView' {"headerViewForSection:", 0}

Sorting

The index predicate usually doesn't work properly because the view ordering is random. Unfortunately, it is needed for some situations, e.g. testing if table view cells are sorted correctly.

It would be nice to have a possibilty to sort the returned selectors:

Proposal: view:'UITableViewCell' sort:position

@moredip
Copy link
Owner

moredip commented May 13, 2013

Thanks for starting to explore this - I've wanted to support UIAccessbilityElement in queries for a while. Lots of other interesting ideas here too.

Could you start a thread about this in the Frank mailing list? This is something which is meaty enough to have some good community discussion I hope. Also there are some folks on the list who have implemented alternate view selector engines with some of the features you describe (e.g. NSPredicate support). It's be great to get their perspectives.

Cheers,

Pete

Typed on a little bitty keyboard

On May 13, 2013, at 2:39 AM, ondrejhanslik notifications@github.com wrote:

I have worked with Frank for a while and I noticed there are many things I can't do and they would be nice to have so I would like to open a discussion about possible Shelley extensions (I am willing to implement any of them).

Accessibility elements

Shelley can currently inspect only views. However, some of the user interaction can be done only through accessibility elements. One example is the iOS native keyboard which uses elements with type UIAccessibilityTraitKeyboardKey and UIAccessibilityTraitButton.

It would be nice to have accessibility selectors, e.g. uiaelement:button marked:'Hide Keyboard'. This could be easily combined with the view hierarchy, e.g. view:'MyCustomView' uiaelement:button

This would also require to add some additional interaction selectors (e.g. FEX_touch) on NSObject. There is already a similar code for Mac.

Custom predicates

Currently there are predefined predicates, e.g. marked:, markedExactly:, isAnimating etc. The all have to return a BOOL. There is no possibility to use logical operations (NOT, OR). It would be nice to allow custom predicates without the need to add custom UIView methods.

Proposal example: view filter:"tag = 10"

This could be easily implemented using NSPredicate and -[NSArray filteredArrayUsingPredicate:], automatically enabling comparisons and logical operations.

This could be actually implemented in Frank using -[UIView filter:] method but implementation directly in Shelley makes more sense.

Inspecting views returning from methods

Some of the views are very difficult to describe only using marked. It would be nice to have the possibility to find a view and then get next views using selectors on the first view.
Cons: The grammar could get complicated

E.g. view:'UITableView' {"tableHeaderView"} or view:'UITableView' {"headerViewForSection:", 0}

Sorting

The index predicate usually doesn't work properly because the view ordering is random. Unfortunately, it is needed for some situations, e.g. testing if table view cells are sorted correctly.

It would be nice to have an ability to sort the returned selectors:

Proposal: view:'UITableViewCell' sort:position


Reply to this email directly or view it on GitHub.

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

No branches or pull requests

2 participants