Android: Alternative to AbsoluteLayout (I really d

Question

I am trying to write a calendar app and I plan to have a grid (week view) which will probably be a TableLayout and directly on top of that I will have to absolutely position events on the grid.

But AbsoluteLayout is deprecated. What should I use instead?

Events may overlap and I think it would be really silly to try and use a non absolute layout to achieve what I want.

Maybe I should use RelativeLayout with a margin left and margin top on each of the child nodes. Seems odd to do it that way and might not be as efficient. Is this the best way or is there an alternative?

Answer 1

But AbsoluteLayout is deprecated. What should I use instead?

Write your own layout manager that implements the rules you want.

Answer 2

• CommonsWare suggested writing my own layout manager and Christian pointed out it sounds easier than it is.
• Yahel suggested SurfaceView/OpenGl and draw whatever I want.

I found out you can recreate absolute positioning by adding your child views to a RelativeLayout and set the RelativeLayout.LayoutParams to have only default values except width, height, marginTop and marginLeft. The top and left margin will be similar to top and left in AbsoluteLayout. Also, negative margins are supported.

Make sure you account for screen density and width and orientation changes and all the other caveats of absolute positioning that used to apply to AbsoluteLayout

If you have problems with getting your content to overflow past the right edge of the screen, try supplementing your positive left margin with an equally negative right margin. (original question)

Answer 3

I would suggest either going the easy way :

1. Setting your calendar for 15(or 30) minutes intervals, this way you don't need absolute positionning. A table view filled with linear view each representing 15 minutes interval and fill these with events.

Or going the hard but a lot more stable/speedy/customisable way :

1. SurfaceView/OpenGl draw your own however you want.

The problem with number 1 is the fact that the more you add elements in your view hierachy the more your app will take a performance hit. Say a conventional month you have 3 appointments a day, your hierarchy will be filled with a hundred views wich will be very long to render and heavy memory-wise too.

The problem with number 2 : Well it's a lot harder to code at first. If you have to write your own layoutmanager, don't, go surfaceview or openGL.