One of the great things about jQuery mobile and other web technologies is that you can find a lot of components and examples out there. Almost every single type of visual element can be found online and there is no need to build it yourself. This is kind of the opposite of the native environment, where most of the times you need to build your own components; this commonly ends with taking a different direction in order to avoid that path. But with Cascades and QML, that’s old news.

Today we were asked if we have a QML component that behaves like the Collapsible on jQuery. And the answer is no – unless you wait for 10 minutes and you build it yourself. Yes, it only took me 10 minutes to have that component ready to be used by anybody within Cascades.

So, let’s see how that happened.

First of all I created a QML file called ExpandableItem.qml. I created on a separated file so we can then reuse the code on any screen within the application.

Second step was to include the visual components. In this case, I included a Button and a Label:

    Button {
        id: btnHeader
        text: "default header"
    }
    Label {
        id: lblBody
        text: "default body"
    }

This will give us the two components we need to build our new expandable component. Then I added some styling:

    Button {
        id: btnHeader
        text: "default header"
        preferredWidth: maxWidth
    }
    Label {
        id: lblBody
        text: "default body"
        textStyle.fontStyle: FontStyle.Italic
    }

And this was the first result we got:

After defining our components, it was then time to define our properties, which allows us to interact with the UI component. In this case, we needed at least these ones to control the basic behavior:

    property alias headerText: btnHeader.text
    property alias bodyText: lblBody.text
    property alias bodyVisible: lblBody.visible
    property string collapseImage
    property string expandImage

I said “at least” because you can include as many properties you want to tweak your inside components. These are the basics to control the behavior of the expandable component. You can set the default imageSource of your button by including this line on your Button element:

        imageSource: collapseImage

It was then time to include our user interaction scripts. This allowed the user to interact with the component, and it reflects the user’s will.

I included two pieces of code:

a) for handling the click event on the Button:

        onClicked: {
            if (bodyVisible) {
                lblBody.visible = false;
                btnHeader.imageSource = expandImage;
            } else {
                lblBody.visible = true;
                btnHeader.imageSource = collapseImage;
            }
        }

b) to handle the change of the visibility of the body text:

    onBodyVisibleChanged: {
        if (bodyVisible) {
            btnHeader.imageSource = collapseImage;
        } else {
            btnHeader.imageSource = expandImage;
        }
    }

And this is what our new UI component looks like:

Now it is time to use it! And it is as easy as this, for example:

        ExpandableItem {
            headerText: "click to expand"
            bodyText: "this is my custom body text"
            expandImage: "asset:///images/expand.png";
            collapseImage: "asset:///images/collapse.png";
            bodyVisible: false
        }

And you will see this:

Or, you can have the body displayed by default:

        ExpandableItem {
            headerText: "click to expand"
            bodyText: "this is my custom body text"
            expandImage: "asset:///images/expand.png";
            collapseImage: "asset:///images/collapse.png";
            bodyVisible: true
        }

With this as a result:

As you can see, it is easy to create your custom components and replicate some standard logic out there. Keeping in mind the fact that these UI components are Native components, I think this is a big deal!

This example can be found on our Github page.

If you have Cascades questions, please don’t hesitate to ping me on Twitter at @bryantafel.

Qt is an important part of our BlackBerry 10 Cascades framework. We were proud to be part of Qt Developer Days in Santa Clara, where we had our own booth set up to showcase the BlackBerry 10 OS and to speak to developers about the excitement surrounding the upcoming BlackBerry 10 launch event on January 30th (not long to go now!). Some developers did not really know what BlackBerry 10 was but after seeing the platform for themselves, they shared our excitement. This was a user interface that they had not seen before, and something a lot of the MeeGo community liked with its simple but powerful gestures.

Alec Saunders, VP Developer Relations at RIM, had a keynote speech where he presented our BlackBerry 10 ecosystem story. He also spoke to RIM’s involvement with Qt and how developers can be rewarded for porting their Qt applications to BlackBerry 10. BlackBerry World is a going to be a level playing ground for your applications to actually have a chance of being discovered and not lost in the crowd like on other platforms.

We seeded eager developers with BlackBerry 10 Dev Alpha testing devices for them to port over their existing MeeGo / Symbian Qt applications, and also provided technical support. For Qt Mobile Application Developers, BlackBerry 10 offers the ability to get a return on your existing development investments. Depending on the complexity of your application, the port over to BlackBerry 10 can really be a painless experience.

