5

Without going into too much detail, I want to be able to 'slide' elements in a ListView similar to the 'slide to archive' feature in GMail. I'm fine with the onTouchListener and all that, my question is regarding the slide animation.

The first two things that come to mind are..

view.setPadding(slideOffset, 0, 0, 0);

and..

view.setX(slideOffset);

The former is very buttery, even on the emulator.
The latter is a bit janky on my Galaxy Nexus.

My questions:
* Regardless of what I've tried, what's the correct way to do this?
Why is setX less smooth than setPadding?
Does one approach conform to Android best practices more than the other?
Are tweened translation animations an option? If so, can you provide a brief example to point me in the right direction please?

Edit:
To be clear, I am attaching an image of the effect I am trying to emulate.

enter image description here

Sean Connolly
  • 5,692
  • 7
  • 37
  • 74
  • I'm going to let the bounty run on this. I'm not sure if this problem doesn't have a good answer or if I'm just not asking the right question. Perhaps an elegant solution will present itself in time. – Sean Connolly Feb 12 '13 at 20:33

3 Answers3

1

I'm pretty sure the setX() is slower because it affects its parents. When changing the X of a view, it calls the onLayout/onMeasure of the parent every time you update the value. That's because the X value of the child may cause other items on the parent to move, therefor the parent needs to redraw itself.

You can test this easily by extending the ViewGroup and writing to the log on those methods. Then, you can use both approaches, padding vs. setX, and see what happens.

Are you trying to animate the item? Or do you want the user to move it like on Gmail? You can use the ObjectAnimator to handle the "X" value of your item. Combined with a "hardware layer" for your item, it will create a smoother experience. You can find more details about how to do that here: http://developer.android.com/guide/topics/graphics/hardware-accel.html

Udinic
  • 3,014
  • 2
  • 25
  • 32
  • That seems to make a lot of sense about the onLayout/onMeasure calls. Would there be any way to circumvent this or would this be a reason to use padding instead? Or, is padding just a hack? I'd prefer the item to follow the user's finger, so no animation is necessary. Is ObjectAnimator appropriate if the target location is constantly changing - such as in following a touch location? – Sean Connolly Feb 06 '13 at 11:46
  • In that case - animation is not the right approach. You can still try creating a "hardware layer" for the item, which could make it easier for the GPU to draw as you move it. Don't forget to remove the layer after you done. Tell us how it went. – Udinic Feb 06 '13 at 12:31
1

Yeah, if you're targeting higher APIs, ViewPropertyAnimator is probably a great solution. If you have to support lower APIs, my thought process for implementation would be (and I haven't implemented this myself personally, but this should be good for performance) to:

  1. In your touch handler, once you've determined that the user is "sliding", set the View's visibility to INVISIBLE, and store the drawing cache into a separate bitmap (Bitmap bmp = myView.getDrawingCache();)

  2. Draw that bitmap in the same place as the view, and use the Canvas translate methods to shift the position according to the x-position of the user's touch point.

  3. After the user lets go, translate back (preferably smoothly with an animation), recycle the bitmap, and set the view back to VISIBLE.

Kevin Coppock
  • 133,643
  • 45
  • 263
  • 274
  • I've passed this comment on to some friends, some who know about Android and/or programming, and some who don't. All shared my feeling that if this is the correct way to do things like this, it doesn't look good for Android. Is this the correct way to do things like this in Android? Or is this just a hack to get it done? I'm surprised this isn't a well documented problem with a solution. – Sean Connolly Feb 12 '13 at 12:38
  • Many things in Android feel like hacks. I guess it can be boiled down into which case is best for you. If you're certain that the row won't change, this seems like a good approach. Otherwise, I would use setPadding(). – Janito Vaqueiro Ferreira Filho Feb 21 '13 at 15:55
1

Check out the 3 devBytes posted on AndroidDev:

Mario Lenci
  • 10,422
  • 5
  • 39
  • 50