If you have downloaded the project template for Flashdevelop: http://blubl.geoathome.at/wp-content/uploads/2010/10/091-ActionScript-3-Android-AIR-AS3-Projector.zip
… put it in the flashdevelop/projects folder. Now you can select Android/Air app in the “new project”-screen. The template contains a good readme.txt for what you need to do.
Additionally you have to setup the compiler options and setup the custom path to Flex SDK. Also start adl.exe with the parameter -runtime to lookup the version of it. If it says 2.6 you have to change the application.xml accordingly.
Otherwise adl will quit its job telling you: Error while loading initial content. Now you should be able to test you apps in FlashDevelop.
Changing Screen Size
If you want to change the screensize in which adl opens your app go to project settings and edit “run custom command”. Change it to:
$(FlexSDK)\bin\adl.exe; -screensize 600×1024:600×1024 application.xml bin
The second resolution is for fullscreen mode and needs to be set for adl to work.
I want to point out some reason why Robotlegs makes sense. For someone who does not know Robotlegs: It’s an Actionscript 3 framework that builds upon the Model-View-Control (MVC) code design pattern. In short: You can use it to seperate the logic of your application (controller) from the data (model) and the representation of it (view).
You can find implementations of MVC in divers frameworks and programming languages – frontend and backend alike. When you google MVC pattern you can read tons of articles about the pros and cons.
Communication between Objects made easy
Beside MVC there are two other features I really appreciate about Robotlegs. First, it has a build in event bus. You should know events from Flashs Display List. Objects that get created if the user “does something” with the user interface (e.g. MouseClick). These event objects can bubble up the display list (the hierarchy of nested displayobjects like Sprite or Movieclip). Thats nice as it is but the events are bound to the displaylist. In Robotlegs the objects share an eventdispatcher they can utilize to listen for events or to send events into the framework – and that is not limited to user interface elements nor the displaylist. The benefit is: You do not need to know the actual object that broadcasts the event meaning you do not need a reference to the broadcaster in your listening classes. Just listen to the event bus and everything works.
Robotlegs helps to reduce code
The other thing is automated Dependecy Injection (DI). (Google it for more information). What automatic DI does is it provides your classes with their dependencies. If you have a Car class and that class needs an instance of the Motor class to work properly when getting instantiated Robotlegs does it for you. That means you do not have to write construction code to first get a motor, instantiate it, then create a car and put the motor in it’s constructor. Code instructions like that are called boiler plate code, code with the sole purpose to create and combine objects, code that has no business logic. Sure you have to instruct Robotlegs on startup what objects are created at what time but that is, compared to manual creation and combining, a lot less code.
And it does not make it harder to understand
Some say using frameworks like Robotlegs bloat your code and DI makes it hard to understand what happens where. But these arguments are even more true for individual code. I had to get back to my last bigger project built with Robotlegs after 2 month. I found it really easy to put in new functionality because of the seperation due to MVC and DI. I just wrote another class, pointed out that this class needs an instance of the model when instantiated and was ready to go. Without Robotlegs I would have needed to break apart my code base and look for hooks in my code to put the new class into place – more boilder plate code or even restructuring other classes.
Robotlegs or other frameworks are not made for very very small projects like banner advertising because they naturally put in some kB for the framework classes but if your project is not restricted in that way give it a try. It not only makes your code more flexible but makes you think about object communication in general.
There are a lot of blog posts on the topic of smoothing pictures in Flash after loading. The process goes like this:
private function onPicLoaded(e:Event):void
var pic:Bitmap = Bitmap(e.currentTarget.content);
pic.scaleX = pic.scaleY = 0.2;
pic.smoothing = true;
But few mention that you also have to set:
stage.quality = StageQuality.BEST;
in order to have the pictures smoothed. Preferably you set this value at the very beginning of your application, in your main class. It’s not neccessary to do it everytime you loaded a picture, its a global setting.
If you are loading your pictures from a different domain there seems to be a problem when there is no policy xml file on that server but you can find solution for that on the web.
If you try to import a sql database dump file from any Concrete5 installation to another one you can get some problems. Here is a checklist(will be updated if necessary) what can happen:
- if you made a dump file from a Concrete5 installation that runs on a unix system and you now want to import it into a windows environment you have to deal with case sensitivity: Unix DOES care if a table name is ‘myTable’ – Windows DOES NOT care. For windows ‘myTable’ and ‘mytable’ are the same. Concrete5 does use upper- and lowercase letters in there database tables. You can setup your SQL Database to deal with names differently. Here is how: deutsch english.
- the import script (your dumped file) implies that your local database already has Concrete5 tables in it and before it imports any data it tries to delete the tables. If there are no tables to delete sql throws an error like this: mysql error: [1051: Unknown table ‘AreaGroupBlockTypes’] in EXECUTE(“DROP TABLE AreaGroupBlockTypes;”).
Edit the sql file and replace any accurance of ‘DROP TABLE’ with ‘– DROP TABLE’, save and import again. It should work now.
- to be continued…
- Download the most recent version at the zend framework download page
- unzip the package to any location you want (e.g. c:\frameworks)
- if you have xampp installed you already have a version of zend framework available under \xampp\php\PEAR\Zend. Best would be to just delete all the files in there and copy the content of the library folder from your fresh Zend Framework installation into the folder. Also overwrite the zf.bat und zf.php in D:\xampp\php with the new once in the bin folder of your Zend Framework installation. Now you can skip the next two steps
- find the ‘bin’ folder containing zf.bat and add the path to your path variable in windows
- edit your php.ini in your PHP installation. (e.g.: c:/xampp/php/) and add the path of the ‘library’ folder of the zend framework to the includepath. (Search the php.ini for includepath until you find something like that: include_path = “.;c:\xampp\php\PEAR” and just add path to the library folder)
- add the folder of your php installation that includes php.exe to your windows path like you did before with the bin folder of zend framework
- now open a command line window (execute – ‘cmd’), navigate to a folder where you want your project to reside in and type:
“zf.bat create projectname” (replace projectname with any name you want)
- edit the file hosts in (C:/Windows/System32/drivers/etc/). If you cannot see the etc folder in drivers just type in the path, it’s sometimes hidden. If hosts is not editable or saveable start your editor in administrator mode and make sure no other program uses that file. Enter the following:
127.0.0.1 quickstart.local (that defines a host that routes the url quickstart.local to 127.0.0.1(also known as localhost). You can chose whatever name you want, e.g. dev.projectname but make sure to reflect the change in the next step.
- open your httpd.conf file in your apache config folder (e.g. ‘d:/xampp/apache/conf/’) and search for the term virtualhost and enter somewhere below:
SetEnv APPLICATION_ENV “development”
Allow from all
Servername needs to be the same like in hosts. Document root needs to point to the public folder of your new Zend framework installation.
If you now start your apache you should be up and running. Open your browser and type in quickstart.local.
If this description was too short the manual from Zend is good stuff.