We do realize that not everyone can get to these events, and so we have the BlackBerry Qt Porting Program, an online offer so that eligible developers can get their hands on BlackBerry 10 Dev Alpha testing devices. For complete details, see the Official Program Terms and Conditions.

What you need to do is:

• Become a BlackBerry World Vendor.
• Submit your porting plan to bring your Qt app to BlackBerry 10 for approval at https://developer.blackberry.com/offers/qt

We also have an offer of a one-time donation of $10,000 USD to the Qt Project Hosting Foundation if 50 eligible Qt apps are ported to BlackBerry 10 by the Qt Community and then posted and available for sale in BlackBerry World by January 30, 2013 (1)

Criteria:

• Be a BlackBerry World Vendor.
• Apps must be submitted to BlackBerry World by January 20, 2013 and be approved.
• 50 Qt apps must be up for sale in BlackBerry World by January 30, 2013.

It was fantastic being part of Qt Developer Days in Santa Clara, but this is really just the start for us and by no means the end. We are actively working with Digia and the Qt foundation to further strengthen Qt and our relationship with it and also with you.

Below are some links of how we can help you develop for us:

Qt Project Wiki:

• http://qt-project.org/wiki/blackberry

Qt Project Group:

• http://qt-project.org/groups/qt-blackberry-and-qnx

Open Jam Sessions for Qt developers to talk to RIM internal Qt experts about technical problems:

• Qt Live Time with BlackBerry Developer Relations
  • Wednesday, December 12, 2012 @ 10:00 – 12:00 ET
  • https://developer.blackberry.com/devzone/jamcommunity/supportjams/session_registration.html?id=307
• Qt Live Time with BlackBerry Developer Relations
  • Wednesday, December 19, 2012 @ 10:00 – 12:00 ET
  • https://developer.blackberry.com/devzone/jamcommunity/supportjams/session_registration.html?id=308

Porting Qt to BlackBerry 10:

• Porting Qt Applications to BlackBerry 10 is Easier than Ever!
• Writing Qt apps for the BlackBerry 10 platform

Built for BlackBerry and the 10k Developer Commitment:

• http://developer.blackberry.com/10k

1) To be eligible, fifty (50) Qt Apps (“Apps”) must be submitted to BBAW by the Qt Community by 11:59:59 PM Eastern Time (“ET”) on January 20, 2013. Apps will be accepted beginning at 8:00 AM ET on December 8, 2012. Allow a minimum of ten (10) days for BBAW approval. Approved apps must be posted on BBAW for sale on or before January 30, 2013. Apps are not eligible if they simply contain a web launcher or shortcut or a web browser (“Excluded App”). RIM will confirm if Qt Community is eligible for $10,000 USD donation to the Qt Project Hosting Foundation (“Donation”) by February 28, 2013. Allow 8-12 weeks for delivery of Donation. Void where prohibited or restricted by law.

Guest post from Roberto S. – Ed.

Since the introduction of Cascades in May, developers have been asking us one question: Is there something I can do to make my app start faster? Cascades is a marvelous piece of technology, but like any new technology, it takes time to work out the kinks and optimize performance. It took a while, but the Cascades team figured out a way to make it faster. Let me introduce you to Project Zygote.

When a detailed performance analysis was conducted on a Cascades application while it was starting up, it was discovered that loading shared libraries was taking up the majority of time. Cascades uses a number of different Qt and platform-specific libraries, so this made sense. After some investigation, we learned that you can save a lot of time by pre-compiling these shared libraries into one library that could be pre-loaded. Thus, Project Zygote was born.

How do you get in on the party? With this latest beta release of BlackBerry 10, all new Cascades projects will have Zygote enabled by default. You get it for free!

For those with pre-existing projects, there are some minor changes you need to make to your existing projects to enable Zygote for your release target. A little bit of work that goes a long way!

Let’s start by looking at the original project file for the Cascades Cookbook sample app:

TEMPLATE = app
TARGET = cascadescookbookqml

CONFIG += qt warn_on debug_and_release cascades

