Self-built Frank behaving differently from GIT Frank

[Martin Taylor]

I was trying to implement a solution to Issue #203 but was having great difficulty getting my self-built Frank.a library to work.  So I did a "git stash" to put aside all my changes, checked that I had a clean copy, and then used Xcode's Project-->Build to build my own copy of the Frank.a and other .a libraries.  This worked fine.  I then copied these libraries into my Frankified app and built and ran it.  I used Symbiote to test tapping on a simple navigation button.  The attached screen shots illustrate the steps:

1. Screen Shot 2013-05-02 at 3.42.22 PM.png shows the navigation button I'm going to tap highlighted.

2. Screen Shot 2013-05-02 at 3.46.57 PM.png shows that Symbiote can Flash this button on the iPad (I saw it flashing on the iPad).

3. Screen Shot 2013-05-02 at 3.47.08 PM.png shows Symbiote after I asked it to "Touch in App" this same navigation button.

The problem is that with MY build of Frank, the "Touch in App" does nothing.  If I repeat all of this with my Frankified app using the Frank.a and other .a libraries that are in the Frank GIT repository, then it all works fine.  The app navigates back to the "Document Settings" part of the dialog as you would expect.

What could I be doing wrong in my Xcode build of Frank that would cause this weird behaviour. Other parts of my app, Frankified with my own build of Frank, work just fine, including the new code I added as a solution to Issue #203!  Its just that ANY "view:'UINavigationItemButtonView'" that I tap (and I have a number of them in my app) does NOTHING!

FYI: I'm using Xcode Version 4.5.2 (4G2008a) under iOS 10.7.5 running on a 2.4 GHz Core i7 MacBook Pro with 8 GB of RAM.

Any tips or suggestions for how to correctly build Frank would be greatly appreciated.

Thanks,

Martin

[Peter Hodgson]

Hi Martin,

This is a strange one. Are there any interesting log messages when you try to send that touch event? I believe Frank will log the touch coordinates it is using. Also, can you launch the Web Inspector in your browser (Cmd-Option-I) and look at what the raw network traffic looks like when you send the touch. There may be some clues there.

Cheers,

Pete

--
You received this message because you are subscribed to the Google Groups "Frank" group.
To unsubscribe from this group and stop receiving emails from it, send an email to frank-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Taylor, Martin]

Hi Pete,

 

Yes there are some interesting log messages.  I turned on frankLogEnabled in FrankLoader.m to get the attached detailed log.  My annotations in the attached log are prefixed “CMT:”.  It appears to be some sort of issue with Shelley, in that it can recognize that a view exists (by checking its accessibility label) but cannot touch it for some reason.  This works fine when I use the .a files from GIT.  It only fails when I build my own.

 

My own .a files are quite a bit smaller than the ones from GIT.  I seem to recall from some help you gave me last year that you don’t build from Xcode, which only produces a .a for a single platform (in this case iPad).  You had some command-line “incantation” that I’ve forgotten that you use to build .a files for BOTH iPad and Simulator.  Can you please remind me how to do that?  It may be that there are other differences in the build you use, other than just multi-platform.

 

I have no idea what you’re talking about regarding “Web Inspector in your browser”.  What is that?  What browser do you need? How can it see raw traffic between my PC and my iPad if its running on my Mac?

 

Thanks,

Martin

[Peter Hodgson]

The command line incantation is `rake`. That'll build all the libraries, combine them into fat (multi-arch) libs, and leave them in the dist directory. I'd try using those libs to see if it makes a difference.

I'm wondering whether your custom build is giving you a different version of Frank with slightly different semantics for how touch works. For example I believe we recently changed it so it would fail to touch things that aren't visible on screen.

When I mentioned the web inspector I was talking about using it to debug the traffic that Symbiote is sending to the Frank server when you press the various buttons in the Symbiote UI. Web Inspector is built into both Chrome and also Safari I believe. You can open it by hitting Command-Option-I (I for Inspect, not L for Lisa). You're already getting the raw wire traffic in those logs anyway though, so it's not worth it for this.

