Field Alignment Using RIM's Alignment Styles
| It is more efficient to align fields manually by overriding sublayout() since it does not require extra wrapper managers. See Centering a Field in a HorizontalFieldManager for an example. |
Field alignment is not as straight forward as it could be on the Blackberry. The
Field class provides the following style bits for alignment:
- Horizontal alignment styles
- FIELD_LEFT
- FIELD_HCENTER
- FIELD_RIGHT
- Vertical alignment styles
- FIELD_TOP
- FIELD_VCENTER
- FIELD_BOTTOM
The horizontal alignment styles are only recognized when a Field is added to a VerticalFieldManager, and the vertical alignment styles only apply when a Field is added to a HorizontalFieldManager. Below is a simple example that should illustrate the basic idea.
Creating a HorizontalFieldManager containing fields aligned to either side
We'll assume you've created the following objects:
ButtonField leftField = new ButtonField( "Left", null, Field.FIELD_LEFT ); ButtonField rightField = new ButtonField( "Right", null, Field.FIELD_RIGHT ); HorizontalFieldManager horizontalFieldManager = new HorizontalFieldManager();
Fields added to a HorizontalFieldManager are ALWAYS aligned to the left. This is the correct behavior for the leftField, so we can simply add it directly to the HorizontalFieldManager:
horizontalFieldManager.add( leftField );
The rightField on the other-hand MUST be added to a VerticalFieldManager in order to be aligned to the right. We can accomplish this with the following code:
VerticalFieldManager rightFieldManager = new VerticalFieldManager(Field.USE_ALL_WIDTH);
rightFieldManager.add( rightField );
horizontalFieldManager.add( rightFieldManager );
We must create a VerticalFieldManager that consumes the remaining width of the HorizontalFieldManager. When the rightField is added to this VerticalFieldManager it will be aligned to the right side of the manager, and subsequently to the right side of the screen.

Comments (6)
Jul 20, 2009
Martin Reed says:
Aligning Fields in a HorizontalFieldManager is a common problem. The main oversi...Aligning Fields in a HorizontalFieldManager is a common problem. The main oversight is that the HorizontalFieldManager will auto-shink to the actual size used. This means that even though you specify a Field to be right aligned, it will be next to the left Field. This is expected, given the constructor arguments. You must provide the style of "USE_ALL_WIDTH | NO_HORIZONTAL_SCROLL" to have it layout correctly. See also Centering a Field in a HorizontalFieldManager for manual Field alignment.
The way your workaround is working is because the VerticalFieldManager will automatically use all width and grow the HorizontalFieldManager for you.
Jul 20, 2009
Mark McEver says:
Martin and I tried the method he mentioned on the screen in eReader that prompte...Martin and I tried the method he mentioned on the screen in eReader that prompted me to post this (see ERDR-1209), but it didn't work. In the past we've overridden sublayout to accomplish this sort of task. Unfortunately, overriding sublayout was the method originally used to implement this, and it prevented the field from being selected on the Storm when the device was in landscape mode. Martin reviewed the previous sublayout() code and did not see a problem with it.
I seem to have run accross a screnario on eReader's SignInContainer where calling setPositionChild() causes significant problems on the Storm. I also think overriding sublayout() is unnecessarily error prone.
I suspect that RIM's method of Field alignment is very reliable, as long as you use horizontal alignment styles within a VFM, and vertical alignment styles within an HFM.
I think perhaps we should stop overiding sublayout() unncessarily. Martin disagrees because of the performance implications adding extra managers just for alignment. I think the performance implications are negligible.
Jul 20, 2009
Martin Reed says:
By not overriding the Abstract Managers we have built, you are losing the automa...By not overriding the Abstract Managers we have built, you are losing the automatic setting of the Virtual Extent in onSublayout(), which is where one of the solutions for the Storm TouchEvents is handled... along with all performance enhancing features (layout suspension). The original code did not utilize this.
Jul 20, 2009
Andrew Cowart says:
So the original problem of not handling focus well was likely due to using RIM's...So the original problem of not handling focus well was likely due to using RIM's managers and overriding sublayout, instead of using Metova's managers and overriding onSublayout?
Jul 24, 2009
Mark McEver says:
I haven't been ignoring your message. You guys are probably right. Once I'm wo...I haven't been ignoring your message. You guys are probably right. Once I'm working on BB again I'll test to make sure.
Jul 28, 2009
Mark McEver says:
You are correct, overriding AbstractHorizontalFieldManager instead fixed the tou...You are correct, overriding AbstractHorizontalFieldManager instead fixed the touch problems on the Storm.