Asset Selector: Designing for the Z and Q [Weekend Coder]

By Brian Scheirer on 4 May 2013 07:56 am EDT
1
loading...
0
loading...
66
loading...

As we can all plainly see, the BlackBerry Z10 and Q10 have different screen sizes and aspect ratios. This is obviously because the Q10 has the full QWERTY. More often than not this presents a challenge for app developers. Luckily when coding in Cascades it is easy to code for both aspect ratios using the asset selector.

Before jumping into the asset it should be noted that Cascades will try squishing, squeezing, reduce spacing between elements, and/or cutting off certain parts of the display to make everything fit. Sometimes it works fine, especially for long scrolling lists like Facebook or Twitter.  Either way it is best to use the asset selector to directly control display, plus it’s really easy to use.

The asset selector is an automatic feature that displays specific code for a specific device. So in the case of Q10 vs Z10 you would have sections of code (either full pages or just specific components) shown for the Z10 and other code shown for the Q10. Now this may be hard to conceptualize without a sample, so guess what… here comes a sample…

Say we have the following code and how it will display on the Z10:

However if we load it to the Q10 it will look like this:

This is not ideal, since some images/buttons are overlapping and everything looks squished together. Rather than creating a new project that will be the “Q10 app” here’s where we’ll use the asset selector.

First, let’s create a custom component with another QML file. Create a new file in your assets folder called “CustomStuff.qml” and take some code from main.qml to add it to CustomStuff.qml. And replace it CustomStuff {} in the main.qml file so we have the following:

New main.qml and CustomStuff.qml:

Now we can use the asset selector, to do so we need to create a folder inside of the asset folder called “720x720” and inside of that folder create a file called “CustomStuff.qml”. Our second CustomStuff.qml file will contain similar code as the other only this one will have different images/text/whatever we want that makes it look better on the Q10.

720x720/CustomStuff.qml:

When you launch this code on the Z10 it will pull the code from the assets/CustomStuff.qml and when you run it on the Q10 it will pull code from the assets/720x720/CustomStuff.qml as seen in the main picture of this posting.  This also works for full files. So you could have an assets/main.qml and an assets/720x720/main.qml and it will behave the exact same. The true beauty of this is there is no need to maintain two sets of logic (C++ or Javascript) in separate apps for the Z and Q. That’s it, nothing else, crazy easy huh!?!? So there should be no excuses that the Q10 doesn’t get the same love as the Z10 for apps.

Reader comments

Asset Selector: Designing for the Z and Q [Weekend Coder]

41 Comments

Well, you sure make it "look" easy... Either way, wish I knew how to code... My next project. (Someday...)

Nice work that type of article makes me want to develop some apps. Not any gps apps mind you cos that seems to be covered off in the store ...it'd hardly be a 'First' to develop anything like that.

Posted via CB10

You should mention that this works for images as well not just QML files! For example you can have:

assets/background.png and assets/720x720/background.png

The first will be used on a z10 and the second will be used on the q10. That way if only images need changed you don't have to touch your QML at all! Cascades will do the heavy lifting for you to select the correct image at run time :)

Posted via CB10

Good catch, and I believe it will work for datamodels (xml), sounds, and video too. Pretty much if you are running the app on the Q10 it will look for anything in the 720x720 folder first and if its not there it will then look in the main assets folder.

You could improve these by going into more detail about how the coding is actually done, you just skip over that.

Do you know how much of a waste of time that is? Especially when the syntax of QML is pretty easy to deduce. Technically, QML isn't even the coding part. If you want to know more about the UI elements in QML you should read the documentation.

Thanks for the feedback. Some posts I will go into details about the code and others (like this one) are a more of a high level post. The idea of the asset selector would get lost if I was explaining how I made Containers and Labels. Don't worry there will be some lower level ones where I'll explain each line of code.

The other question is, will you bloat up the size of your app because you are deploying a single BAR that will run on both screens and contains ALL assets... Or is it better to compile 2 separate apps, each with Assets for only 1 screen resolution... (at time of BAR signing) and upload to appworld 2 separate BAR packages (but under the same app) that you designate for targeting each device individually?

For the most part this will just add lines of text which don't take up much space. I would think it would be more annoying to have to have two apps because then you'd have to maintain two logic sets. Then say there is a bug in your logic then you'd have to make every fix twice. Same with adding features.

As a dev I can confirm that, it's much easier to lose some time making it adaptable on both devices, rather than losing double of this time every time you have to update your app.

The asset selector is really useful, I was able to port my app without changing a single line of code, just custom layouts.

Nice write up! It's good to see development related posts on CB, hopefully, with more of this people will be encouraged to try their hand at app development.

For my app VitalSigns, I took a different approach to incorporating the Q10 visual changes. The main app itself wasn't much of an issue, the Active Frame display was where all the changes needed to be. I ended up writing a Q_INVOKABLE C++ function that returned the width and height that the Active Frame should be which it itself determined by retrieving the display resolution. I could then use this function to bring the correct fixed size values into my apps QML. Worked like a dream in my case scenario, but there are other cases where the dual assets approach would be much better suited.

The fact that you don't need a 1280x768 folder for the Z10 makes me believe this is an afterthought.

Posted via CB10

I kind of thought the same thing. Either way I'm glad they made it really easy to use. And I look at it this way that once BB10 is on the PlayBook I assume we'll just make a folder called "1024x600" to support it too.

Z10 was the first BB10 phone so it gets the privilege of having the default asset folder :)

Posted via CB10

Might be a little confusing long-term, because won't this be the *only* x768 device? All future ones will be x720, right?

Actually that's not true. You can have a 768x1280 folder (note that the order matters, it uses the default orientation) and the Z10 will use whatever's in that folder. Then, you could have your Q10 stuff in a 720x720 folder if you wanted, and assets for future devices in a 720x1280 folder, or whatever.

The way it works is, it looks in the folder corresponding to the resolution of the device, and if it can't find one, it uses whatever's in the root (assets/) directory.

The problem with that is, the static asset selector was added in OS 10.1, so if you have no default assets the Z10 version might not work without that OS version.

Nice weekend coder articles Brian. I look forward to the articles every weekend now.

Posted via CB10 on my Z10 L.E.

Cool. I'm getting the itch to code some Cascades alps :)

I would also like to see a tutorial on how to code fast Android apps for BB10. E.g.: Some Android ports are Laggy, while others are super fast. I would like to know the tricks to code Android apps that run fast on the Z10 / Q10 and integrate with the hub, notifications etc...

Can an Android app detect if it's running on BB10 Android runtime?

Posted via CB10

What if we didn't have that folder? I'm about to submit an app, is it a better idea to have something in the main 'assets' folder that it cause by default?

I think so. Momentics should give a warning if there aren't isn't a default asset, although it might depend on your settings.

ALSO, could you cover how to save information?? As in, say you have custom options that you allow users to pick OR stuff like text user enters etc...