[Taylor, Martin]

The command line “rake” doesn’t work.  Here’s what I get:

 

cmtaylor:Frank cmtaylor$ rake --trace

(in /Users/cmtaylor/_GIT_/Frank_Fork/Frank)

rake aborted!

/Users/cmtaylor/_GIT_/Frank_Fork/Frank/Rakefile:13: odd number list for Hash

  puts "building #{{scheme:scheme,sdk:sdk}}"

                           ^

/Users/cmtaylor/_GIT_/Frank_Fork/Frank/Rakefile:13: syntax error, unexpected ':', expecting '}'

  puts "building #{{scheme:scheme,sdk:sdk}}"

                           ^

/Users/cmtaylor/_GIT_/Frank_Fork/Frank/Rakefile:13: syntax error, unexpected ':', expecting '='

  puts "building #{{scheme:scheme,sdk:sdk}}"

                                      ^

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2383:in `load'

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2383:in `raw_load_rakefile'

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2017:in `load_rakefile'

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2068:in `standard_exception_handling'

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2016:in `load_rakefile'

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2000:in `run'

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:2068:in `standard_exception_handling'

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rake.rb:1998:in `run'

/usr/bin/rake:31

 

This is with the latest GIT stuff obtained immediately before the “rake” with:

git  fetch upstream

git merge upstream/master

 

Please fix the Rakefile and push it to GitHub so I can get it.

[Taylor, Martin]

Replacing this line in the Rakefile:

  puts "building #{{scheme:scheme,sdk:sdk}}"

 

With this:

  puts "building scheme #{scheme} with sdk #{sdk}"

 

got rid of the syntax errors.  I then got a successful Rake build.  I put these artifacts from dist into my app Frank folder and built my Frankified app.  When I ran the test like before, this time I got a successful:

 

POST DATA:

               {"query": "view:'UINavigationItemButtonView'", "operation": {"method_name": "touch", "arguments": []}, "selector_engine": "shelley_compat"}

May  7 10:14:12 unknown TI-Nspire SE CAS Frank[4560] <Warning>: Using Shelley 1.1.11.pre1 to select views with selector: view:'UINavigationItemButtonView'

May  7 10:14:12 unknown TI-Nspire SE CAS Frank[4560] <Warning>: tapping at (661.00,240.00)

May  7 10:14:12 unknown TI-Nspire SE CAS Frank[4560] <Warning>: returning:

               {"results":[true],"outcome":"SUCCESS"}

May  7 10:14:12 unknown TI-Nspire SE CAS Frank[4560] <Warning>: received request with path (

                   map

               )

 

Where “touch” on "view:'UINavigationItemButtonView'" generates a “tapping at” log message and a {"results":[true],"outcome":"SUCCESS"}

return value.

 

Obviously there’s something different about doing a Rake build, vs. a build from inside Xcode!  I’ll use the Rake build in future.

 

Now I’ll go back to trying to integrate and test my fix for the issue I raise so I can submit it back to you with a “pull” request.

 

Thanks,

Martin

Thanks,

[Pete Hodgson]

Glad you got it figured out. 

FYI, that ruby error was because the Rakefile has some ruby 1.9 syntax, and you're presumably running 1.8.

Cheers,

Pete

--

Typed on a little bitty keyboard

[Taylor, Martin]

Well, not totally figured out…

 

Now when I build my own Frank with the Rake command a different Frank feature stops working!  We have a custom keypad with buttons for which I have set accessibilityLabel values.  One such button is the ENTER key, with accessibilityLabel=”~enter~”.  With the GIT-provided Frank.a I can touch it and I see “tapping at…” in the console log.  When I do the exact same test with my Rake-built Frank.a I don’t see the “tapping at…” and yet the return value to FrankHelper is the same as if the touch happened OK.  I very specifically replaced ONLY Frank.a in my Frankified app, and NOT Shelley.a (which I left as the one provided from GIT).

 

