Let’s take a step back and see how things scale without the use of 9-slicing before explaining how it works. If you are developing an application and would like to add a background image to certain elements of your application – say, a TextArea to give it more emphasis – and begin with the following image:

The idea with the above image is that the colored area will work as our border, leaving the white area to handle the content. The above image works fine as long as the component being used is fits into the white area, but what if it is larger? If the component grows to 100x450px then we will end up with a component that ends up looking like this:

The end result does not look very appealing. As the image scales in size so does the width and height of the border by default resulting in a top border that is more narrow than the side borders and stretched corners. Ideally what we would like is for the border to stay uniform no matter the size the entire image scales. To achieve this, we use 9-slicing which results in the following image:

The result is that we have taken a 30x30px, 135-byte image and scaled it up to 100x450px without losing the scale of the border. The way this is done is by taking the original image file and slicing it into 9 sections: 4 corners that always stay to their original scale, 1 center which scales to fill, 2 (top and bottom) edges which scale horizontally only and 2 (left and right) edges that fill vertically only.

Using this method keeps the corners of the image crisp and only applies scaling to the portions of the image that will not be noticeable to the eye, and in a way that keeps the proportions of things like the black border uniform around the image at any scale:

Using 9-slicing in the Cascades framework is extremely easy. If you have used an ImageView to display an application image then you are already halfway there. If you have an image named background.png then you would create an ImageView component similar to this:

ImageView {
imageSource: "asset:///images/background"
}

The next thing you would need to do is create a new file named background.amd in the same directory as background.png where the name of the files must match exactly except for the extension. This new file – background.amd – will be a plain text file with one line of text:

sliceMargins:20 20 25 34

The numbers in this file represent the left, right, top and bottom margins respectively. The framework will read this file automatically when loading the image because it shares the same name as the image file and apply the 9-slicing to have the image scaled to your specifications. This can be used to provide all sorts of neat borders that continue looking good when used throughout your application. Keep in mind that images displayed this way will be loaded synchronously with the rest of the UI. The below example shows a TextArea with a custom border:

Now you have the tools and knowledge, let’s see what you can make with them!

Nothing is more frustrating than putting countless hours of hard work into your BlackBerry® app, making sure every subroutine is perfect and every millisecond of performance squeezed, only to find out that users are displeased with some aspect of layout or interaction. Speaking from experience, I find that numerous times we all too often dive into architecting and developing the meat and potatoes of an app, leaving the user interface to get created ad hoc. Yet behind every good app there is a great user interface!

Now, you might be saying: “But Matt! I do think about layout and design – but I can’t design for every user’s tastes.” While we do typically put some thought into layout and design, I find we (as developers) rarely think about it from an end user’s perspective. We are too close to the project, and end up seeing aspects of the application from a specific view. Think of it this way – every parent thinks their baby is the cutest ever…but what do the rest of us think? What a good app developer/designer needs to do is take a step back and look at the design from others’ points of view and, better yet, gather points of view from others.

Nothing helps guide a design better than real world feedback. Take your design and layouts and talk to your peers, your mother, your granddad, or even your future end users (basically anyone that will talk to you.) You can even solicit feedback from a limited beta of your app or use various online solutions such as getsatisfaction.com. Ask your users what they like, what they don’t like, how they would expect things to flow, and so on. Taking this feedback and integrating it into your app will help ensure users are happy – and happy users mean good BlackBerry App World™ storefront ratings!

If you cannot easily gather end user feedback on the design and flow of your app, here are some other points to keep in mind at the beginning of your project:

• Keep the user interface and design as simple as possible. Your app should require a user to have little to no instructions in order to get started.
• For touch screen devices, ensure proper spacing of objects that a user will interact with. Nothing will frustrate your users more if their touch events are misread.
• The layout of the screen should be well used, but not too cluttered. For objects in groups, space them evenly for a clean look.
• Make use of menus when required. Menus are great when there are additional options or settings that you want a user to have access to, but don’t want to have them always displayed on screen.
• Lastly, remember to keep your app consistent. Every screen within the app should offer a similar user experience in layout, theme and flow. A user should know this is your app regardless of the screen they are looking at.

Hopefully you have found these tips useful. If you have your own, please share them in the comments section below or head on over to the BlackBerry Developer Support forums and post them there.

public TableLayoutManager(int columnStyles[], long style)

public TableLayoutManager(int columnStyles[], int columnWidths[], int
horizontalPadding, long style )


columnStyles[] defines the styles for all columns, and the number of this array refers to the number of columns desired in a given row. The different column styles to choose from are listed below:
USE_PREFERRED_SIZE – Allows the field to use up all the space it needs.
USE_PREFERRED_WIDTH_WITH_MAXIMUM – Allows the field to use up as much space as it needs UP TO a preset maximum. You can specify the maximum for each field by passing in the width in the columnWidths variable.
SPLIT_REMAINING_WIDTH – Columns will use up the remaining width evenly.
FIXED_WIDTH – Sets columns to a fixed width.

