11-21-2010 03:12 PM
I am just wondering about the implications of keeping my app solely AS3 with none of the QNX componenets added. I want to be able to bring my app to different patforms with as little changes required as possible, so this is why I don't want to add any Playbook specific elements. Is this the right choice or is there a very good reason not to ignore QNX?
11-21-2010 04:32 PM
You can but your application, and it would take a bit of thought to ensure you optimize for the right platform, but it might not be able to be very PlayBook specific (i.e. your menus wouldn't look like BlackBerry menus, you wouldn't get access to BlackBerry specific functions (like the PIN, BBM, etc.). This isn't necessarily a bad thing if you want to have one look and feel for your applications across multiple platforms but it might not look very BlackBerryish if you know what I mean... similarily on other platforms it might not very Androidish...
The advantage to the QNX libraries is that with not much more than changing a name on the import statement (from mx. to qnx.) you can get all the benefit of being on the blackberry platform and not have to worry about the controls not being optimized for the PlayBook. You could easily code around this with a compile time macro for each platform to optimize them. I haven't done this yet on the Adobe platform but used to do this all the time to provide flags for Windows/Unix and OS/2 environments. I'm sure some bright young coder knows how to do this right off the top of his/her head.
11-21-2010 04:34 PM
There are some elements in the QNX SDK that are designed for finger manipulation. Native MX/Spark components have scroll bars and other small items that were designed for the mouse. If you dont use the BB SDK, you will probably have to create your own widgets that work with the finger. If you dont, and you use the mouse driven widgets, your end customer will probably get frustrated. If you dont need or have any "small" controls, then you might be good.
Also, the BB controls are very light weight (space and functionality). This will make for a faster download and probably take less memory than the older MX framework.
If you have portability concerns, I would create a library that is shared that contains your business logic and storage logic and then just have the UI specific to the platform you are developing on.
11-21-2010 05:35 PM
Thanks for the quick helpful responses
I should have been more specific. The app that I'm currently working on is a game. Based on your responses I think I'm going to be fine without QNX, however I will definitely look into the suggestions regarding alternative methods of ensuring portability while using QNX.
11-25-2010 07:30 AM
Usually, in games we do not need many components (of course it depends on game, but they are rather for business apps I guess - from my experience with Flex) so you may write your own extending for example Sprite class.
See this for example: http://www.adobe.com/devnet/air/flex/articles/writ
11-25-2010 12:10 PM - edited 11-25-2010 12:12 PM
Yes you certainly can, and I would actually recommend it if you have plans for multi-device deployment.
If you want to ensure maximum portability, do everything in pure AS3, and you will have no issues porting to iOS, Android, Blackberry or whatever else is around the corner.
There might be a few cases where it's unavoidable, or the QNX classes actually do things that are not possible yet in AIR 2.5, QNXStageVideo for example will probably be available before the real StageVideo class. In that case you probably want to use QNX as a stopgap, but switch over to the AIR 2.5 class when they come available.