Five More Tips for a Speedier App Launch [CFA]

Native SDK Development

Speed up app launch

Welcome to part two of our Cascades Field Agency article on speeding up the launch time of your application. Check out our first five performance tips, and have a look at five more easy ways you can shave time off your app launch:

1. Pay attention to how images are loaded. There are several different options when loading images:

  • Synchronous loading
    Synchronous loading should be used when you need the image to be fully loaded before it shows up in the UI. This includes background images and images used in custom controls. Note that this will lock the server thread temporarily, so it’s especially important in list items to avoid this as much as possible.
ImageView {
    imageSource: "asset:///a.png"  
}
  • Nine-slicing
    All nine-sliced images are synchronously loaded. You can use nine-slicing when you want to stretch an image. Read more about it here. You can also see an example of image nine-slicing in our Cascades Cookbook sample app.
ImageView {
    imageSource: "asset:///a"  
}
  • Load asynchronously
    Images should be loaded asynchronously as much as possible, especially for dynamic content like a profile picture in a list item. Simply specify the relative path from the asset directory. Here, the image is placed directly in the asset folder in Momentics:
ImageView {
    imageSource: "a.png"  
}
  • Load using absolute path
    While not as common, it is also possible to load an image using an absolute path. This is used to get the path to a shared directory, like the image or data folder. Note that this loads the image asynchronously.
ImageView {
    imageSource: "file:///valid/path/from/the/root/a.png"  
}

2. If you have a container that swaps between images, defining them as ImagePaintDefinitions and conditionally setting the container background will prevent you from having to load every image to start.

3. Understand how the visible property works. If you have several components in your QML that are marked with visibility set to “false,” they will still be loaded and consume startup time. Our general recommendation is to hide controls by the visible property only if they are going to be shown during the current run of the application, card or sheet. The visible property should mostly be considered when the controls should be more or less temporarily hidden. When you know that the control will most likely not be shown, it is better to defer the loading of the control rather than setting its visibility to “false.” Some examples where the visible property is good to use could be when you have two or more images of a custom toggle button, or when a control should be shown only if a checkbox is checked.

To enable code re-use, some developers use the same QML for multiple cards or sheets and customize the sheet or card by setting the visible property on controls. In this case, it is better to use the ComponentDefinition or ControlDelegate to dynamically create the controls that are not always present in the sheet or card.

The advantage with the ControlDelegate is that you can toggle its “active” property, rather than the visible property, to determine if the control should be there or not. What you need to remember, however, is that the ControlDelegate is a control in itself. So even if you have “active” set to “false,” there will still be one control that gets created. Therefore, when you use the ControlDelegate it is better to group up as many controls as possible in one ControlDelegate. When it is not possible to group controls, it might be better to use the ComponentDefinition.

The final thing to consider is when you feel that you cannot remove the controls with visible set to “false” from the QML, since they in most or all cases will be shown later. In those cases, you can still consider deferring the loading of those controls until the rest of the QML have been created.

4. Asynchronously load your data. Never block the UI because a data source is slow. It may not be ideal to wait on content once a screen becomes visible; however, launching an app and watching it sit there unresponsive is even worse. Check out the Weather Guesser sample app to learn more about asynchronously loading data.

5. The less QML required for scene creation, the better. It can be helpful to split code into several files for maintainability; however each file that needs to be loaded and parsed adds time before launch. Consider defining a component inline if it is only used once, or using a component definition for items not required on initial view.

Keep these tips in mind when designing and building your next app, and let us know if these tips help you reduce your launch times.

About Erin Rahnenfuehrer

I'm living the dream, working for the Developer Relations team at BlackBerry speciailizing in Cascades and C++ development. I focus mostly on social and lifestyle apps.

Join the conversation

Show comments Hide comments
+ -
blog comments powered by Disqus