So there’s still something weird going on in Frank on the iPad when I build it.  Do you have ANY idea what could cause such strange behaviours?  Maybe I’m still not getting everything I think I’m getting from GIT, but I don’t know what else to try there.

 

Thanks,

Martin

[Taylor, Martin]

Slight correction…

 

When trying to do the touch of ~enter~ I get the “false” for views touched, just like I did before with the navigation button:

POST DATA:

{"query": "view marked:'~enter~'", "operation": {"method_name": "touch", "arguments": []}, "selector_engine": "shelley_compat"}

2013-05-07 11:49:56.228 TI-Nspire SE CAS Frank[4675:707] Using Shelley 1.1.11.pre1 to select views with selector: view marked:'~enter~'

2013-05-07 11:49:56.248 TI-Nspire SE CAS Frank[4675:707] returning:

{"results":[false],"outcome":"SUCCESS"}

2013-05-07 11:49:57.344 TI-Nspire SE CAS Frank[4675:707] received request with path (

    "app_exec"

)

 

I’m adding a test for this and raising an exception in my FrankHelper.py, but I still don’t understand what it means for a query to return “[false]” for its results.  Can someone explain the meaning of this, and perhaps how to correct it?

 

Thanks,

Martin

[Peter Hodgson]

the touch method will return false for a lot of reasons, mostly from the logic in FEX_canTouchPoint:

https://github.com/TestingWithFrank/Frank/blob/master/src/UIView%2BPublicAutomation.m#L109

