09-11-2012 03:12 PM
09-11-2012 03:34 PM
It's very simple to setup NME for development. Here are a couple videos I did yesterday:
Most of the projects built with NME have been games, so a lot of game-related APIs (accelerometer, joystick support, etc) have been implemented, but some of the things that you may want for an application (like geolocation) are not supported yet, though this would be very simple to add.
NME is using the SDL port for BlackBerry right now, which is not going to run inside of Cascades. However, it could be possible to create a new stage that works as a "foreign window" for use in Qt/Cascades.
Another idea would be to explore Cascades bindings for Haxe. That would mean you code is written in Haxe and compiled to C++ for use with Cascades. It sort of drops the NME/Flash paradigm, but this could be done -- someone has used Haxe to work with wxWidgets, and it would be a similar idea.
NME is compatible with a SWF library that can help you use Flash assets, but it won't process Actionscript. Actionscript only works when you are targeting Flash. I have been questioning what method I would want for an application UI -- create in Flash, create with Cascades, find another option? There are pros and cons to each path
09-12-2012 04:25 AM
Thanks, thats very interesting.
So, if exisiting AS3 libs only work when i taget Flash and not C++ - are there any basic UI-controls like lists written in Haxe available? I mean, i can create Buttons, Sliders and even the BB10 Actionbar by my own, but a skinnable list, optimized for touch-events is a lot of work...
RIM should hire someone like you to port the BB10 controls to Haxe as soon as possible.
09-12-2012 04:37 AM
This is interesting...
So would you rather have standard native Cascades controls, accessed from a language like Haxe, or would you rather have Haxed-based UI controls that follow the same function and design as other BlackBerry 10 applications?
In the first case, you would not have a Flash-like API -- it would be the API for Cascades, but in addition to using C/C++ to write the application, you would have the option of using Haxe, which would feel much more like Actionscript.
In the second option, it would be the same as Flash development (Sprite, SimpleButton, Graphics, Sound, URLLoader, etc) but we would have a set of controls for applications. It could take some work to bring polish so it provides a similar experience, but it may be closer to what you are used to and would be more compatible with cross-platform
09-12-2012 09:24 AM
09-12-2012 01:13 PM
I believe a great platform should have both a first-class web implementation and high-performance, low-level native access using C/C++.
The direction for BlackBerry 10 focuses on those pillars. I do not mind that RIM is using a C++ framework for applications. It should lead to the fastest possible performance and greatest flexibility for features that are possible.
Having a fast, low-level platform means that we have the opportunity to use things like NME on top. It is a win for low-level developers, and it provides a foundation for high-level developers. It took less than 48 hours to port NME for the BlackBerry PlayBook -- it holds the record (by far) for NME platforms, thanks to the low-level support, and the libraries (like SDL) that RIM has on GitHub.
I appreciate your feedback! The more that I think about it, the more I like this suggestion. It reminds me of the way that Qt supports platforms. At the end of the day, "native look and feel" is using the correct graphic and tweens. This can be hard to replicate, but once you have there is a tremendous level of flexibility. I love using NME for games, but I said before that I was struggling to find a solution that worked right for me for applications. This could be it
09-12-2012 01:35 PM - edited 09-12-2012 01:38 PM
I know you would get support from RIM's open source initiative to have an "official" implementation of Haxe/NME for BB10. It would be a big win for RIM for this:
1) Higher level API that is already used by the majority of PlayBook developers (AS3)
2) Low level performance
3) Choice to deploy AS3, WebWorks or C++
4) Maintain cross device support
5) Open Source
You might want to submit this for a topic for JAM America as a non-conference conference meetup.