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
New Contributor
romainlefebvre
Posts: 7
Registered: ‎12-08-2010
My Device: Not Specified

Advantages of QNX UI components over Spark components?

Hi,

 

I created a small application for Playbook and I wonder what is the advantage of using QNX components instead of Spark components? I read that some Spark componnents are not supported but for example, if I can use Label, TextInput and Button from Spark why would I use those from QNX?

I know that the look & feel will look native from Playbook but I can easily get to the same results using the skinning of Spark components...

 

What are the advantages of QNX components then?

 

Thanks,

Romain

Please use plain text.
Developer
JRab
Posts: 2,462
Registered: ‎11-04-2010
My Device: Bold 9700

Re: Advantages of QNX UI components over Spark components?

aside from the look and feel, the QNX components have been specifically optimized for the playbook both performance-wise and for the touch screen environment.

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
Please use plain text.
New Developer
dkerr
Posts: 38
Registered: ‎12-01-2010
My Device: Playbook

Re: Advantages of QNX UI components over Spark components?

Very good question.  I've been asking the same thing.  Seems to me there is a lot of re-work being done in this API that already existing in Flex/Burrito.  Not just components like buttons, but also things like view/screen navigation.  This all already exists and is very easy to use in Burrito.

 

To me, there is a huge benefit to do things like Christophe is doing here

http://coenraets.org/

 

I don't really want to re-create mxml components to force them to work with QNX.  Nor do I want to maintain two versions of an application.... one for Android and one for Playbook.  Yes, there will be hardware difference.  But, that should only matter when interacting with the hardware.

 

So, I'm moving in the direction Christophe is "selling" for Adobe... multi-screen/multi-device ... same code.

 

Don

 

 

 

 

Don Kerr
Manager, Space City Adobe User Group
Houston, Tx
www.spacecityaug.com
Please use plain text.
Contributor
ml4d
Posts: 10
Registered: ‎12-07-2010
My Device: Not Specified

Re: Advantages of QNX UI components over Spark components?

[ Edited ]

Even though you can achieve the look by skinning different components from other libraries, can you achieve the eaxct feel and functionality?

 

Although this sounds silly to us as developers (an input field is an input field) when you see a user touching and interacting with you app you'll instantly understand why consistency is key.

 

Say a user interacts with your re-skinned spark TextInput which looks just like the qnx TextInput but your component is lacking the exact features and behaviour of the qnx component. No matter how slight the difference the user often becomes frustrated that it's missing and most of the time assumes it's broken.

 

Also consider development speed. Whilst your skinning the spark input field I've already finished an entire registration form view using the prebuilt components that users are familiar with.

 

Rather than weighing up advantages, disadvantages, differences ask yourself what would be more appropriate to use in order to achieve exactly what I want from my application.

Please use plain text.
New Contributor
romainlefebvre
Posts: 7
Registered: ‎12-08-2010
My Device: Not Specified

Re: Advantages of QNX UI components over Spark components?

> Even though you can achieve the look by skinning different components from other libraries, can you achieve the eaxct feel and functionality?

 

In the cases of Buttons, TextInput and Label, the behaviours are so basic that for sure I can skin Spark components to give them the same look & feel and behaviours (remove 'Over' state)

 

About speed development, I can argue that once these components are skinned I can reuse them in every Playbook application. Moreover QNX components are not usable directly in MXML (except if you use the Container component that Renaun created) and doing AS3 code to generate UI is not the most efficient way to do a Flex application (in my opinion)

Please use plain text.
New Developer
dkerr
Posts: 38
Registered: ‎12-01-2010
My Device: Playbook

Re: Advantages of QNX UI components over Spark components?

Well said.

 

I am amazed, frankly, how much AS3 code is being used to generate UI, especially basic stuff like screen/view navigation.

 

But, we all come from different backgrounds.  I've tasted how easy it is to build Flex Mobile using spark ... so it is hard for me not to see all of this as a step backward.

 

I have to think beyond just the Playbook, so I look at code efficiency across all devices.

 

Don

Don Kerr
Manager, Space City Adobe User Group
Houston, Tx
www.spacecityaug.com
Please use plain text.
Contributor
ml4d
Posts: 10
Registered: ‎12-07-2010
My Device: Not Specified

Re: Advantages of QNX UI components over Spark components?

Sorry I wasn't saying it was a bad Idea merely playing devils advocate.

 

If flex/spark is the route for you then I would suggest you stick with the default flex styling for the components or a completely unique style rather than borrowing aesthetically from the device.

 

When we built our Android app I recreated many of the android components and it took rigours testing and user feedback too get the "feel" even close to right. You'd be surprised at how picky users are, I certainly was. (To the literal point of inconsistencies in gradient ratios)

 


 

I am amazed, frankly, how much AS3 code is being used to generate UI, especially basic stuff like screen/view navigation.

 

But, we all come from different backgrounds.  I've tasted how easy it is to build Flex Mobile using spark ... so it is hard for me not to see all of this as a step backward.

 

I have to think beyond just the Playbook, so I look at code efficiency across all devices.

 



 

We've invested in the whole multiple devices same code base as well, it would be interesting to hear how your approaching the challenge.

 

At the moment we are sharing models, controllers, "managers" etc but having unique views and "navigators" per app the only consistency between views is they all dispatch the same events. This has worked well for us so far the only major problem has been the difference in device soft keys which completely change how an app is navigated. (Frustration!)

 

Please use plain text.