- your app is in the middle of an animation (e.g. navigating from one view to another

- the view is hidden, or transparent

- the view's center isn't tappable from the view's window

Are any of those a possibility? Is it possible you have a race condition? For example you're trying to touch the view before it has fully animated into place?

Pete Hodgson

Señor Consultant!

@ph1

thepete.net

cell: 707-206-8897
skype: thepete

[Taylor, Martin]

I’ve finally been able to get Xcode to breakpoint through some of this code in the debugger.  What I’ve learnt is that when my custom keypad is displayed and I’m trying to tap on the “view marked:’~enter~’” key, it fails because first the test in this line is False:

https://github.com/TestingWithFrank/Frank/blob/master/src/UIView%2BPublicAutomation.m#L57

and then the test in this line is also False:

https://github.com/TestingWithFrank/Frank/blob/master/src/UIView%2BPublicAutomation.m#L60

 

The touchedView is this:

 

 

But it’s not clear to me what “self” is in this code.  Nor is it clear to me why either touchedView must be a descendent of self or self a descendent of touchedView.  In general, I think, a keypad is unlikely to be a descendent of any view other than the top-most window. I haven’t yet had time to go through this debugging path for a key on the custom keypad that works (and most of them do), but I’ll try to do that early next week if not today.

 

In the meantime, Pete and Ondrej, does this give you any further clues as to what’s going on in this non-working GUI object touching?

[Ondrej Hanslik]

Hi,

FEX_canTouch is trying to test if the view can really be touched. We don't know if the generated "tap" event is really delivered to the selected view so FEX_canTouch is replicating the iOS event delivery before event generation.

For example, if you try to touch "view marked:'~enter~'", then:

self is the selected view (the one marked "~enter~")

touchedView is the one that will receive the tap event.

In an ideal situation, self == touchedView (the selected view will receive the touch)

The [touchedView isDescendantOfView:self] checks for the situation when the selected view is not the receiver of a touch.

For example, when processing touch("tableView") the touchedView will probably be a UITableViewCell instance. Such a touch is still valid because the cell is a descendant of the table.

The last branch tests whether you are trying to touch an object that cannot be touched. For example, touch("button label") will select the button label but the actual receiver of the touch is the button. If the label is inside the button and it is visible, it can be touched.

I thought the code was bulletproof, so I am really interested in finding the problem.

Is it possible there are two buttons (or views) at the same position and one of them is marked "~enter~" but the second one is receiving the touch?

Ondrej

[Taylor, Martin]

Hi Ondrej,

 

In this particular instance of the ~enter~ key, the object with the accessibilityLabel == “~enter~” is a UILabel.  Most of the other buttons on the custom keypad are UIButton or custom TINKeyBoardKeyOverlay objects.  I’m going to ask our developers a “Why?” question about this when I can catch the right person.  In the meantime, I think that if touch events are generated simply at an (x,y) location, then you shouldn’t have ANY logic that would prevent me from touching an arbitrary location.  If I touch the wrong location, then nothing, or something unexpected, will happen and that’s an automation bug.  I don’t expect the automation tool to prevent me from touching anywhere I want to.  If that messes with other users’ expectations, then maybe we need a “forceTouch” method that ignores all this “am I allowed to do it” stuff.

 

Thanks,

Martin

[Ondrej Hanslik]

Hi,

there is nothing preventing you from touching an arbitrary point on the screen but if your test says "touch view marked:'~enter~'" and you are expecting it to touch a completely different view which only happens to be in the same place on the screen, then I don't think it is a problem in Frank.

The code inside FEX_canTouch doesnt check whether "I am allowed to do it”. It checks whether the event goes to the view we have selected.

I think the accessibility label should be set on the button.

Or maybe something like "view marked:'~enter~' parent view:'TINKeyBoardKeyOverlay'" would be better (not sure about the view hierarchy there).

[Taylor, Martin]

Hi again,

 

I did a bit more digging into the .xib file that defines our custom keypad.  I found that directly behind the UILabel for which I had set the accessibilityLabel == “~enter~” is a custom TINKeyBoardKeyOverlay object that is the actual button.  These two GUI objects have a sibling relationship (i.e. same parent) and not a descendent relationship.  By temporarily moving the UILabel object in the .xib file, I was able to access the TINKeyBoardKeyOverlay object behind it.  I moved the accessibilityLabel == “~enter~” to that object, then moved the UILabel back directly over it.  Rebuilding the app with this change makes it work OK now with Frank as I built it!

 

So the real explanation for the “Self-built Frank behaving differently from GIT Frank” problem originally raised in this thread is that the set of .a binary files in GitHub do not match the source code.  When I build from the latest source code I get your (and others) latest changes which are breaking things in a GUI layout scenario like this.

 

Regarding the “sibling” style of GUI layout, this layout scenario is fairly typical in our (and I suspect others) apps.  Here’s another example that is also broken in the current (my) Frank build:

 

 

The UIButton with its child UIButtonLabel are completely invisible, but are behind the UILabel: START GUIDED TOUR and the UIImageView: tutorial_ForwardNeutral1.png (the little arrow in the circle to the right of START GUIDED TOUR words).  All 3 of these co-located objects are siblings of a common parent GUI object.  I happen to attempt to touch the UIImageView: tutorial_ForwardNeutral1.png because it is uniquely identifiable in a non-language-specific way.  This fails with the current build for the same reason that the attempt to touch the ~enter~ label failed.

 

Could you perhaps add a 3^rd OK scenario in your logic that allows you to touch an object if it has a co-located sibling object that will actually respond to the touch event?  And by “sibling object” I really mean “any object with a common ancestor” ‘cause there’s no telling if, a GUI designer might make a GUI with such a structure.  A simple example of this might be if I tried to touch the unnamed UIButtonLabel in the Symbiote hierarchy above.  It has no siblings that could handle the touch, but it does have  “Uncles” that would respond.

[Ondrej Hanslik]

Personally I think this type of view hierarchy is slightly abusing UIKit :) (why not using tap recognizer or a UIControl with the label and image inside?)

Your proposed change would effectively revert to the version where there were no checks.

I think we could implement a specialized method skipping the checks, e.g. "touchScreen". IMHO if you want to touch a view different from the one you are selecting, you should say it explicitly.

However I would love to hear a 3rd opinion on this.

[Peter Hodgson]

Martin, Ondrej, much credit to both of you for your dogged diligence in investigating what's going on here.