INCLUDEPATH += ../src
SOURCES += ../src/*.cpp 
HEADERS += ../src/*.h 

device {
	CONFIG(release, debug|release) {		
		DESTDIR = o.le-v7		
	} 
	CONFIG(debug, debug|release) {
		DESTDIR = o.le-v7-g
	}
}

simulator {
	CONFIG(release, debug|release) {
		DESTDIR = o
	} 
	CONFIG(debug, debug|release) {
		DESTDIR = o-g
	}
}

OBJECTS_DIR = $${DESTDIR}/.obj
MOC_DIR = $${DESTDIR}/.moc
RCC_DIR = $${DESTDIR}/.rcc
UI_DIR = $${DESTDIR}/.ui

As mentioned earlier, Zygote is configured primarily for release targets. The reason behind this is that the differences in packaging make it difficult for developers to debug applications built in this way. The first step to upgrading the project configuration is to add a template override from app to lib in the device-release configuration section:

TEMPLATE = app
TARGET = cascadescookbookqml

CONFIG += qt warn_on debug_and_release cascades10

INCLUDEPATH += ../src
SOURCES += ../src/*.cpp 
HEADERS += ../src/*.h 

device {
	CONFIG(release, debug|release) {		
		DESTDIR = o.le-v7
TEMPLATE=lib
QMAKE_CXXFLAGS += -fvisibility=hidden
	} 
	CONFIG(debug, debug|release) {
		DESTDIR = o.le-v7-g
	}
}

simulator {
	CONFIG(release, debug|release) {
		DESTDIR = o
	} 
	CONFIG(debug, debug|release) {
		DESTDIR = o-g
	}
}

OBJECTS_DIR = $${DESTDIR}/.obj
MOC_DIR = $${DESTDIR}/.moc
RCC_DIR = $${DESTDIR}/.rcc
UI_DIR = $${DESTDIR}/.ui

These changes switch the target from an executable to a library and hide the symbols to minimize the size.

The next thing that needs to change is the main.cpp file. Change the main() declaration as follows:

Q_DECL_EXPORT int main(int argc, char **argv)

The last step is to update the bar.descriptor.xml file as follows:

    <configuration id="com.qnx.qcc.toolChain.1485069140" name="Device-Debug">
       <platformArchitecture>armle-v7</platformArchitecture>
       <asset path="arm/o.le-v7-g/cascadescookbookqml" entry="true" type="Qnx/Elf">cascadescookbookqml</asset>
    </configuration>
    <configuration id="com.qnx.qcc.toolChain.1120265426" name="Device-Release">
       <platformArchitecture>armle-v7</platformArchitecture>
       <asset path="arm/o.le-v7/cascadescookbookqml" entry="true" type="Qnx/Elf">cascadescookbookqml</asset>
    </configuration>

Changes to:

    <configuration id="com.qnx.qcc.toolChain.1485069140" name="Device-Debug">
       <platformArchitecture>armle-v7</platformArchitecture>
       <asset path="arm/o.le-v7-g/cascadescookbookqml " entry="true" type="Qnx/Elf">HelloPhone</asset>
    </configuration>
    <configuration id="com.qnx.qcc.toolChain.1120265426" name="Device-Release">
       <entryPointType>Qnx/Cascades</entryPointType>
       <platformArchitecture>armle-v7</platformArchitecture>
       <asset path="arm/o.le-v7/cascadescookbookqml.so" entry="true" type="Qnx/Elf">libcascadescookbookqml.so</asset>
    </configuration>

After making these changes, export your project to a zip file. If you haven’t already done so, create a new workspace. Import the project into the new workspace, change the active build to Device-Release, and clean and rebuild the project. You should have a Cascades Cookbook sample app that starts up faster! My testing showed a reduction in start time from 1.96 seconds to 0.68 seconds. Feel free to convert all of your Cascades apps and spread the word!

Other means to let a device “see” include the light and the proximity sensor. Considering BlackBerry 10 devices as sensors should naturally lead to methods of determining environmental contexts, and providing an unmatched user experience based on those. As a developer you can leverage the following types of sensors in your application: accelerometer, magnetometer, temperature, gyroscope, compass, proximity, holster, rotation sensor, GPS, microphone and camera.

For more information, please take a look at our sensor documentations and start building today.

Documentations are good but samples are readable (well, at least to developers). With that in mind, we also have a full sample application that is both useful and fun to use.

We are very excited about this and look forward to see how you incorporate sensors in your application. Let’s break the false perception that sensors are only meant for games and maps!

Sample Application Example – SensorDemo:

The SensorDemo example demonstrates how to use the QtSensor module to implement the Rotation 3D, Motion Alarm, Compass, Flashlight, Motion Alarm and Collision Detector. This sample made on native layer (Cascades/QML).

Requirements:

BlackBerry 10 Native SDK Beta 3

Running the example:

1. Clone the Sample repository sample application.
2. Launch BlackBerry 10 Native SDK Beta 3, and from the File menu, select Import.
3. Expand General, and select Existing Projects into Workspace. Click Next.
4. Browse to the location of your sample directory, and then click OK.
5. The sample project should display in the Projects section. Click Finish to import the project into your workspace.
6. In the Project Explorer pane, right-click the project (for example SensorDemo) and select Build Project.
7. In the Project Explorer pane, right-click the project (for example SensorDemo and select Run As > BlackBerry C/C++ Application.
8. The application will now install and launch on your device; if not, you might have to set up your environment.

Sample Code:

main.qml:
import bb.cascades 1.0
import QtMobility.sensors 1.2
TabbedPane {
    id: tabPane
    showTabsOnActionBar: true
    onCreationCompleted: {
        OrientationSupport.supportedDisplayOrientation = SupportedDisplayOrientation.All;
        tabPane.activeTab = compassTab;
    }
/* Block of statements for other tabs such as Motion Alarm, Compass, Flashlight, Motion Alarm and Collision Detector.*/
Tab {
        id: rotation3DTab
        title: qsTr("Rotation 3D")
        imageSource: "images/rotation3d.png"

        Page {
            ControlDelegate {
                source: "rotation3D.qml"
                delegateActive: (tabPane.activeTab == rotation3DTab)
            }
        }
    }
}