The SPLIT_REMAINING_WIDTH style can be thought of as the “this column will utilize all the remaining width of the table” style. So if TableLayoutManager has a column defined as SPLIT_REMAINING_WIDTH in conjunction with Manager.USE_ALL_WIDTH, the column will fill the remaining space. If there are multiple columns defined as SPLIT_REMAINING_WIDTH, they will evenly share that remaining width.

style – is the manager style. You can just choose from Manager. HORIZONTAL_SCROLL, Manager.xxxx.

columnWidths – if you choose you can specify widths to be used for each field for force particular columns size.

horizontalPadding – you can also specify horizontal padding between columns .

As you can see above, it’s pretty easy to define the desired amount of columns. Based on number of fields added to the layout, TableLayoutManager will automatically align them in separate rows to keep the desired number of columns. This can often be a helpful feature, as developers won’t need to know the number of rows their table may have at construction time.

Now let’s explore some views that are possible with TableLayoutManager.

Example 1: Say you are building your next great application that requires cover art to be displayed as a grid like view.

This view has five columns, each of which is a BitmapField and each field will accept focus  . This table can be constructed very easily with TableLayoutManager. Here is a code sample of how I constructed the table:

TableLayoutManager colFMgr = new TableLayoutManager(new int[]
{
TableLayoutManager.USE_PREFERRED_SIZE,
TableLayoutManager.USE_PREFERRED_SIZE,
TableLayoutManager.USE_PREFERRED_SIZE,
TableLayoutManager.USE_PREFERRED_SIZE,
TableLayoutManager.USE_PREFERRED_SIZE
}, Manager.HORIZONTAL_SCROLL);

for(int i= 0;i < images.length;i++) {
colFMgr.add(new BitmapField(images[i],Field.FOCUSABLE));
}
add(colFMgr );

If you want a little more control on bitmap sizes and how the layout manager uses each cell size you can use the other constructor to pass in widths for each column.

Example 2: Now say I wanted some text below each image but did not want the text to take primary focus.

As you can see, it’s the same structure as Example 1, but for every five BitmapFields, I would have to add five Label fields and disable focus on the Labels. TableLayoutManager will take care of the layout and ordering.

Example 3: Now consider using a table view where the left column contains an image and right columns contain some textual description with a ‘more’ link.

Conceptually, the per-row view in wireframe would be an outer table with 2 columns:

And an inner table with two columns to host some textual description:

The inner table is inserted within the COL 1 of the outer table to get our desired view for a given row. Note that the space alignments are configurable based on the style you choose on the layout manager.

Now that we have constructed each row, you can keep adding COL 1(flower art bitmap) and COL 2 (inner table) and it will take the form as shown in the Example 3 screen shot. All this translates in very little code using TableLayoutManager:

TableLayoutManager outerTable = newTableLayoutManager(new int[]
{
TableLayoutManager.USE_PREFERRED_SIZE,
TableLayoutManager.SPLIT_REMAINING_WIDTH
},0);

For constructing the inner table:

TableLayoutManager innerTable = new TableLayoutManager(new int[]
{
TableLayoutManager. USE_PREFERRED_SIZE,
TableLayoutManager.USE_PREFERRED_SIZE
}, Manager.USE_ALL_WIDTH);

In the second case, USE_ALL_WIDTH causes the table to fill the maximum width space. The first USE_PREFERRED_WIDTH will allow COL 1 to take up the minimum necessary amount of space, and COL 2 will automatically fill to fit. If you want COL 2 to use the minimum size, set COL 1 to SPLIT_REMAINING_WIDTH.

Here’s how to add the fields to the inner table:
innerTable.add(titleField);
innerTable.add(titleField1);
innerTable.add(descriptionField);
innerTable.add(descriptionFieldLink);
innerTable.add(ratingField);
innerTable.add(ratingFieldImage);

And how to add a bitmap field to the outer table and add the inner table.
outerTable.add(Bitmap.getBitmapResource("image1.png")));
outerTable.add(innerTable);

To add more rows to this table, keep adding bitmaps and inner tables to the outer table. And don’t forget to add the outer table to the Screen!
super.add(colFieldMgrForRow);

This is not the only way to build a layout like this. For example, for each row I can use a horizontal layout manager (hfm) with two columns. The second column for this hfm would need a vertical field manager (vfm), for which I need three hfm for each row of text (title, description, rating etc). So really there is no one size fits all for layout management. It’s simply a matter of picking the right one that works for your application.