Unable to swipe to delete cell in iOS7

[athenatk]

swipeInDirection no longer works in iOS7. Need new function to enable swiping cells to delete them.

[MichaelBuckley]

I have a local fix for this. Unfortunately, it relies on a lot of other changes. I'll be sending out a code review for all these changes tonight (PST).

[aceunreal]

Is there any update on the code review?

[MichaelBuckley]

After the code review, it turned out that there are still some issues. The core issue is that, in the simulator, UIAutomation can't perform drags properly.

I just tested this out in UIAutomation, the Javascript testing framework that ships with Instruments, and it turns out dragging is broken in UIAutomation is iOS 7.

http://stackoverflow.com/questions/18792965/uiautomations-draginsidewithoptions-has-no-effect-on-ios7-simulator

Since Frank's event simulation is based on UIAutomation, it's broken in Frank as well.

We're working on an alternative, but it changes how Frank simulates events. In the meantime, we've filed a bug with Apple, and hope that they will solve the issue.

[aceunreal]

Thank you @MichaelBuckley for the update

[ghost]

Is there any chance of getting even a patch file of the work you were doing? Given this bug still exists and is causing my team issues, I'm trying out anything to get gesture support working in Frank. Any help would be greatly appreciated.

[MichaelBuckley]

In fact, the entire branch I was working on has been uploaded to Github. https://github.com/TestingWithFrank/Frank/tree/remove-uiautomation-in-ios7

On Thu, Jul 24, 2014 at 3:44 PM, Nick Gravelyn notifications@github.com wrote:

Is there any chance of getting even a patch file of the work you were doing? Given this bug still exists and is causing my team issues, I'm trying out anything to get gesture support working in Frank. Any help would be greatly appreciated.

— Reply to this email directly or view it on GitHub https://github.com/TestingWithFrank/Frank/issues/16#issuecomment-50088142 .

[ghost]

Awesome, I'll compare that with Frank and see if I can get things working.

[ghost]

I was able to build and use that branch, with some modifications, to get swiping to work. Related: would there be any reason I couldn't make my own static library with the KIF functionality so I can use the latest Frank build but extend it with my own methods? I've tried pulling out what is in this branch but it doesn't want to swipe anything. Is there a conflict with having PublicAutomation in the base Frank library with KIF code that you know of?

[MichaelBuckley]

I'm not 100% I understand what you're asking, but the branch I created is very tightly integrated with KIF. It won't work with PublicAutomation. You'd have to rewrite a lot of Frank code to make that work, which is basically the issue that prevented this from getting merged into master.

On Mon, Jul 28, 2014 at 10:05 AM, Nick Gravelyn notifications@github.com wrote:

I was able to build and use that branch, with some modifications, to get swiping to work. Related: would there be any reason I couldn't make my own static library with the KIF functionality so I can use the latest Frank build but extend it with my own methods? I've tried pulling out what is in this branch but it doesn't want to swipe anything. Is there a conflict with having PublicAutomation in the base Frank library with KIF code that you know of?

— Reply to this email directly or view it on GitHub https://github.com/TestingWithFrank/Frank/issues/16#issuecomment-50366978 .

[ghost]

What I'm hoping to do is have my own static library which would contain all the KIF code that I could then link into our Frankified app to do gestures. We already have a static library that adds some helpers onto various view types. So we'd like to add the KIF gestures to that library as well, that way we aren't using a custom version of libFrank.a in our app.

So my concern then was whether or not libFrank.a still linking PublicAutomation/UIAutomation would cause the KIF logic to completely fail, as I have yet to be able to get KIF working from a separate static library, yet it seems to work fine when building off your branch.

[MichaelBuckley]

It sounds like what you want is to move all the KIF-specific code to a separate library, and have the regular libFrank.a call that code. That's possible to do, but you won't then be able to use the standard Frank ruby API to perform your actions. For example, in the standard Frank Ruby API, you would use the following:

drag_with_initial_delay(:from => selector1, :to => selector2).

