Sometimes you create a custom sprite which has graphical elements but as a best practise you want the graphics/ or new Sprite to be added only when this custom sprite is added to displaylist and not when it is initialized.
Whenever a displayobjectcontainer adds a displayobject it dispatches two events namely ADDED and ADDED_TO_STAGE. The sprite can listen to these events and do the necessary. There is a difference between these wo events. Following is an example demonstrating there usage.
private var objA:Sprite = new Sprite();
private var objB:Sprite = new Sprite();
/* comment 1
ADDED event gets dispatched when the listening displayobject
is added to another display object (whether or not in placed in stage
any other displayobject is added to the listening display object
/* comment 2
ADDED_TO_STAGE event gets dispatched when the listening displayobject
is added to the stage (timeline)
is added to any other displayobject which is added to stage(timeline)
//objB.addChild(new Sprite()); // this will put the loop in
//recursion read comment 1 becoz a display object is being added to the listening object again so ADDED will fired
Flex profiler is a part of the Flex Builder IDE, that listens for messages from the profiler agent. The profiler agent is a swf launched in parallel to your main swf. It is located in your Flex workspace at .metadata/.plugins/com.adobe.flash.profiler/ProfilerAgent.swf.
I had a hard time getting it worked. Here is what worked to make it working:
Create (edit existing) file named mm.cfg (location windows: c:/users/user) and add following line
In addition to above you can other options which are quite helpful for debugging:
Above options will redirect the
trace() output to an external file which can you browse using any text editor.
The flashlog.txt file will be created in the following location:
C:\Documents and Settings\username\Application Data\Macromedia\Flash Player\Logs\flashlog.txt
What is Halo? Halo is the framework, which Flex uses to design a UI component. Any complex custom UI components made in Actionscript need to be made using this design mechanism. Just to add “Spark” is the name given to new component and skinning architecture for Flex’s next release, code named Gumbo.
The key consideration that Adobe guys have given while designing Halo is implementing concept of “Lazy validation”. The idea is to cache the requests and separate them for processing for some optimum time. This is done by Validation/Invalidation model.
preinitialize() à createChildren() à initialise() à invalidation/validation cycle à creationComplete()
Invalidation is captured by 3 methods:
invalidateProperties() - call this to add/remove children not required through the life of the entire component, this function will finally call “commitProperties()”
invalidateSize() – call this whenever UI component width/height will be likely to change, this function will finally call “measure()”
invalidateDisplayList() – call this whenever UI component layout will be likely to change, this function will finally call “updateDisplayList()”
Validation is captured by 3 methods:
What the heck? Right. So basically, the validation functions are overwritten in subclasses that you create but these are not called directly. Whenever you expect change in properties of the UI component call the invalidate function instead of the validation function. Why? Because as said earlier the idea is to cache the requests and separate them for processing for some optimum time so as to take care of multiple property changes continuously made by a user.
In addition to invalidate calls dirty flags and storage variables need to be used to this to happen. What this mean is whenever a property is changed, flag the change with a variable (dirty flag) and reset it once the validation function is called additionally hold the actual property also that will be used at time of validation.
Most of the above info has been taken from following sources:
I had been involved in projects which have used REST and RPC style of web services. But every time a newbie try to get into the heap of these protocols and jargons he/she gets lost. For all those and myself too here is a brief idea of what these are and there relation(if any). So this POST is for entry level web geeks only.
HTTP is an Application-level protocol for client server communication. Typically, an HTTP client initiates a request. It establishes a Transmission Control Protocol (TCP) connection to a particular port on a host (port 80 by default). An HTTP server listening on that port waits for the client to send a request message. Upon receiving the request, the server sends back a status line, such as “HTTP/1.1 200 OK”, and a message of its own, the body of which is perhaps the requested resource, an error message, or some other information.
Web services are just Web APIs that can be accessed over a network, such as internet, and executed on “remote” system hosting the requesting service
SOAP and REST are web services protocols. To mention WSDL holds the definition (how to use? type) to the web service and hence is not a protocol.
REST is universal protocol for client server communication. Even HTTP rest on REST though we generally used this term in relation to web services and not “web pages” ( A web page is a representation of a resource/object.). So like for web pages HTTP, for web service REST. The key difference between a web page and web service is the type of content. In HTTP, all that data comes back to your browser (as HTTP body) in “HTML format”. But when a client calls a “web service” to get some information, it is usually some specific information. Thus, the first difference between a web application and a web service is that the HTTP body or content in response to GET significantly varies in content and format.
REST is a limited “verb” and infinite “noun” based protocol. It uses standard methods; two everyone knows (GET and POST), the set of standard methods includes PUT, DELETE, HEAD and OPTIONS. Every resource page will have these “interface” methods.
Here are some examples of URIs you might come up with:
You don’t call a specific function/method every time in REST but you do call a specific page for a new resource/object. Remember, in REST, we expose objects and not methods. Imagine an HR associate wanting to view employee Peter Scheufele’s details and she typing in http://employeeinfo/v1.4/employee/12098
in her browser’s address bar! She has to know that 12098 is Peter’s Employee Id. Even if she does not know that, how about the URL: http://employeeinfo/v1.4/employees?name=peter
and get back a list of employees whose names have “peter” in them?
Note the words employee and employees in the two URLs above. They are the resources. Resources are the objects exposed by the REST web service and accessed using the URL itself. In this example, the web service exposes two objects employee, representing 1 employee, and employees, representing the collection of employees. Instead of being an URL, these addresses above are, truly speaking, URI-s. Because they do a little bit more than locate a resource, they actually identify a resource. That is why these are uniform resource identifiers.
SOAP is XML based protocol like RSS and ATOM. SOAP needs less “noun” and more “verbs” i.e. each resource is uniquely identified by XML and has only one web url representation. Call is made to one specific location, which has all the knowledge (methods/functions) to understand this XML and respond accordingly.
Basically, SOAP has a XML wrapper, which carries the type of request and data. There is a standard wrapper but you can have your own too which your server understand that would be your own protocol AND NOT CALLED SOAP.
GET /stock HTTP/1.1
The SOAP request tends to be overly verbose, but generally (not always) easy to understand. The SOAP envelope wraps an optional Header and the Body. The Body contains the actual XML request object. The Header contains information not required to service the request, but that help in some other way. A common use of the SOAP Header is the attachment of user credentials to the request. The beauty of SOAP is that it’s not bound to the HTTP transport, although HTTP is by far the most commonly used transport for SOAP messages.
HTTP/1.1 200 OK
The SOAP response, also slightly overly verbose, but easy to understand. Now, imagine getting this response and you want the m:Price element text. How would you formulate the XPath to acquire this bit of information? Very simple (“//m:Price/text()”).
To call a SOAP web service you should be aware of the methods that the web service has and call them. For example SOAP web service created in .NET will have “one” URL (resource/noun) where the .asmx file will reside which will the methods (verbs).
methods could be sayHello(name) etc
From client, Call the page’s appropriate method with the name value
RPC Web service
Is similar to SOAP but its just you don’t use SOAP’s XML wrapper you can have your owm or even you can different data format e.g AMF to send across. In case of AMF you also need a AMF gateway to serialize this binary data and then sent it to a webservice.
e.g. AMF gateways – AMFPHP, Zend, WEBORB, SABREAMF, Flourine, BlazeDS, LCDS etc.
A lot of above information/example have been collated from different sources (listed in “References”).