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 [email protected]
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
#16 (comment)
.

[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 [email protected]
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
#16 (comment)
.

[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 [email protected]
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
#16 (comment)
.

[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 [email protected]
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
#16 (comment)
.