However, this will call code in libFrank.a which uses PublicAutomation, without giving your library the chance to use a KIF gesture. You'd instead need to implement some kind of custom_drag_with_intiial_delay like so.

def custom_drag_with_intiial_delay(args) from, to = args.values_at(:from,:to) raise ArgumentError.new('must specify a :from parameter') if from.nil? raise ArgumentError.new('must specify a :to parameter') if to.nil?

dest_frame = accessibility_frame(to)

frankly_map( from, 'YourCustomKIFMethodOnUIView_dragWithInitialDelayToX:y:', dest_frame.center.x, dest_frame.center.y )

end

And you'd have to do the same for every other KIF gesture that you wanted to support.

If you use a custom libFrank.a built from my branch, you can just use the standard Frank Ruby API, and it will use KIF instead of PublicAutomation. It was designed to be a replacement for libFrank.a, so that's the easiest way to use it.

On Tue, Jul 29, 2014 at 12:40 PM, Nick Gravelyn notifications@github.com wrote:

What I'm hoping to do is have my own static library which would contain all the KIF code that I could then link into our Frankified app to do gestures. We already have a static library that adds some helpers onto various view types. So we'd like to add the KIF gestures to that library as well, that way we aren't using a custom version of libFrank.a in our app.

So my concern then was whether or not libFrank.a still linking PublicAutomation/UIAutomation would cause the KIF logic to completely fail, as I have yet to be able to get KIF working from a separate static library, yet it seems to work fine when building off your branch.

— Reply to this email directly or view it on GitHub https://github.com/TestingWithFrank/Frank/issues/16#issuecomment-50527272 .

[ghost]

Yes, we'd like to have our own implementations that we either call directly with frankly_map or wrap ourselves. While replacing libFrank.a is easiest, at this time that requires that we maintain our own fork and merge in any other changes. We'd like to avoid have a custom Frank build which is why we prefer a separate static library approach, at least until such time when Frank officially supports the KIF input code path.

At this point, though, I've not succeeded in getting a separate static library to actually work. The KIF code executes but nothing seems to happen in the app. I've yet to do any deep debugging, but my theory was that perhaps the PublicAutomation library was doing something that would interfere with the KIF injection working.

[MichaelBuckley]

That's a possible explanation. PublicAutomation is just a wrapper around the private functions that Apple uses to implement Javascript UIAutomation in Instruments. It could have that kind of side effect.

But that would only happen if you called any PublicAutomation functions, meaning you'd have to use a standard Frank API call that uses PublicAutomation first.

If you're not calling any PublicAutomation functions, you'll probably need to do some debugging to figure it out. Since the application is launching and running, I expect that it's not a linking problem.

But since you're doing all that work anyway, I would encourage you to spend the time and effort to get Frank to a point where users can switch between PublicAutomation and KIF at runtime. That way, the KIF branch can finally be merged into master, and everyone can benefit from the change.

What you're attempting to do with static libraries appears from the outside to be at least as much work than updating Frank, if not more. I've always intended to come back to Frank and do the work myself, but I've been buried with other concerns, and I don't think I'll have the free time until autumn.

On Tue, Jul 29, 2014 at 1:01 PM, Nick Gravelyn notifications@github.com wrote:

Yes, we'd like to have our own implementations that we either call directly with frankly_map or wrap ourselves. While replacing libFrank.a is easiest, at this time that requires that we maintain our own fork and merge in any other changes. We'd like to avoid have a custom Frank build which is why we prefer a separate static library approach, at least until such time when Frank officially supports the KIF input code path.

At this point, though, I've not succeeded in getting a separate static library to actually work. The KIF code executes but nothing seems to happen in the app. I've yet to do any deep debugging, but my theory was that perhaps the PublicAutomation library was doing something that would interfere with the KIF injection working.

— Reply to this email directly or view it on GitHub https://github.com/TestingWithFrank/Frank/issues/16#issuecomment-50530066 .