I guess I'd agree that the situation described isn't a poster-child for good UIKit practices, but at the same time it's not unusual for people to take some shortcuts when needed. It's also not unsual to see non-idiomatic approaches when teams are learning a new framework, and I think Frank shouldn't throw up too many roadblocks - the goal is to help people develop better quality software.

Ondrej, what do you think of Martin's suggestion to add a new method that is less rigorous in the checks it does? Something that checks that the touch is within bounds, but not much else? That'd be similar to how the touch method worked a while ago, I think. Something like FEX_touchWithoutChecks maybe?

I think it would also be really good to have the more rigorous FEX_touch method provide as much debugging information as possible when it decides to not touch a view because the constraints haven't been met. Some options: have FEX_touch return a string describing the outcome: e.g. "view touched", "view not touched because out of viewport", "view not touched because it would not be the recipient of the touch event - consider FEX_touchWithoutChecks instead". Alternatively we could continue to return a simple boolean, but write detailed logs describing the reason a touch didn't occur. Either way I think it's important that these failure messages are verbose, and explicitly point the reader towards the alternate FEX_touchWithoutChecks method.

Very much looking for thoughts and opinions on the above.

[Ondrej Hanslik]

Hi,

I do agree, quoting myself

I think we could implement a specialized method skipping the checks, e.g. "touchScreen". IMHO if you want to touch a view different from the one you are selecting, you should say it explicitly.

I will push it as soon as possible. I will probably name it "FEX_touchScreen" 

I also agree with the logging but I will have to think about it a little. I would like to see the errors in cucumber but I don't want "FEX_canTouch" to log errors when it is used in selectors, e.g. "view FEX_canTouch".

[Taylor, Martin]

I also agree with the need for a “more forgiving” touch method.  However I don’t like the proposed name.  The “FEX” prefix won’t mean anything to test authors.  What about calling it “touchNoChecks”, “looseTouch”, “forcedTouch” or some such name that carries the implication of touching without strict checking?  Internally, UIView+PublicAutomation.m will need a whole set of methods that correspond to the current set dealing with touching an object, touching at a point, etc. but without the strict canTouch checks.

 

In the meantime, now I know the cause of the problems, I’ve re-worked some parts of our product code to name the more correct GUI elements for touching in some circumstances, and I’ve re-worked some of our Python client-side methods to touch different GUI objects that pass the strict checking.  This latter part is non-intuitive and I would like to put them back the way they were.  One of the techniques our GUI developers used, that breaks the strict touching algorithms, is that when a pop-up menu or dialog is shown the rest of the app screen is “dimmed” by covering it with a semi-transparent “dimming view”.  This “dimming view” covers the entire screen and thus prevents touching anything behind it (when strict touch is enforced).  However, the user can see through this “dimming view” and, to remove a pop-up selection box for example, would touch again the field in the dialog that they touched to cause the pop-up selection box to appear.  When automation tries to touch this same dialog field, now behind the “dimming view”, the strict touch algorithm disallows it.  My workaround in these situations was to touch the “dimming view”, which is also valid for a user to do, but not necessarily as common a practice.

 

I also agree with the more detailed error return suggestions.  If such a return was in place this would have saved me about a week of effort to track down the source of these touch failures!  Just logging is not enough.  These detailed messages MUST come back to the client side (Cucumber or Robot Framework).

 

Thanks,

Martin

 

From: frank-...@googlegroups.com [mailto:frank-...@googlegroups.com] On Behalf Of Ondrej Hanslik
Sent: Friday, May 17, 2013 4:59 AM
To: frank-...@googlegroups.com
Subject: Re: [Frank] Self-built Frank behaving differently from GIT Frank

 

Hi,

 

I do agree, quoting myself

 

I think we could implement a specialized method skipping the checks, e.g. "touchScreen". IMHO if you want to touch a view different from the one you are selecting, you should say it explicitly.

 

I will push it as soon as possible. I will probably name it "FEX_touchScreen" 

 

I also agree with the logging but I will have to think about it a little. I would like to see the errors in cucumber but I don't want "FEX_canTouch" to log errors when it is used in selectors, e.g. "view FEX_canTouch".

