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

Swipeable "Actions" for Eureka rows? #105

Closed
marbetschar opened this Issue Nov 27, 2015 · 18 comments

Comments

Projects
None yet
10 participants
@marbetschar
Contributor

marbetschar commented Nov 27, 2015

Will there be a Swipeable actions present in Eureka? It would be cool to have something like the following:

<<< DateInlineRow("DateInlineRow"){
    $0.title = $0.tag
    $0.rowActionsRight = [ RowAction("Delete",
        action: { ... },
        condition: Condition.Function(...)),
        ... ]
    $0.rowActionsLeft = [ ... ]
}
@marbetschar

This comment has been minimized.

Show comment
Hide comment
@marbetschar

marbetschar Nov 27, 2015

Contributor

Additionally a rowActionsRightTriggerAction and a rowActionsLeftTriggerAction would be cool (the action which should be executed if the users swipes through). Maybe this can just be the the first RowAction in the array? Then a rowActionsRightTriggerEnabled = true should do the job?

Contributor

marbetschar commented Nov 27, 2015

Additionally a rowActionsRightTriggerAction and a rowActionsLeftTriggerAction would be cool (the action which should be executed if the users swipes through). Maybe this can just be the the first RowAction in the array? Then a rowActionsRightTriggerEnabled = true should do the job?

@mtnbarreto

This comment has been minimized.

Show comment
Hide comment
@mtnbarreto

mtnbarreto Feb 9, 2016

Member

@marbetschar I don't know how common is this problem but....
The right actions feature can be easily implemented using editActionsForRowAtIndexPath table view delegate method:

func tableView(tableView: UITableView, editActionsForRowAtIndexPath indexPath: NSIndexPath) -> [UITableViewRowAction]? {
        var actions = [UITableViewRowAction]()
        let action = UITableViewRowAction(style: .Destructive, title: "Delete") { (action, indexPath) -> Void in
        }
        actions.append(action)

        let action2 = UITableViewRowAction(style: .Normal, title: "Martin") { (action, indexPath) -> Void in
        }
        action2.backgroundColor = .orangeColor()
        actions.append(action2)
        return actions
    }

screen shot 2016-02-09 at 3 43 18 pm

My thoughts about this feature.

  1. I would only implement the feature if we see that it is required by someone else.
  2. I would prefer to change rowActionsRight type from [RowAction] to () -> [RowAction] so we will no longer need the condition parameter condition.
  3. I would like to leave out leftActions, rowActionsRightTriggerAction, rowActionsLeftTriggerAction for now. They are really edge case scenarios.
  4. Also not sure which is the best way to specify the action, Should we use the UIKit class UITableViewRowAction or some abstraction like RowAction?
Member

mtnbarreto commented Feb 9, 2016

@marbetschar I don't know how common is this problem but....
The right actions feature can be easily implemented using editActionsForRowAtIndexPath table view delegate method:

func tableView(tableView: UITableView, editActionsForRowAtIndexPath indexPath: NSIndexPath) -> [UITableViewRowAction]? {
        var actions = [UITableViewRowAction]()
        let action = UITableViewRowAction(style: .Destructive, title: "Delete") { (action, indexPath) -> Void in
        }
        actions.append(action)

        let action2 = UITableViewRowAction(style: .Normal, title: "Martin") { (action, indexPath) -> Void in
        }
        action2.backgroundColor = .orangeColor()
        actions.append(action2)
        return actions
    }

screen shot 2016-02-09 at 3 43 18 pm

My thoughts about this feature.

  1. I would only implement the feature if we see that it is required by someone else.
  2. I would prefer to change rowActionsRight type from [RowAction] to () -> [RowAction] so we will no longer need the condition parameter condition.
  3. I would like to leave out leftActions, rowActionsRightTriggerAction, rowActionsLeftTriggerAction for now. They are really edge case scenarios.
  4. Also not sure which is the best way to specify the action, Should we use the UIKit class UITableViewRowAction or some abstraction like RowAction?
@marbetschar

This comment has been minimized.

Show comment
Hide comment
@marbetschar

marbetschar Feb 11, 2016

Contributor