rotation3D.qml:
import bb.cascades 1.0
import bb.multimedia 1.0
import QtMobility.sensors 1.2

Container {
//! [0]
    attachedObjects: [
        RotationSensor {
            id: rotation

            // Create variables to hold rotation reading values
            property real x: 0
            property real y: 0
            property real z: 0

            // Turn on the sensor
            active: true

            /* Keep the sensor active when the app isn't visible or the screen is off (requires app permission in bar-descriptor) */
            alwaysOn: true

            /* If the device isn't moving (x&y&z==0), don't send updates, saves power*/
            skipDuplicates: true

            onReadingChanged: { // Called when a new rotation reading is available
                x = reading.x
                y = reading.y
                z = reading.z
            }
        }
    ]
//! [0]

    layout: DockLayout {}

    ImageView {
        horizontalAlignment: HorizontalAlignment.Center
        verticalAlignment: VerticalAlignment.Center

        imageSource: "images/device.png"
    }

    Container {
        layout: AbsoluteLayout {}

//! [1]
        Label {
            layoutProperties: AbsoluteLayoutProperties {
                positionX: 480
                positionY: 685
            }

            text: qsTr("%1\u00B0").arg(rotation.x.toPrecision(4))
            textStyle {
                base: SystemDefaults.TextStyles.BodyText
                color: Color.Yellow
                fontWeight: FontWeight.Bold
            }
        }
//! [1]

        Label {
            layoutProperties: AbsoluteLayoutProperties {
                positionX: 480
                positionY: 460
            }

            text: qsTr("%1\u00B0").arg(rotation.y.toPrecision(4))
            textStyle {
                base: SystemDefaults.TextStyles.BodyText
                color: Color.Yellow
                fontWeight: FontWeight.Bold
            }
        }

        Label {
            layoutProperties: AbsoluteLayoutProperties {
                positionX: 335
                positionY: 390
            }

            text: qsTr("%1\u00B0").arg(rotation.z.toPrecision(4))
            textStyle {
                base: SystemDefaults.TextStyles.BodyText
                color: Color.Yellow
                fontWeight: FontWeight.Bold
            }
        }
    }
}

By Tehdog (Own work) [CC0], via Wikimedia Commons (Mute_Icon.svg, Speaker Icon.svg)

Some of you may have noticed that the Beta 3 release of the BlackBerry® 10 Native SDK got a bit quieter in the console when creating Cascades™ applications. As of Qt 4.8.3, all output that used to code to the console (qDebug(), qWarning(), qCritical() etc) is now output to slog2. This not only affects the logging from C++ but also any console.log() JavaScript logging done from within QML as well as error messages at runtime. No console output can make troubleshooting even simple issues very frustrating. Luckily there are a few workarounds detailed in the “Known limitations” section of the release notes that can get you access to the logging information.