On Friday, May 17, 2013 6:39:51 AM UTC+2, Pete Hodgson wrote:

Martin, Ondrej, much credit to both of you for your dogged diligence in investigating what's going on here.

 

I guess I'd agree that the situation described isn't a poster-child for good UIKit practices, but at the same time it's not unusual for people to take some shortcuts when needed. It's also not unsual to see non-idiomatic approaches when teams are learning a new framework, and I think Frank shouldn't throw up too many roadblocks - the goal is to help people develop better quality software.

 

Ondrej, what do you think of Martin's suggestion to add a new method that is less rigorous in the checks it does? Something that checks that the touch is within bounds, but not much else? That'd be similar to how the touch method worked a while ago, I think. Something like FEX_touchWithoutChecks maybe?

 

I think it would also be really good to have the more rigorous FEX_touch method provide as much debugging information as possible when it decides to not touch a view because the constraints haven't been met. Some options: have FEX_touch return a string describing the outcome: e.g. "view touched", "view not touched because out of viewport", "view not touched because it would not be the recipient of the touch event - consider FEX_touchWithoutChecks instead". Alternatively we could continue to return a simple boolean, but write detailed logs describing the reason a touch didn't occur. Either way I think it's important that these failure messages are verbose, and explicitly point the reader towards the alternate FEX_touchWithoutChecks method.

 

Very much looking for thoughts and opinions on the above.

On Thu, May 16, 2013 at 12:00 PM, Ondrej Hanslik <ondrej....@gmail.com> wrote:

Personally I think this type of view hierarchy is slightly abusing UIKit :) (why not using tap recognizer or a UIControl with the label and image inside?)

 

Your proposed change would effectively revert to the version where there were no checks.

 

I think we could implement a specialized method skipping the checks, e.g. "touchScreen". IMHO if you want to touch a view different from the one you are selecting, you should say it explicitly.

 

However I would love to hear a 3rd opinion on this.

On Thursday, May 16, 2013 8:41:05 PM UTC+2, Martin Taylor wrote:

Hi again,

 

I did a bit more digging into the .xib file that defines our custom keypad.  I found that directly behind the UILabel for which I had set the accessibilityLabel == “~enter~” is a custom TINKeyBoardKeyOverlay object that is the actual button.  These two GUI objects have a sibling relationship (i.e. same parent) and not a descendent relationship.  By temporarily moving the UILabel object in the .xib file, I was able to access the TINKeyBoardKeyOverlay object behind it.  I moved the accessibilityLabel == “~enter~” to that object, then moved the UILabel back directly over it.  Rebuilding the app with this change makes it work OK now with Frank as I built it!

 

So the real explanation for the “Self-built Frank behaving differently from GIT Frank” problem originally raised in this thread is that the set of .a binary files in GitHub do not match the source code.  When I build from the latest source code I get your (and others) latest changes which are breaking things in a GUI layout scenario like this.

 

Regarding the “sibling” style of GUI layout, this layout scenario is fairly typical in our (and I suspect others) apps.  Here’s another example that is also broken in the current (my) Frank build:

 

 

The UIButton with its child UIButtonLabel are completely invisible, but are behind the UILabel: START GUIDED TOUR and the UIImageView: tutorial_ForwardNeutral1.png (the little arrow in the circle to the right of START GUIDED TOUR words).  All 3 of these co-located objects are siblings of a common parent GUI object.  I happen to attempt to touch the UIImageView: tutorial_ForwardNeutral1.png because it is uniquely identifiable in a non-language-specific way.  This fails with the current build for the same reason that the attempt to touch the ~enter~ label failed.

But it’s not clear to me what “self” is in this code.  Nor is it clear to me why either touchedView must be a descendent of self or self a descendent of touchedView.  In general, I think, a keypad is unlikely to be a descendent of any view other than the top-most window. I haven’t yet had time to go through this debugging path for a key on the custom keypad that works (and most of them do), but I’ll try to do that early next week if not today.

