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!

Forget everything you know about working with maps and BlackBerry WebWorks. Mapping just got real, real easy!

We heard you ask for an easy way to integrate mapping services with your BlackBerry WebWorks applications, and today I’m happy to announce that on BlackBerry 10, the process has become much simpler.

We’ve put together a straight-forward sample application that will show you how to integrate with a few of the services out there:  Google Maps, Bing, Leaflet, and OpenLayers.

If you’ve been following the progression of the BlackBerry WebWorks framework, you’ve probably noticed an awesome amount of transparency. Open web standards are lovingly embraced and adopted here at RIM. Even the framework itself is staged publicly on GitHub.  Continuing this theme of openness and following web standards, the maps samples we’ve released are not platform specific.  Whether you’re writing an exclusive BlackBerry app, or planning on targeting multiple platforms using Cordova (previously known as PhoneGap), these samples are most definitely for you!

For each service, you’ll be able to learn how to:

-          Setup a mapping service to use to in your app

-          Find the users location with HTML5 Geolocation

-          Perform a search for nearby points of interest

-          Display push-pins on the map, showing the search results.

The goal of this sample is to show you how you can quickly integrate maps into your app and have it perform great in WebWorks for BlackBerry 10.

When it comes down to picking which service is right for your app, it’s completely up to you.  One of my teammates, Jim Ing, wrote a really in-depth article on maps, comparing services and much more.  I strongly recommend checking it out “Lightweight Maps For Mobile”.

Check out the sample, in action!

Download the source code.

Ready to add some maps to your app? Download the source code from our GitHub repository!

Calling all Native developers!

Have you been yearning to contribute to the BlackBerry 10 cause but weren’t sure how?  Why not take this WebWorks sample, and build a Native version?!  If you’re interested, get in touch with Shadid Haque (@ShadidHaque) on Twitter.

If you’ve got a success story, have a question, or just want to chat about apps, hit me up on Twitter @chadtatro!

Image By Civilspanaren (Own work) [Public domain], via Wikimedia Commons

What It Does

BlackBerry Application Resource Monitor monitors applications when they are in the background (with the screen on or off) and when in the foreground when the screen is off. When the app is in one of these two states, it looks for excessive background wakeups (any sort of timers firing including rapid/constant repaints) and high CPU utilization.

When efficient applications are in these two states, they should not be consuming an excessive amount of CPU or exhibiting any sort of timer abuse. When the problematic application is identified, an alert may be presented to the user. If “Automatically shutdown background draining applications” is enabled, the user is alerted and the application is shut down. If it is disabled, the user is alerted and they have the ability to close the app from within the notification. The ability to automatically shut down background-draining applications can be enabled and disabled within the Application Resource Monitor options access on a BlackBerry® smartphone by going to Options -> Device > Application Resource Monitor. The default setting is for it to be enabled.

Applications can also be whitelisted so that they are not shut down by Application Resource Monitor. To whitelist an application, users need to first receive an alert. If the ability to automatically shut down background-draining applications is disabled, they are simply alerted about the problematic application. They can acknowledge the alert (OK), whitelist the app (Ignore Future Alerts) or choose to manually shutdown the app (Kill it Themselves). If it is enabled, the application will be shut down and an alert presented to the user. The user can then open the alert to acknowledge and dismiss it, or whitelist the application to ignore this application going forward. To remove items from the whitelist, users can go to Options > Device > Application Resource Monitor.

How to Avoid Being Shut Down

You can prevent your application from being shut down by Application Resource Monitor by detecting and adapting to the state changes described above. If we use the example of a game, you can put your game into a paused state where it is not making any game play calculations for things like physics or artificial intelligence, and so it is not refreshing the screen when the game has moved to the background or when the screen has turned off.

Detect Moving to the Background

There are two ways to detect that your application is no longer in the foreground. Application.deactivate() is called when an application is moved to the background, and Application.activate() is called when the application moves to the foreground. Override both of these methods to detect the backgrounding and foregrounding events.

An application screen can override the Screen.onObscured() method to be notified when another screen appears on top of it, which may or may not be another application. This method is fired when the menu appears or if a dialog from your application is shown, which could be another point where you would want to pause your game. Screen.onExposed() is the matching method that is fired when screens on top of your application have been removed and your screen moves to the top-most position on the screen stack.

Detect the Screen Turning Off and On

There are also two ways to detect the BlackBerry device screen turning on or off. You can use the SystemListener2.backlightStateChange(boolean on) interface to be notified when the screen turns on or off. The Backlight.enabled() method can be used to poll for the current state of the screen.

Handling the Shutdown Request Gracefully

