A method organization strategy for Android activities

Using the principles of low-coupling and high cohesion, our class files shouldn't balloon out of control to the point where single line method signatures get lost amongst the trees, but it doesn't hurt to have an extra layer of organization on which developers can agree. It's an inevitable fact that we have to read each other's code. The list below reflects how I organize methods in an Android Activity class at the moment. I wouldn't mind making this an exhaustive list so if you got any ideas....speak up.. :).

1. Constructors – default followed by paramterized (public, then package, then private).
2. Any method that overides Activity lifecycle events, starting with onCreate(). The rest should follow in the order that they are called on the activity lifecycle stack.
3. Next come any classes that override an interface. These should all be appended with the @Override annotation.
4. Include the @Override annotation also on any methods that override an abstract class implementation. First list the methods you are forced to override from the abstract class, followed by the methods that you chose to override.
5. Next come any methods that are being optionally overriden from any concrete superclass.
6. Then we list our public methods that are specific to this class. I like to start with the public methods that have more meat to them, followed by the getters and setters.
7. Package-level implementations are next.
8. Private methods follow the package-level ones.
9. After the private methods come the abstract methods. I like the abstract methods down here so that when another programmer is looking at this abstract class and wants to find out which methods this class does not implement, he or she can scroll to the bottom. Those one-line method signatures don't get lost among the methods that have a heavier implementation.