[Pete Hodgson]

The reason for the FEX_ prefix is to prevent naming collisions. This is an unfortunate but real problem, so we have to do it despite the clunkiness. It can be hidden away on the client side inside the automation driver.

I agree that a method name that implies it's a 'looser' or less strict way of touching a view would be good. touchScreen doesn't convey that to me.

Another idea for getting the error string back to the client would be to treat the attempt to touch an 'untouchable' view as an automation error, and use the existing error reporting mechanism to get the message back to the client. I think that might be the clearest approach.

Cheers,

Pete

--

Typed on a little bitty keyboard

[Ondrej Hanslik]

Okey, then "FEX_forcedTouch" it is.

I can promise you I will get to it before Monday.

to treat the attempt to touch an 'untouchable' view as an automation error... might be the clearest approach

I think that too. 

On Friday, May 17, 2013 4:46:53 PM UTC+2, Pete Hodgson wrote:

The reason for the FEX_ prefix is to prevent naming collisions. This is an unfortunate but real problem, so we have to do it despite the clunkiness. It can be hidden away on the client side inside the automation driver.

I agree that a method name that implies it's a 'looser' or less strict way of touching a view would be good. touchScreen doesn't convey that to me.

Another idea for getting the error string back to the client would be to treat the attempt to touch an 'untouchable' view as an automation error, and use the existing error reporting mechanism to get the message back to the client. I think that might be the clearest approach.

Cheers,

Pete

--

Typed on a little bitty keyboard

On May 17, 2013, at 6:13 AM, "Taylor, Martin" <cmta...@ti.com> wrote:

I also agree with the need for a “more forgiving” touch method.  However I don’t like the proposed name.  The “FEX” prefix won’t mean anything to test authors.  What about calling it “touchNoChecks”, “looseTouch”, “forcedTouch” or some such name that carries the implication of touching without strict checking?  Internally, UIView+PublicAutomation.m will need a whole set of methods that correspond to the current set dealing with touching an object, touching at a point, etc. but without the strict canTouch checks.

 

In the meantime, now I know the cause of the problems, I’ve re-worked some parts of our product code to name the more correct GUI elements for touching in some circumstances, and I’ve re-worked some of our Python client-side methods to touch different GUI objects that pass the strict checking.  This latter part is non-intuitive and I would like to put them back the way they were.  One of the techniques our GUI developers used, that breaks the strict touching algorithms, is that when a pop-up menu or dialog is shown the rest of the app screen is “dimmed” by covering it with a semi-transparent “dimming view”.  This “dimming view” covers the entire screen and thus prevents touching anything behind it (when strict touch is enforced).  However, the user can see through this “dimming view” and, to remove a pop-up selection box for example, would touch again the field in the dialog that they touched to cause the pop-up selection box to appear.  When automation tries to touch this same dialog field, now behind the “dimming view”, the strict touch algorithm disallows it.  My workaround in these situations was to touch the “dimming view”, which is also valid for a user to do, but not necessarily as common a practice.

 

I also agree with the more detailed error return suggestions.  If such a return was in place this would have saved me about a week of effort to track down the source of these touch failures!  Just logging is not enough.  These detailed messages MUST come back to the client side (Cucumber or Robot Framework).

 

Thanks,

Martin

 

From: frank-...@googlegroups.com [mailto:fra...@googlegroups.com] On Behalf Of Ondrej Hanslik

[Ondrej Hanslik]

I have added FEX_forcedTouch. Sorry for the "FEX_" prefix but that's necessary. In theory, all the "touch" methods should have this prefix.

I will improve the logging this week when I have the time.

[Taylor, Martin]

Thanks very much for this.  It works fine and I’ve integrated use of it into my Python FrankLibrary so that “Force” is an option on the Tap method, defaulted to True for my purposes.

 

I’ve now integrated my own enhancements for Issue #203 and am in the process of testing them and getting permission to release them with a Pull Request.

 

Cheers,

Martin