Overriding Application.requestClose() can allow your application to respond gracefully to a termination request. Returning true from this method will allow your application 10 seconds to process any required cleanup before it is shut down. Returning false will shut down the application immediately. This can also be used for diagnostic purposes, as it can log information about the state of the application for debugging purposes. Be careful to avoid logging excessive amounts of data in the production version of your application. requestClose is also fired for visible applications (those for which acceptsForeground() returns true) if they have not been used for one hour, regardless of whether or not they are using background timers or significant CPU. (However, applications are not terminated after being idle for one hour. This is simply a suggestion that they could close to conserve resources.)

Application termination from Application Resource Monitor is not limited to visible applications – in fact, it’s arguably more important that non-visible processes are terminated since users are not otherwise able to easily shut them down. You should consider the possibility that their processes may be shut down and ensure that this does not hinder future use of your app.

Verifying Efficiency using the BlackBerry Java Plug-in for Eclipse

Efficient applications that already take into account the states described above should not be impacted. However, it makes sense to do some performance testing of your application to verify that it does act like a good citizen. A new view has been added to version 1.5.2 of the BlackBerry Java® Plug-in for Eclipse™ that allows you to do just that. The new Process View allows you to monitor CPU utilization of your application, where you can monitor the statistics presented to observe the impact of your application while it is in the background and/or when the screen has turned off.

BlackBerry Java Plug-in for Eclipse Profiler View

How to Determine if an Application was Shut Down by Application Resource Monitor

Application Resource Monitor will create an entry in the event log every time it shuts down an application. You can view the event log on a BlackBerry smartphone from the home screen by holding down the Alt key and pressing LGLG. You can also extract it using the javaloader command line tool (javaloader –u eventlog > mylog.txt).
Application Resource Monitor will log detailed information about why the application was shut down and how it handled the shutdown request. Stack traces may be useful if the alert stems from processing too many timer events in the event handling thread (usually from the use of invokeLater with timed runnables and very short timeouts), but it’s more likely that the stack trace won’t capture the specific event processing at the time of the trace dump.

Setting the minimum event log level to “information” will provide more information about background activity that doesn’t meet the criteria to trigger notification or automatic shutdown – i.e. background timer activity below the minimum wakeup rate threshold. Here is a sample event log entry that shows an application being shut down by Application Resource Monitor, with comments added describing the entries shown bolded in red:

W 22:01:02 – net.rim.appmon – Terminating still-running process TestWebworks(596) Logged because the app did not support requestClose()

W 22:01:01 – net.rim.appmon – Shutting down process automatically Logged because autokill is enabled.

W 22:01:01 – net.rim.appmon – Thread CPU r=0, t=47085 Recent (last 2 seconds) and cumulative CPU time (ms) for the thread with the preceding stack trace

a 22:01:01 – Java Exception – ForcedStackTraceException Start of stack trace of a single thread in the process.

| VM:AppM TestWebworks(596) 322 2 0×15580800
| net_rim_cldc(4FA2F16A)
| Object
| wait
| 0xA7AF
| net_rim_cldc-36(4FA2F16A)
| MessageQueue
| dequeue
| 0x72F5
| net_rim_cldc-11(4FA2F16A)
| ApplicationProcess
| getMessage
| 0x4A6E
| net_rim_cldc-10(4FA2F16A)
| Application
| processNextMessage
| 0×2249
| net_rim_cldc-10(4FA2F16A)
| Application
| enterEventDispatcher
| 0×2196
| TestWebworks-2(4F9144A8)
| Widget
| main
| 0x741C

W 22:01:01 – net.rim.appmon – Thread CPU r=0, t=9531

a 22:01:01 – Java Exception – ForcedStackTraceException

| VM:AppM TestWebworks(596) 173 3
| TestWebworks-3(4F9144A8)
| AnimatedGIFField$AnimatorThread
| run
| 0×187

W 22:01:00 – net.rim.appmon – Thread CPU r=0, t=125632

a 22:01:00 – Java Exception – ForcedStackTraceException

| VM:AppM TestWebworks(596) 163 3
| TestWebworks-2(4F9144A8)
| MemoryMaid
| run
| 0×3081

W 22:01:00 – net.rim.appmon – Thread CPU r=0, t=242

a 22:01:00 – Java Exception – ForcedStackTraceException