1) This workaround gets you the logging information back to the console, but should be removed prior to publishing your application to the BlackBerry App World™ storefront. Either of the following can be done:

a. Use the fprintf() function with stdout or stderr as the output stream to receive output directly to the console. This is easy to do to add in-line console output from C++, but will not restore logging to the console from QML.
ex fprintf(stdout, “I am a console message\n”);

b. Register your own message handler with the application to have all qDebug() (etc) and QML output handled however you wish (including using fprintf() as mentioned above). To do this, open your main.cpp file (the default main file for a Cascades application) and add a function similar to the following above the main method:

void myMessageOutput(QtMsgType type, const char* msg){
               fprintf(stdout, "%s\n", msg);
               fflush(stdout);
}

Then in the main method we need to register the above method as a message handler:

int main(int argc, char **argv)
{
    Application app(argc, argv);
    qInstallMsgHandler(myMessageOutput);
    ...
}

After this is done you will once again have console output!

2) To see debug information that is output from qDebug(), you can access the slogger2 logs as follows:

In the IDE, in the Target Navigator view, right-click the device target. Click Launch SSH Session.

In the terminal that appears, do one of the following:

• To view the current slogger2 logs, type slog2info.
• To view real-time output for the processes that are being debugged (for applications that are running in development mode), type slog2info -w.
• To view help information on slogger2, type slog2info -h.

You can also access the log files directly in the /tmp/slogger22 on the device and run these logs through slog2info at a later time.

This works well to retrieve all logs, but has a bit more overhead than option 1b) and also does not allow you to see the logs in the console.

Now you have a few options to get access to the application logs, which can be used in the interim until a solution comes in a future NDK release and the above workarounds are no longer needed.

The workarounds mentioned above are also covered in the following places:

• Cascades Beta 3 – Release Notes
• Upgrading to Beta 3 – QNX Momentics IDE changes
• Getting Started – Debugging and profiling

Guest post from Ash N. – Ed.

BlackBerry® is serious about developers, serious about applications, and serious about Qt. With this in mind, we are asking for all you Qt ambassadors and Qt superstars to try porting your Qt applications over to the BlackBerry® PlayBook™ tablet and upcoming BlackBerry® 10 smartphones.

With this in mind, we have a post on the Qt Project Website. What we need from you is:

• For you to be a member of the “Qt on BlackBerry and QNX” group (if you are not, then please register to become a member)
• Send a proposal of the application(s) you will / are considering porting or have ported
• Send us a link to where you will make your code available OR if you do not to make the code public, then please provide us evidence that you are developing using Qt

In return, you will be automatically entered into our weekly draw for a free BlackBerry PlayBook tablet. We even have Mondays reserved for Qt porting at the BlackBerry Tech Center in Slough, UK if you need some in-person help.

Sounds good? Log on to the Qt Project website for all the links and info!

KDAB, a company with tons of experience providing Qt consultation services and delivering Qt training, has created a brand new course for Cascades™ application development:  Programming with Qt and Cascades for BlackBerry® 10.

This is an intense five-day workshop in which Qt experts from KDAB will teach you how to develop apps using Cascades and Qt in QML and C++.  You can check out the layout of KDAB’s course by going here.

KDAB is offering this course in Berlin on October 8-12 and in the Bay Area on October 22-26.  Visit KDAB’s website to register for either session.  Better hurry, though, because seating is limited!

Since the first release of the Cascades™ Beta, we have received a lot of feedback, suggestions and questions from developers trying it out. Thank you for all of this — we are very grateful! It really helps us get perspective on what we are doing, how it is perceived, and where we still have work to do.

Some of the most common questions are about custom UI: How do I create a custom UI component? How do I extend the existing components? How do I implement my own paint() method?

Custom UI works very differently in Cascades compared to how it used to work in the old BlackBerry® Java® platform, and in this blog post I want to try to bring some clarity to that — how it works and why it works in the way it does.

I’ll start off by briefly comparing how Cascades renders its UI compared to traditional widget toolkits such as the BlackBerry Java UI. Understanding the differences explains why custom UI has to be approached differently in the two architectures.

Traditional UI rendering – Immediate mode rendering

