08-28-2012 01:45 AM
08-28-2012 04:11 AM
08-28-2012 04:21 AM
I don't think you will get a better explanation because the the situations in which layout is required are many and varied. For example, a user typing into an EditField will cause a layout of the EditField each time a character is put it. This can cause that EditField to suddenly extend to another line, and when it does this, it changes size in which case its Manager needs to re-layout its Fields. You could have a FieldChangeListener based on this EditField which adds a 'go button' when the size of the EditField reaches a certain stage, again a new layout. All of this happens after the Field is actually on display.
I suggest the best thing that you can do, when you are not clear on what is going to happen, is describe the circumstances that you face and ask for help in creating the custom manager.
You have design how the whole screen display is going to work before you start. So if you have a custom Manager and it depends on another custom manager, the second custom manager can't depend on the size of the first.
And remember you do have control. For example, say you need a Manager whose job it is to fill the screen. On the landscape format devices, it will do this every time, but on portrait format devices it might not - this meant there could be space at the bottom. So this Manager lays itself out, then figures out how much space it uses, compares this with the space it has available, and if it does not fill the screen, it lays itself out again with more spacing between the Fields.
So look at your requirements, design Managers to provide it, and the layout problems should be solved.
08-29-2012 02:34 AM
08-29-2012 02:43 AM
08-29-2012 05:23 AM
In addition to the parent child example that Simon has given you, here is another to explain this:
Say you are trying to create a section at the bottom of a screen that you can use, like the status area of a MainScreen. So you add a scrolling Manager (call this the ScrollingManager) to your screen, and then the Manager which is going to be at the bottom (call this the BottomManager).
Now the actual height used in your setExtent for the ScrollingManager will depend on the height of the BottomManager. So you have got to actually layout the BottomManager first, and then layout the ScrollingManager using the height (Display.getHeight() - BottomManager.getHeight(). This works fine.
Now I made this comment:
"'So if you have a custom Manager and it depends on another custom manager, the second custom manager can't depend on the size of the first.'"
In fact now that I re-read that comment, it does not make sense. All I was trying to say is that you can get yourself in recursive issues where layout 1 depends on layout 2, layout 2 depends on layout 3, and layout 3 depends on layout 1. This doesn't work, but then this sort of problem is not specific to layouts, it happens in all code. So, forget that comment.