Shared publicly  - 

OK, seems from the last post that lots of folks are interested in an early look at swipe-to-dismiss sample code. Here it is:

YMMV and I wouldn't throw it into production code just yet.

Oh, and if you find bugs (and even better, have fixes), comment here, including a link to your diff/patch/fork/etc. if you have one.
Arkaitz Osa's profile phototofeeq ahmad's profile photoDushyant Patel's profile photoThuy Pham's profile photo
Thank you for sharing Roman! this is going to be a great extension to the already familiar pattern from notifications & task manager. 
+Roman Nurik - do you think this pattern could also apply to a 'mark as read' action? For example, Google+ notifications are never really deleted, but just go from an unread (new) to read (old) state. Seems much easier than opening each one.
+Ian Lake maybe as 'archive' ... the item should definitely disappear from the list, so you'd probably only want to use this if the list represents only unread items.
There's an iOS app that uses this gesture to mark items as read. What I've heard it works really well in that one. Can't remember the name just now.
Why is this a gist?  This should be a library on github~!
you can do it with simple jquery ui
Doesn't K9 Mail support swipe to mark es read? What is the difference? 
+Ian Lake I occasionally find myself trying to swipe to mark a message as read (I already read the message notification and swiped that away). It would be convenient, but as +Roman Nurik pointed out, it would be tricky to implement while maintaining consistency with the "flick off the screen" feel. The bounce Reeder uses seems to confuse the experience.

What do you think of simply swiping the unread "color" off the screen?  For example, unread messages in the ICS messaging app have a white background. Could one swipe this white rectangle with the same slide and fade effects used for notifications? 
Cool. Presents an interesting choice between swiping between pages when designing
Rob G
Look and feel nice. I'm still trying to see where could confirmation come into play and not disrupt the whole UX too much. I wouldn't want user to accidentally deleting an email or note with no way to bring it back.
The Android way is "swipe to remove from the list". I don't think that "swipe to keep in the list but change state" would feel natural to Android users.
Rob G
True, but at the moment it would only be good for the list of notifications or item that can repopulate by itself. Which, I think would be a waste since this would be really useful for list-heavy application.
There seems to be an update view bug with this when used with Jelly Bean, works fine under ICS. +Roman Nurik and +Jake Wharton is that anything you have seen? On Jelly Bean calling listAdapter.notifyDataSetChanged() in onListItemClick when having set the OnTouchListener to an instance of SwipeDismissListViewTouchListener does not update that clicked view (does not call getView() for that item). Works fine under ICS. Something changed (or regression/fix!?) in JB?

Update: Have only tested it with +Jake Wharton's backport.

Complete code to reproduce, not the best place to attach code, but anyway:

public class MainActivity extends ListActivity {
    ArrayAdapter<String> listAdapter;

    public void onCreate(Bundle savedInstanceState) {
        listAdapter = new ArrayAdapter<String>(this, android.R.layout.simple_list_item_1, new ArrayList<String>(Arrays.asList(
                "Item 1", "Item 2", "Item 3"))) {
            public View getView(int position, View convertView, ViewGroup parent) {
                // not called for the clicked item on Jelly Bean
                Log.i("ListTest", "pos=" + position + ", convertView=" + convertView);
                return super.getView(position, convertView, parent);
        ListView listView = getListView();
        SwipeDismissListViewTouchListener touchListener = new SwipeDismissListViewTouchListener(listView,
                new SwipeDismissListViewTouchListener.OnDismissCallback() {
                    public void onDismiss(ListView listView, int[] reverseSortedPositions) {
                        for (int position : reverseSortedPositions) {
        listView.setOnTouchListener(touchListener); // comment out this and it works

    public void onListItemClick(ListView l, View v, int position, long id) {
implemented it inside ViewPager, dismiss only one direction opposite of the ViewPager direction. Works great on ICS but 2.3 and lower does not work (Its worknig when its not in ViewPager), touch get canceled event.

Any Idea someone?
Thx +Roman Nurik and +Jake Wharton for this share.
A little remark after some tests. Why put a max Velocity in the swipe gesture? I'm able to do fast swipe and so do not remove the item.
Second point, for me the min velocity used is too small. I'm able to make a swipe gesture instead of a click.
What do you think about that ?
Yes, I have the same problem. I am trying to select an item clicking it and accidentally deleted it...
+Roman Nurik what do you think about using STD on a tablet layout? The listview goes on the left column and the detail fragment on the right. It's not very intuitive, better to put an icon on the action bar when the item is selected?
it very nice! Thanks man! i think it will be good if have undorbar.
any idea if this would work with CursorAdapters??
Most anticipated for iPhone lover shifted to android and now want their android app should look like Android. BTW you have done great work and continue doing this.
Add a comment...