In the BlackBerry Java platform and in many UI toolkits for desktop and mobile, UI is rendered using “widgets” drawn with “paint()” calls. The exact naming of the building blocks and functions differs between implementations, but the principle is the same and is often called immediate mode rendering. The application developer constructs a hierarchy of widgets, with each one representing a specific area on the screen. A more advanced widget can consist of a parent widget and a number of child widgets. For example, a list could consist of a widget drawing the background, widgets representing each item and a widget representing the scroll bar. Together they represent a List Widget. The position of each individual widget is decided by the system using a layout engine. The positions are based on where the application wants them to be, and often it is possible to add completely custom layout code as well. However, the actual content – what the widget is drawing on the screen – is completely up to the application to draw when the rendering engine asks it to.

The application uses low level drawing commands such as “DrawLine”, “DrawCircle”, “SetColor”, and so on to draw the widget on a pixel buffer. Finally, the system composites the whole screen by going through the set of widgets, making sure their position is updated (based on animations, scrolling, etc.) and asks the widgets to draw themselves on the piece of screen real estate which is theirs. The callback from the rendering thread, where the widget should issue their draw commands, is typically called the “paint()” method.

(As a side note, there are usually other steps in the rendering where the application gets callbacks, such as layout() to do custom layouts. The same reasoning can be applied for those cases as well.)

From a threading perspective it can be represented as the picture below.

Often the UI Framework contains a predefined set of UI widgets for the application to use. If the developer wanted to customize a widget, it could selectively overload the paint() method and replace it with custom drawing commands, or call the old paint() method but decorate it with new custom code.
Immediate mode rendering is easy to work with and works well in many cases, but it certainly has limitations and drawbacks:

• The application can block the rendering thread. Since the rendering thread is calling app code in the paint() method, slow code in one widget could easily slow down the whole UI.
• Overdraw. It’s fairly easy for the rendering engine to understand which widgets are totally obscured by others (although transparency makes it a little complicated), but for partly obscured or clipped widgets, usually the drawing code can only draw a complete widget, hence many pixels gets drawn and then overdrawn several times.
• Hard to optimize for GPUs. Modern GPUs have been designed mainly for gaming, where most of the geometry, textures, and so on is known beforehand. As a result, GPUs like to have their work nicely organized for them in terms of drawing states and textures. “First let’s draw everything of this kind then let’s draw everything of that kind” – that’s how your GPU likes to roll! Optimizing the drawing commands in an immediate mode rendering is inherently difficult because there is no single place where the complete rendering work is known. The rendering is spread out in autonomous widgets. The result is that the GPU needs to change state constantly and shuffle textures in and out of graphics memory.
• Overloading overload. Overloading paint() methods and UI behavioral methods works for simpler widgets, but when widgets get complex with lots of features and lots of dynamics, it gets really hairy. You more or less have to expose every single behavior as an overloadable function, and it has to work no matter what combinations of function overloads the developer chooses to implement. This puts great pressure on the internal design of the widgets and a wide API to test and maintain. It also makes it cumbersome to add new features and behaviors without messing up something else. In the end, for complex controls, you just can’t make any assumptions about anything, because anything may be overloaded with unknown application code.

Of course, there are ways of working around these problems, but immediate mode rendering has a hard time performing well on modern hardware, and more modern kinds of rendering engines are taking over using retained mode rendering.

Modern UI rendering – Retained mode rendering

Cascades uses a fundamentally different way of rendering known as retained mode rendering. Instead of letting the application be an active part of the rendering loop, the application only manages the ui tree. When the rendering engine needs to render, it takes the current state of the ui tree and renders it. To use a gaming analogy, in retained mode rendering the UI becomes a “scene” that’s being rendered by the rendering engine.

Since the application is not directly involved in the rendering, slow application code cannot block the rendering, which generally means better performance. There are ways to get a slow UI anyway, generally by making the scene big or complex. Also, if the application can’t feed the data of the scene fast enough – for example, not providing list items to a list – the UI can be perceived slow by the user, but the actual rendering is never delayed.

As an example, you can try to create a really slow ListItemManager in Cascades that sleeps for a second every time it provides an item. Even if the list populates slowly, you will be able to scroll the list smoothly.

Another great advantage with retained mode rendering is that the UI engine can get a holistic view of the whole UI and optimize textures, states, and so on for the GPU.

Needless to say, using function overloading for customization does not work very well with retained mode rendering since it would introduce callbacks to the application from the rendering thread. It could be used for overloading behaviors that are completely disconnected from the rendering of the control, but not a lot for UI features that are completely disconnected from the rendering.