| VM:AppM TestWebworks(596) 352 2 0x14FE2C00
| net_rim_cldc(4FA2F16A)
| Object
| wait
| 0xA7AF
| TestWebworks-2(4F9144A8)
| EventQueue
| dequeueWaitIfEmpty
| 0x25FB
| TestWebworks-2(4F9144A8)
| SystemEventManager
| getNextWaitingEvent
| 0x600D
| TestWebworks-2(4F9144A8)
| SystemEventExtension
| invoke
| 0x5E09
| TestWebworks-3(4F9144A8)
| WidgetRequestController
| handleResourceRequest
| 0x4DA0
| net_rim_bb_browser_field2_api(4FA2F821)
| RenderingApplicationImpl
| getInputConnectionDirect
| 0×3971
| net_rim_bb_browser_field2_api(4FA2F821)
| RenderingApplicationImpl$2
| run
| 0x3D0D
| net_rim_bb_apps_framework-4(4FA2F73D)
| Job
| go
| 0×4874
| net_rim_bb_apps_framework-4(4FA2F73D)
| Worker
| joinableRun
| 0xA682
| net_rim_cldc-34(4FA2F16A)
| InterruptibleThread
| run
| 0x1EEE

W 22:01:00 – net.rim.appmon – Thread CPU r=0, t=0

a 22:01:00 – Java Exception – ForcedStackTraceException

| VM:AppM TestWebworks(596) 330 2 0x258AC400
| net_rim_cldc(4FA2F16A)
| Object
| wait
| 0xA7AF
| TestWebworks-2(4F9144A8)
| PushListener2$MessageProcessor
| run
| 0x44EA

W 22:01:00 – net.rim.appmon – Process TestWebworks(596), system = false, visible = true, localized app name = BARM Test App, group name = RIM, friendly group name = BARM Test App Details about the process.

W 22:01:00 – net.rim.appmon – Process TestWebworks(596) background wakeup count 3661 over 420023ms First log for the alert, shows the wakeup rate.

Triggering Application Resource Monitor Shut Down for Application Testing

The BlackBerry Profiler View in the BlackBerry Java Plug-in for Eclipse should always be the first tool you use to test and enhance the efficiency of your application. However, you may want to test how your application behaves in the event that it gets shut down by Application Resource Monitor. To do so, you can lower the thresholds that it uses to determine if an application should be shut down. This can also be used in conjunction with the BlackBerry Profiler View to ensure that your application stays well under the default threshold. To modify this threshold, go to Options -> Application Resource Monitor on your BlackBerry smartphone, then type FLTR to display the additional options. You should see a screen that has these additional options:

Here are some tips on how to configure these settings while testing your application.

• Reduce the wakeup threshold to a low level, perhaps the minimum. It is intentionally set at a very conservative (high) level by default.
• Disable automatic shut down – this allows you to immediately profile the application when Application Resource Monitor triggers an alert and before changing the state, to see what’s going on in your application.
• Disable transient filtering – this will speed up detection of sustained problems.
• If you are performing very frequent restarts of your BlackBerry smartphone while testing, reduce the startup delay to 0.

Shutting Down

The BlackBerry Application Resource Monitor is designed to help consumers get the most battery life out of their BlackBerry smartphone by closing applications that are abusing resources leading to noticeable battery drain. By following the steps outlined in this article, you can ensure that your application behaves like a good citizen on the device and is never noticed by Application Resource Monitor.

Hopefully you’re already aware that one of the exciting new features of the BlackBerry® 7 OS and devices (such as the BlackBerry® Bold™ 9900 smartphone and BlackBerry® Curve™ 9360 smartphone) is Near Field Communications, or “NFC” for short. In addition to some of the consumer and business stories we’ve talked about on the NFC front in recent weeks, such as announcing BlackBerry® Tag and the MasterCard® certification of BlackBerry Bold 9900 and BlackBerry Curve 9360, NFC can be used by you, our community of developers, in a variety of ways. This presents a great opportunity to get creative and differentiate your applications and your company.

For developers, NFC is a truly interesting area of technology to learn about, though for many it may currently be quite unfamiliar territory. With that in mind, we’re aiming to publish a series of articles under the Resources tab in the BlackBerry® Developer Zone, which will help inform developers about the possibilities of using NFC, the underlying technical details of the technology, and how to use the BlackBerry 7 APIs for NFC in your own applications.

In fact, myself and John, my colleague in BlackBerry Developer Relations, have already published the first two articles in the series. The first is called “NFC Primer for Developers” and if you’re completely new to the topic, it’s definitely the place to start. More recently, we also published an article entitled “Reading and Writing NFC Tags”, which explains how to work with smart posters and other implementations of NFC tags.

We hope you find these articles interesting and useful, and we look forward to being impressed by your use of NFC in BlackBerry® applications! Watch the Inside BlackBerry Developer’s Blog for further articles in the future.