Layout Lifecycle and Customization


Let us assume we have a view called pv and it has a child view called cv. Here is a flow how Rikulo handles the layout pv (triggered by, say, View.requestLayout).

Lifecylce of Layout

  • The handling of layout is taken from the parent to its child views. In other words, in this case, pv will be handled and then cv.
  • When handling the layout, View.measureWidth_ and View.measureHeight_ will, if necessary, be called recursively from the parent to its child views to measure the dimension.
  • View.onPreLayout_ will be called after the view has been handled, but before its child views. On the other hand, View.onLayout_ will be called after the view and all of its child views are handled.
  • Instead of overriding them, the application is suggested to listen the preLayout and layoutevent instead, if necessary. They are sent by the default implementation of View.onPreLayout_ and View.onLayout_ respectively.
  • View.doLayout_ is called to handle the layout of child views. The default implementation delegates the invocation to LayoutManager, which will then delegate to the right implementation of Layout.
    • Notice, though a bit subtle, View.doLayout_ is not called to layout the given view, which is handled by the parent's invocation of doLayout.


You can provide additional layouts or replace the existent ones. To do so, you first implement the Layout interface. Then, register it to LayoutManager. For example, assume you implement a tile layout, called TitleLayout, and you can register it as follows.

layoutManager.addLayout("tile", new TileLayout());

Then, you can use it in your application:

view.layout.type = "tile";