A retained mode renderer has one inherent quirk that is good to know about: Since the application cannot block the rendering thread, the application can never know exactly where things are on the screen. You can listen to layout updates, but once you get the updates in your app, you cannot be 100% sure that the position is up to date. A new frame could have been rendered and moved your object. That may sound like a huge limitation, but in real life it’s usually not a problem. Also, writing code that depends on where things are on the screen is often a recipe for bugs, especially when moving between different form factors and orientations.

This explains why the paint() method is gone in Cascades. There is also another aspect to consider: UI consistency.

UI Consistency

There is also a design consistency aspect to customization. With BlackBerry® 10, the RIM® designers have spent a lot of time designing, prototyping and testing out the core UI controls. They look and feel as they do because of deeply thought-through considerations and design decisions. They should be considered a unit together rather than individual classes spread out in the class hierarchy.

Hence, we are sensitive to letting developers change them too much. It would break the unity and cause inconsistencies, and BlackBerry device users would have a hard time finding their way in applications. They might start to wonder why a radio button behaves in one way in one app but another way in another app.

We definitely could have chosen a different path and focused on making the controls generic and easy to customize, making it simple for each individual developer to make their own drop down, picker or progress bar. However, we really wanted a consistent look and feel of the core UI. Does that mean every app has to look the same? Of course not. Firstly, some controls are more prone to being customized such as buttons. We chose to make them more generic and support greater customization options or generally more usable for compositions. The ImageButton and Container represent such cases.

Secondly, the core UI is designed to cover the most common need for an app developer, but it can never cover all cases. For some applications, unique and innovative UI is a big part of the application, and this is something we embrace and encourage with Cascades. For those cases, we believe the right strategy is to build a new custom control based on some basic generic building blocks, rather than a “Frankentrol” — a mix between a core component and something completely custom. The Cascades development paradigm with declarative QML and JavaScript is actually a very good fit for this.

Custom UI in Cascades

So if the pattern for Custom UI in an immediate mode renderer is overloading functions and overriding paint(), what’s the pattern in Cascades? In general, in Cascades – and for controls in specific – we greatly prefer composition over inheritance. You build custom UI in Cascades by compositing “interactive UI subscenes”. You composite simpler controls into a more complex control and add dynamics by implementing event handlers, adding animations and data connections. QML and JavaScript make this very easy. You get a quick preview in Momentix, quickly deploy the QML file and try out the behavior. Of course you can use C++ as well, but the quick turnaround times of QML and JavaScript usually become the preferred way of working with custom UI.

The toolbox features you should be looking for are:

• Generic, basic controls such as ImageView, Label, Containers, ScrollView, ImageButton
• Animations and layouts
• Event and gesture handling

When you have reached the look and feel you want, you can package it up into something easily reusable in QML and C++ by exposing its features as QML properties and Q_INVOKABLEs.

So does that mean that you hardly can reuse anything in the existing controls?

No. In Cascades you reuse by using a control as part of your custom control composite; for example, by including a label or ImageButton as part of a more advanced custom list item. Usually you would use the more generic controls, but nothing is stopping you from including any control in your composite.

There are still some holes in Cascades where a generic control would make sense to avoid rewriting some boring code; for example, expanding the ImageButton with customizable text. With QML and JavaScript, rebuilding some of this functionality should be pretty fast. At the same time we are looking to add some more generic controls to save you from some not-so-exciting QML work.

We know there are some important layouts missing that would make some Custom UI easier to build — we are planning to add them soon.

Will I be able to implement any UI in Cascades?

Cascades has its limitations just like any other framework. We have been focusing on core UI for the first release of BlackBerry 10 because we believe that is what is most useful for most developers. We are aware of some limitations in certain areas of the framework that can make some custom UI tricky to implement. This is also why we created the “Stump the Developers” challenge. We want to know what is messy to do and we want to understand what kind of UI you are creating.

There is a classic rule of thumb for APIs: “If in doubt, leave it out.” Some APIs we have left out intentionally in the first release to make sure they are well thought-through before being published. That being said, Cascades in its first version is more than capable of handling most custom UI.

This is nice and all, but I really need a drawLine() to draw my graph.

There is nothing stopping a retained mode renderer from having lower level vector features such as drawLine. We don’t use vector graphics to draw our UI internally and we just didn’t have time to add a vector library in Cascades yet. For now you will have to use a ForeignWindowControl and draw into it using OpenGL (something along the lines of this tutorial) or perhaps an open source graph renderer. This would be useful for many developers, so it’s a great opportunity for a friendly developer to contribute this to one of our repositories on github