@mtnbarreto thanks for your feedback. Here are my thoughts about this feature:

  1. I can see a lot of use cases for this feature, therefore IMHO it should definitely be implemented into Eureka Core: Imagine a "Swipe to delete contents", or a "Swipe to add a new item to a multivalued section".
  2. This sounds reasonable if I got your suggestion right: We have the ability to define a Condition for the RowAction to be rendered, but we are not forced to?
  3. If you imagine the use case "Swipe to add a new item to a multivalued section" you may see Eureka should definitely support Row-Action-Left, also there are a lot of use cases (mainly for editing) which require a swipe from the left and would feel unnatural if packed into the right hand side.
  4. I would definitely go for some sort of abstraction like RowAction: This enables us to implement additional, Eureka specific behaviour like Event-Handler-Blocks, Conditions etc.

And one additional point:
The implementation should support the accessibility features to enable UITesting. This is the main concern of all currently available implementations; they simply do not support it. See MortimerGoro/MGSwipeTableCell#139 for additional details.

I'm aware of the Swipe Feature (especially the left-one) to be quite a big beast and unfortunately I can't find the time right now to implement it - so if anyone can afford some time this would be awesome!!!

Contributor

marbetschar commented Feb 11, 2016

@mtnbarreto thanks for your feedback. Here are my thoughts about this feature:

  1. I can see a lot of use cases for this feature, therefore IMHO it should definitely be implemented into Eureka Core: Imagine a "Swipe to delete contents", or a "Swipe to add a new item to a multivalued section".
  2. This sounds reasonable if I got your suggestion right: We have the ability to define a Condition for the RowAction to be rendered, but we are not forced to?
  3. If you imagine the use case "Swipe to add a new item to a multivalued section" you may see Eureka should definitely support Row-Action-Left, also there are a lot of use cases (mainly for editing) which require a swipe from the left and would feel unnatural if packed into the right hand side.
  4. I would definitely go for some sort of abstraction like RowAction: This enables us to implement additional, Eureka specific behaviour like Event-Handler-Blocks, Conditions etc.

And one additional point:
The implementation should support the accessibility features to enable UITesting. This is the main concern of all currently available implementations; they simply do not support it. See MortimerGoro/MGSwipeTableCell#139 for additional details.

I'm aware of the Swipe Feature (especially the left-one) to be quite a big beast and unfortunately I can't find the time right now to implement it - so if anyone can afford some time this would be awesome!!!

@florianthompson

This comment has been minimized.

Show comment
Hide comment
@florianthompson

florianthompson Feb 11, 2016

The swipe feature would be amazing!

florianthompson commented Feb 11, 2016

The swipe feature would be amazing!

@robbiet480

This comment has been minimized.

Show comment
Hide comment
@robbiet480

robbiet480 Sep 24, 2016

This would be a great feature to add to Eureka!!!

robbiet480 commented Sep 24, 2016

This would be a great feature to add to Eureka!!!

@robbiet480

This comment has been minimized.

Show comment
Hide comment
@robbiet480

robbiet480 Sep 24, 2016

Also, it would be an awesome addition if we could implement swipe right actions, like MGSwipeTableCell does.

robbiet480 commented Sep 24, 2016

Also, it would be an awesome addition if we could implement swipe right actions, like MGSwipeTableCell does.

@robbiet480

This comment has been minimized.

Show comment
Hide comment
@robbiet480

robbiet480 Sep 24, 2016

I took a first swing at adding actions support, but would really love to add swipe right actions too.

robbiet480 commented Sep 24, 2016

I took a first swing at adding actions support, but would really love to add swipe right actions too.

@chlebta

This comment has been minimized.

Show comment
Hide comment
@chlebta

chlebta Oct 21, 2016

@mtnbarreto -
I'm trying to create swipe to left but it doesn't work this is my code ( those function are never called ):

    func tableView(_ tableView: UITableView, editActionsForRowAt indexPath: IndexPath) -> [UITableViewRowAction]? {
        let action = UITableViewRowAction(style: .destructive, title: "Delete") { (action, indexPath) -> Void in
        }
        return [action]
    }

    func tableView(_ tableView: UITableView, canEditRowAt indexPath: IndexPath) -> Bool {
        switch indexPath.section {
        case 2:
            return true
        case 3:
            return true
        default:
            return false
        }
    }


    func tableView(_ tableView: UITableView, commit editingStyle: UITableViewCellEditingStyle, forRowAt indexPath: IndexPath) {
        if (editingStyle == .delete) {
            print(indexPath)
        }
    }

