Open ondrejhanslik opened 11 years ago
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,
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.
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
andUIAccessibilityTraitButton
.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
) onNSObject
. 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 aBOOL
. There is no possibility to use logical operations (NOT
,OR
). It would be nice to allow custom predicates without the need to add customUIView
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 complicatedE.g.
view:'UITableView' {"tableHeaderView"}
orview:'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