Okay I got it, you don’t want us to change your core controls. But I just want to change color to make them match the color scheme of my app. Why can’t I do that?

The next release of Cascades will support two color themes — light theme and dark theme. Adding free colorization of controls is trickier than you would think. A control in Cascades is not just a couple of different colored texts and boxes, but instead composites of several layers of visuals with subtle patterns, shading and transitions. Translating that into simple parameters where random colors can be assigned is not easy. A simple color based themeing system is perhaps not the way forward. Again, we are in doubt, so we have left it out — at least for now.

Summary

Due to the different rendering architecture and UX consistency reasons, custom UI works differently than how it used to work in BlackBerry Java. Instead of relying on overloading paint() and other drawing methods, you build custom UI by combining existing UI controls and defining their behavior using animations and custom event handling. Using QML and JavaScript, this can be done in a quick and agile fashion. Compositing basic controls into more complex ones are the way to build Custom UI in Cascades.

We are still looking for feedback in this area and have already seen some areas of improvement. We love to see great custom UI so this is an area where you can expect more features coming in the future.

In today’s post, I’ll talk about property aliases and why they’ll be your friend when creating custom components in QML. I’ll give you an introduction to the topic by creating a Header component, which consists of a Label and a Divider wrapped inside a Container.

I assume that you already know how to create custom components in QML. Basically you create a new file and name it to whatever the name of your component is, for example ‘Header.qml’. So say we have a file ‘Header.qml’ with the following content:

import bb.cascades 1.0

Container {

    Label {
        id: titleLabel
        text: "Sample Title"
        textStyle.base: SystemDefaults.TextStyles.TitleText
    }

    Divider {
    }
}

To create a Header instance from another QML file, we simply write the following lines:

...

Header {
}

...

Looks good, but I assume that we also want to set the title to something more appropriate for the context where the header is to be used. Because we don’t have direct access to the Label’s text property from outside the Header component (you can only access top level properties), we need to add a new property to the Container in the Header component:

import bb.cascades 1.0

Container {
    property string titleText: “Sample Title”

    Label {
        id: titleLabel
        text: titleText
        textStyle.base: SystemDefaults.TextStyles.TitleText
    }

    Divider {
    }
}

The Label’s text property binds to the newly added titleText property. Now we can specify a title by setting the titleText property:

Header {
    titleText: “My Header”
}

Looks nice and works great, but I’m still not satisfied. I had to introduce a new property just to be able to specify a title text. What I actually want is to expose the Label’s text property to users of the Header component. Fortunately there’s a solution for this, and the name is property alias:

import bb.cascades 1.0

Container {
    property alias titleText: titleLabel.text

    Label {
        id: titleLabel
        text: “Sample Title”
        textStyle.base: SystemDefaults.TextStyles.TitleText
    }

    Divider {
    }
}

Much better. We got rid of the titleText property by simply making it an alias to the titleLabel’s text property instead. Even the instance of the Label can be exposed as an alias, which gives you access to all of the Label’s properties, if that’s what you need:

import bb.cascades 1.0

Container {
    property alias titleLabel: titleLabel

    Label {
        id: titleLabel
        text: “Sample Title”
        textStyle.base: SystemDefaults.TextStyles.TitleText
    }

    Divider {
    }
}

Now that we have access to all of the Label’s properties, we can also change the text style:

Header {
    titleLabel {
        text: “My Title”
        textStyle.base: SystemDefaults.TextStyles.TitleText
    }
}

Handy, right?

After the phenomenal response to the first Cascades™ webcast, I am pleased to let you know that we will be continuing with a second supplementary session Tuesday June 26th: Astonishing UIs using the new BlackBerry® 10 framework continued.

This session will use the knowledge gained in the first session and build upon some of the key concepts that make up Cascades, digging deeper into their functionality. The key features being discussed will be: animations, lists and custom UI components. We will be focusing mostly on the QML aspect of development but will begin to introduce some C++ concepts that will be required to perform some more advanced tasks in Cascades.

Registration is now open — hope to have you there! Come armed with your questions and knowledge gained from the first session.

Get Registered Here:
http://www.blackberrydeveloperevents.com/events/webcast/registration/register.html?scoid=1047459465