chlebta commented Oct 21, 2016

@mtnbarreto -
I'm trying to create swipe to left but it doesn't work this is my code ( those function are never called ):

    func tableView(_ tableView: UITableView, editActionsForRowAt indexPath: IndexPath) -> [UITableViewRowAction]? {
        let action = UITableViewRowAction(style: .destructive, title: "Delete") { (action, indexPath) -> Void in
        }
        return [action]
    }

    func tableView(_ tableView: UITableView, canEditRowAt indexPath: IndexPath) -> Bool {
        switch indexPath.section {
        case 2:
            return true
        case 3:
            return true
        default:
            return false
        }
    }


    func tableView(_ tableView: UITableView, commit editingStyle: UITableViewCellEditingStyle, forRowAt indexPath: IndexPath) {
        if (editingStyle == .delete) {
            print(indexPath)
        }
    }
@48clyde

This comment has been minimized.

Show comment
Hide comment
@48clyde

48clyde Oct 26, 2016

I've built Eureka as a framework and added it to my project. I found that I needed to use @objc to change the name of some methods. I'm not sure quite why, it may be an artefact of the fact that FormViewController has UITableViewDelegate specified as an extension.

The following code produces the NSLog messages as expected at the right times when swiping on a row, but I now have the problem if I try and delete a row, exceptions are thrown because there are observers on the row.

