Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Adobe AIR Development

Reply
Developer
Posts: 499
Registered: ‎06-24-2008
My Device: Not Specified

Burrito components versus qnx.ui

Apologies in advance if I'm off base. I'm a Flash newbie.

 

I read somewhere that the qnx.ui components were necessary with Flash Builder 4.0 because the original Adobe ui components were not optimised for "touch".

 

Given that the Flex Hero release includes touch optimised skins; what is the current "best practise".

 

Should I be using the qnx.ui components or given Burrito was promoted on the BlackBerry web site, is it better to stick with the new spark components?

Developer
Posts: 2,462
Registered: ‎11-04-2010
My Device: Bold 9700

Re: Burrito components versus qnx.ui

[ Edited ]

hey br14,

 

the main differences between Flex (spark components) and pure AS3 (qnx components) aside from the sturctural differences for me is the size and load up time. I've noticed that Flex apps are usually much bigger in size and also their load up time are a lot longer. not by minutes or anyhting, but just a few seconds.

 

AS3 in my opinion is lighter from what i've experienced. that being said how about some positives for Flex right? Flex has its share of advantages. One main advantage is its structure. It looks very similar to HTML and XML and is easy to adapt to if you know any of the former well. Also it allows you to use the GUI builder in burrito which makes it easy to visualize and position all of your components using your mouse.

 

For me, i choose purely AS3 because i like to customize the code and make it my own. I dont like it too much when the system does the work and i just do a little. im a control freak and i like knowing why things happens and how they happen. and the only way for that to happen for me is using purely AS3. the downside of course is that i have to visulize everything in my head but i've gotten used to it.

 

hope that can shed some light. good luck on your choice and development!

J. Rab (Blog) (Twitter)
--
1. If you liked my post or found it useful please click on the thumbs up and provide a Like!
2. If my post solved your problem please click on the Accept as Solution button. Much appreciated!

Approved Apps: OnTrack | ssShots | Hangman
Developer
Posts: 499
Registered: ‎06-24-2008
My Device: Not Specified

Re: Burrito components versus qnx.ui

Thanks for the input JRab. Very useful.

 

I guess I'm mostly concerned with compatibility with other platforms and with potential future advances in Adobes "standard" components.

 

I do like the enforced structure with Flex, but I've more or less decided to use the  qnx components. Sounds like there is no official line on this so I'll assume the qnx ui components are future proof.

Developer
Posts: 111
Registered: ‎08-31-2008
My Device: Z10
My Carrier: Verizon

Re: Burrito components versus qnx.ui

As far as compatibility with other platforms, I don't think you will realize that with the qnx components.  They are PlayBook specific as far as I know.  My initial prototype of my app was in Flex, then I ported it over to the qnx components.  Definite difference is load up time, but it was a bit easier to make a nice looking application in Flex.

 

One good thing about choosing to go the qnx route is that there's plenty of very handy advice here in this forum.  If you are having an issue, there's a very good chance it has already been a path taken by others before.  J Rab in particular is an excellent source for troubleshooting advice.

-------------------------------------------------------------------
Creator of the Idea Catch PlayBook application

My favorite Apple product is apple sauce.
Developer
Posts: 2,462
Registered: ‎11-04-2010
My Device: Bold 9700

Re: Burrito components versus qnx.ui

[ Edited ]

one word of warning though with the QNX. some of its components, mainly the ones that rely on the PPS channel (TextInput, Dialogs, SwipeDown, etc), will not be portable to other systems. so when you are porting, make sure you are able to replace them. Also keep in mind that the QNX library is currently in Beta. so there is a more than likely chance that changes will be made to the overall API. One of the most recent changes that affect a lot of people (including myself) was the TextInput class becoming binded to the PPS channel. Also the padding on some objects have since changed. so wat that means is  every SDK that does come out before the 1.0 final of the SDK, will likely break a few things. The bright side is, we just these forums to walk everyone though and find work arounds to put things back to the way they were.

 

i cant speak for adobe's reliability when it comes to its Flex Components. Also remember that its still in "preview" so its also subject to change in some aspects. The bright side though is that I think Flex is open sourced so you can see the code behind it. QNX is very much closed and they dont allow us to peek inside to see what has changed. We usually have to react vs be proactive with that entire Library.

 

That being said I (being the biased person that i am hah) think you made the right choice. it'll give u a huge boost in the experience and give you a better understanding of the code. again thats only my opinion so im sure Flex coders can also say what they do is also a huge learning opportunity. and i would not doubt that it is what they say it is.

 

so no matter what you make, assume that it will break at some point and you will have to fix the problem. it'll keep you on your toes!

 

Edit: Thanks for the compliment davies Smiley Happy im not alone though, this forum is full of great people (including urself) who are willing to help. one question that someone creates a thread with will result in almost ten replies at the same time somtimes. which is always great. keep up the great work everyone - all of it is being noticed!

J. Rab (Blog) (Twitter)
--
1. If you liked my post or found it useful please click on the thumbs up and provide a Like!
2. If my post solved your problem please click on the Accept as Solution button. Much appreciated!

Approved Apps: OnTrack | ssShots | Hangman
Highlighted
Developer
Posts: 499
Registered: ‎06-24-2008
My Device: Not Specified

Re: Burrito components versus qnx.ui

[ Edited ]

Just a follow up on this issue.

 

Only my personal opinion but after a few days of research, it seems to me that Hero is the way to go for the future as far as UI goes. I imagine there'll always be qnx components around that are specific to the Playbook (although perhaps Adobe will incorporate more generic system utils) but the spark UI is very different and clearly the direction Adobe is moving.

 

Because Adobe has built support into Flash Builder Burrito for Playbook, it seems unlikely that further development effort will be expended on the qnx ui - unless by RIM of course. Given that enterprise in particular will want to use the Adobe tools I can't see how the qnx ui components have much of a future.

 

Having said that, the spark UI components in Burrito are not optimised for the Playbook form factor, and are sadly lacking in features. Only a handful have been engineered to support touch for example.

 

Of course if you've already got huge investment in qnx.ui, naturally it would be worth sticking with qnx.ui. But for anyone like myself engaging in Flash and the Playbook for the first time right now, I think it's just too much of a risk to develop with qnx until either a final release of the Playbook SDK or a final release of Burrito provides more concrete direction.

 

It's unfortunate that between them RIM and Adobe have messed this up so badly. I spent some time looking at whether the qnx components could co-exist with spark but that looks to be unlikely.

 

I guess I'll head back over to the Java forums until the dust settles.