learn haXe: library management
During your development process you may come to a point were you need to use different libraries to achieve your goal, even if you decide to use third party libraries or some code you've written before. I like haxelib a lot, it remembers me to the ruby gems goodness, but it also has some disadvantages like Dominic already mentioned in his blog post.
Sometimes, for certain reason, you don't want to use haxelib to upload and download your code to having a kind of library management for your project. You may at least end to the point were you begin to copy and paste different parts of source code together to have it all in your project and it'll be a pain in the ass whenever you made changes to the original source code itself. Also your dependencies will increase very fast and your project becomes unmaintainable the more it grows.
I already did this mistake in my current hxTasks implementation. Of cause this isn't a huge project, but this little project has already a dependency to a Signal project I had written a few weeks ago. Because it just depends on one class, I'd decided to copy paste the original Signal.hx class into my hxTasks project, but a few days later I needed to make an improvement on the original Sig nal.hx class and so I started to copy and paste it again. Yes, I did it wrong. (and I didn't fixed it in my github repo right now)
A better way to decoupling the dependency is to work with relative path declarations in your project.hxml file. Instead of copy and paste the original source code into each project were I want to use this library I can now just set the classpath relative to my current project.
-js deploy/js/main.js // current project -cp src // reference to a library -cp ../hxSignal/src
To add version control to your libraries you could easily integrate an Ant Task or another automated process of your choice to each of your library projects to keep track of your changes.
Do you have another good approach to manage your libraries, versions and dependencies? Let me know!
learn haXe: function types & inline
Today I've written a small Tweening engine with haXe which uses some of Rob Penners easing equations. I just have tested the output for Flash, but JavaScript should run too. Note that there seems to be a know bug with the haxe.Timer class when using neko for the output, but it should be very simple to change the timer implementation to something else which fits better for the neko vm.
I've used TweenLite for several years and never found the need to implement a little tweening class for myself. Therefor I'm much more happier that i've done it today and also used two of haXe's features called function types and inlining. In ActionScript I just rarely used the Function class as a parameter for methods, rather for callbacks than for calculations. It felt not self descriptive enough which kind of function I should pass to get the code running from the viewpoint of other developers - mostly my colleagues.
function types
But haXe offers me a way to structure the code a little more with strong typed functions. Every single method has a type, based on their parameters and return type. Lets say you have a simple function like:
function handleTweenComplete() : Void { }
The type of this function is Void -> Void, because there's no parameter and the method itself returns Void. So you can assign this function to a variable:
var callback : Void -> Void;
Sounds very simple but how can this feature help you to structure your code and API? Let's take a look at Roberts easing equations. In his post he describes each method by the following four parameters: time, startValue, changeByValue & duration. So every different easing function uses this parameters to determine the current position/movement of your object. Instead of passing a magical, unpredictable Function as a parameter like you have to do in AS 3, you can describe your easing function by the following type:
var easing : Float -> Float -> Float -> Float -> Float
which means you're expecting a method with four parameters of type Float which returns a Float. Much more type strong and predictable for other developers who needs to use your API, isn't it?
inline
Just a few words about inlining. Working on a game or another application where high performance matters there are sometimes some parts of your code which are highly optimized for speed. This could end in a very high performant but not that good readable code. Inlining will help you to refactor your code pieces into several methods to make your code more readable without the lost of your performance optimizations. As I understand it right, the compiler than will replace your methods calls with your method body during compile time. Note that there are some restrictions when using the inline keyword on a method or variable.
hxTween
The result of my learning was a little tweening helper which I called hxTween. It uses both - function types in combination with Robert Penners easing equations and inlining to gain performance during execution. Feel free to fork or modify my code pieces and comment with improvements or faults I ran into.
learn haXe the fun way
Dominic "devboy.org" Graefen started blogging a series about his first impressions with the language haXe called "learn haXe the hard way". Yesterday I've decided for myself to dig into haXe for the next weeks and months to dive into every new feature the language offers me compared to those I already knew from ActionScript and Java.
I'm calling my series "learn haXe the fun way" based on Dominic's naming, because I want to learn the language in experimenting with different patterns, porting libraries or doing some HTML5 or WebGL stuff. First of all I've started porting the core functionality of one of my famous libraries - the spicelib task framework. During my work I'm using it in every project to have a clean and easy understandable application starter flow. With the use of this library you can delegate single responsibilities to single tasks, to perform synchronous or asynchronous work in a specific order. After one tasks has finished its job, the next one will be started. At this point the implementation just contains the most common parts of the original library - adding and starting tasks in a sequential chain. Maybe I'll add additional implementations too if necessary.
You can clone or fork the code from github.
AIR 3 Native Extensions
Flash Player 11 an AIR 3.0 will be released soon in October and one desired feature are Native Extensions. Currently there are some few information in the web which helps you to write your own extension with the current AIR 3.0 RC1 SDK like Lee Brimelows video tutorial or the Extending AIR article.
I've added my first four extensions to my github repository right now. In addition to the common AIR API you are now able to use the following sensors and services:
- Orientation / Compass information
- Ambient Light sensor information
- Proximity sensor information
- Vibration hardware
Have fun and feel free to fork/clone and modify the code. More extensions follow soon if time permits.
Faster if-else approach
Yesterday I was thinking about some performance tests for if-else statements e.g. in a game loop. I tried five different ways and here are my results:
1. using a common if-else statement
if (condition == true) value = 10; else value = 5;
2. using the short, inline version you'll be maybe more familiar from flex
(condition == true) ? value = 10 : 5;
3. using only one single if
if (condition == true) { value = 10; continue; } value = 5
4. using double if instead of if-else
if (condition == true) value = 10; if (condition == false) value = 5;
5. doing some math
value = int(condition) * 10 + int(!condition) * 5;
When iterating over a fori 1.000.000 times we could measure the differences of these implementations. Think about a game loop, doing updates every frame with multiple if-else checks on different conditions to rate this results.
Results:
1. ~220 ms
2. ~151 ms
3. ~290 ms / ~219 ms (if condition is false)
4. ~288 ms
5. ~150 ms
Interesting to see, that implementation 2 and 5 offer the fastest algorithms. Especially no. 5 is a very common way to avoid any kind of if-else but just useful in that case when calculating values. Depending on the calculation method 5 is as fast as method 2, but when using more complex calculation, e.g. Math.sin() and Math.cos() the second method is the fastest out of all.
Okay, if-else conditions are not the mayor problems in a game loop, but can also be increase performance a little if that matters.
Develop in a Multi-Platform World with FDT
As @renaun already mentioned in his blog post, when you develop in a multi platform world things can get complicated when you want to manage your external libraries. If you start to develop a mobile application with AIR and target more than one device plattform like Android, iOS or the BlackBerry Playbook you could become the need to use different libraries, e.g. for the UI or common gestures like the QNXApplicationEvent.SWIPE_DOWN event in the BlackBerry Playbook OS.
One solution is to try-catch each class like described in renauns post. Another solution is to use compiler constants to handle the deployment process for the different target plattforms.
So if you want to tell the compiler to skip/compile such a piece of code you just can use the following workflow:
package { import flash.display.Sprite; public class Main extends Sprite { public function Main() { /*FDT_IGNORE*/ if(CONFIG::BLACK_BERRY_PLAYBOOK==true) trace('deployment for BlackBerry Playbook'); else trace('such a piece of code w/o Playbook support'); /*FDT_IGNORE*/ } } }
As FDT offers you the great feature called Live Error Highlighting FDT will tell you that there's no var called CONFIG::BLACK_BERRY_PLAYBOOK and shows an error. To tell FDT to ignore this piece of code you can use the FDT_IGNORE comments.
There is also a code template for it. Just type 'fdti' and hit ctrl + spacebar.
All what you need to do is just add this constant to your compiler arguments in your debug configurations with the -define+= argument.
-define+=CONFIG::BLACK_BERRY_PLAYBOOK,true
That's it. Have fun while developing mobile apps with FDT.
Quicktip: FDT Singleton template
In our current project we're using the singleton pattern very often. To save time i'd written a short FDT Template for it. Feel free to copy&paste
1 2 3 4 5 6 7 8 9 10 11 12 | private static const _instance : ${enclosing_type} = new ${enclosing_type}(); public function ${enclosing_type}() { if (instance) throw new IllegalOperationError("Constructor should not be called directly. Use ${enclosing_type}.instance instead."); } public static function get instance() : ${enclosing_type} { return _instance; } |
Air for Android: Device Orientation – Best Practices
I'm just forwarding a question from @tonylukasavage
Do you create states, separate views, or something else to handle a GUI that changes layout on orientation change?
For myself I would handle a Flex View Component with separated states, but on AS3 only, I would prefer to use two different view classes for portrait and landscape orientation and switch them via a screen controller.
What do you think is your best practice?
Feel free to comment!
Quick Tip: FDT 4 & Mobile – Supporting Multiple Screens
For my upcoming bachelor thesis I am working on an AIR for Android Project at the Powerflasher GmbH agency. Usually I directly debug the application on a Google Nexus One, but sometimes it is more comfortable (e.g. for wireframing) to use the ADL to avoid wasting time when building and deploying your application.
To get your application running on the ADL with different profiles and screen sizes you just have to change your launch configuration in FDT. If you're using the new Flex 4.5 (Hero) mobile casses, the first step is to tell the compiler to use the airmobile-config.xml. You can do this by adding just one line to the compiler arguments:
+configname=airmobile
Now the ADL should launch and render your app like expected. To test different screen sizes you could configure the width and height by hand or just add one more line to the Air Debug Launcher arguments:
-profile mobileDevice -screensize NexusOne
That's it, now you can develop and test your mobile applications with FDT 4 and the ADL on different screen sizes. You can get the whole list with valid arguments at help.adobe.com .
Blog Blog
Today I got my WordPress Blog running. In the future I want to publish some articles about my work at Powerflasher GmbH or even personal projects.
Currently I'm working on my bachelor thesis about mobile development for Android devices with Adobe Air.