In my class MyFormViewController: FormViewController {

@objc(tableView:canEditRowAtIndexPath:)
    open func tableView(_ tableView: UITableView, canEditRowAt indexPath: IndexPath) -> Bool {
        NSLog(#function)
        return true
    }
 open func tableView(_ tableView: UITableView, editingStyleForRowAt indexPath: IndexPath)  -> UITableViewCellEditingStyle {
        NSLog(#function)
        return .delete
    }
 @objc(tableView:editActionsForRowAtIndexPath:)
    open func tableView(_ tableView: UITableView, editActionsForRowAt indexPath: IndexPath) -> [UITableViewRowAction]? {
        NSLog(#function)
        let more = UITableViewRowAction(style: .default, title: "Delete") { action, index in
            NSLog("Delete action called")
        }
        return [more]
    }

48clyde commented Oct 26, 2016

I've built Eureka as a framework and added it to my project. I found that I needed to use @objc to change the name of some methods. I'm not sure quite why, it may be an artefact of the fact that FormViewController has UITableViewDelegate specified as an extension.

The following code produces the NSLog messages as expected at the right times when swiping on a row, but I now have the problem if I try and delete a row, exceptions are thrown because there are observers on the row.

In my class MyFormViewController: FormViewController {

@objc(tableView:canEditRowAtIndexPath:)
    open func tableView(_ tableView: UITableView, canEditRowAt indexPath: IndexPath) -> Bool {
        NSLog(#function)
        return true
    }
 open func tableView(_ tableView: UITableView, editingStyleForRowAt indexPath: IndexPath)  -> UITableViewCellEditingStyle {
        NSLog(#function)
        return .delete
    }
 @objc(tableView:editActionsForRowAtIndexPath:)
    open func tableView(_ tableView: UITableView, editActionsForRowAt indexPath: IndexPath) -> [UITableViewRowAction]? {
        NSLog(#function)
        let more = UITableViewRowAction(style: .default, title: "Delete") { action, index in
            NSLog("Delete action called")
        }
        return [more]
    }
@pauliwang

This comment has been minimized.

Show comment
Hide comment
@pauliwang

pauliwang Nov 3, 2016

One use case is if you are adding multiple values of a type but don't have a predefined set of options to choose from. As you add more values, it could display the values in a dynamic LabelRow but if you decide you want to remove one of the values, you can just swipe left to delete that entry.

pauliwang commented Nov 3, 2016

One use case is if you are adding multiple values of a type but don't have a predefined set of options to choose from. As you add more values, it could display the values in a dynamic LabelRow but if you decide you want to remove one of the values, you can just swipe left to delete that entry.

@marbetschar

This comment has been minimized.

Show comment
Hide comment
@marbetschar

marbetschar Dec 9, 2016

Contributor

@mtnbarreto - do we have sort of specified direction in terms of how this issue goes further?

Is there an approach of how both swipe directions may be implemented best and if so, will this be part of Eureka core?

Contributor

marbetschar commented Dec 9, 2016

@mtnbarreto - do we have sort of specified direction in terms of how this issue goes further?

Is there an approach of how both swipe directions may be implemented best and if so, will this be part of Eureka core?

@marbetschar

This comment has been minimized.

Show comment
Hide comment
@marbetschar

marbetschar Dec 13, 2016

Contributor

Together with @mathmatrix828 we started working on multivalued sections. As we both have limited time, help is very welcome! If any of you wants to see the multi valued section issue and/or the swipeable actions issue closed, please chime in!

And here's the plan:

As proposed here: #17 (comment) - my preferred way of managing items in a multivalued section would be by swiping to the left for removing, and swiping to the right for adding a new item. In order for this to work, we first have to add the basic functionality for multivalued sections.

As said, this is just a proposal - I'm open for any suggestions.

Contributor

marbetschar commented Dec 13, 2016

Together with @mathmatrix828 we started working on multivalued sections. As we both have limited time, help is very welcome! If any of you wants to see the multi valued section issue and/or the swipeable actions issue closed, please chime in!

And here's the plan:

As proposed here: #17 (comment) - my preferred way of managing items in a multivalued section would be by swiping to the left for removing, and swiping to the right for adding a new item. In order for this to work, we first have to add the basic functionality for multivalued sections.

As said, this is just a proposal - I'm open for any suggestions.

@marbetschar

This comment has been minimized.

Show comment
Hide comment
@marbetschar

marbetschar Jun 14, 2017

Contributor

@mtnbarreto was busy in other projects the last couple of months, therefore things went a bit silent here. Now I'd like to start a new attempt for Swipeable Rows.

I'd like to implement them using the new iOS11 features - with which branch should I start best? master oder swift-4?

Contributor

marbetschar commented Jun 14, 2017

@mtnbarreto was busy in other projects the last couple of months, therefore things went a bit silent here. Now I'd like to start a new attempt for Swipeable Rows.

I'd like to implement them using the new iOS11 features - with which branch should I start best? master oder swift-4?

@mats-claassen

This comment has been minimized.

Show comment
Hide comment
@mats-claassen

mats-claassen Jun 14, 2017

Member

If you want to go with iOS 11 features then you should start with the swift-4 branch. You have to remember that there might be changes to that branch until Xcode 9 (non-beta) is out.

Eureka currently supports from iOS 8 onwards. I think any new feature should support at least iOS 9.

Member

mats-claassen commented Jun 14, 2017

If you want to go with iOS 11 features then you should start with the swift-4 branch. You have to remember that there might be changes to that branch until Xcode 9 (non-beta) is out.

Eureka currently supports from iOS 8 onwards. I think any new feature should support at least iOS 9.

@MatrixSenpai

This comment has been minimized.

Show comment
Hide comment
@MatrixSenpai

MatrixSenpai Jun 19, 2017

Agreed, I'd go with swift-4. I've been pretty bogged down recently and am not sure when I'll be available since I have a bunch of things coming up soon, but I'll try to pitch some time if I have any

MatrixSenpai commented Jun 19, 2017

Agreed, I'd go with swift-4. I've been pretty bogged down recently and am not sure when I'll be available since I have a bunch of things coming up soon, but I'll try to pitch some time if I have any

@kronik

This comment has been minimized.

Show comment
Hide comment
@kronik

kronik Nov 1, 2017

Has anyone a pull request?

kronik commented Nov 1, 2017

Has anyone a pull request?

@marbetschar

This comment has been minimized.

Show comment
Hide comment
@marbetschar
Contributor

marbetschar commented Nov 1, 2017

#1249

@mats-claassen

This comment has been minimized.

Show comment
Hide comment
@mats-claassen

mats-claassen Mar 5, 2018

Member

Has been merged in #1361

Member

mats-claassen commented Mar 5, 2018

Has been merged in #1361

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