Inspired by this Flex question, is it seen as better practice to dispatch an event back to the parent app, as opposed to calling a method on the instance of the parent app, from within a module?
To me it seems that the module shouldn't know what methods are available at the parent, as such approach leads to tight coupling.
Thoughts?
I think I found my answer here.
Related
I try to change the scene hierarchy. The appendChild method work but the attachedCallback and detachedCallback are called too. I want just perform the appendChild's native code only.
How can i do it?
You cannot really for A-Frame's custom elements. The callbacks are critical. Maybe you can monkeypatch or inherit the prototypes (e.g., AFRAME.AEntity.prototype)? But heavily, heavily not recommended and strange.
I am building an React+Redux application, I come to the point where I am
considering to use a container inside another container. I am asking myself if
this is a good approach, ie. is it good practice, or should we strictly follow the rule of 1 container with several components ?
Let me quote Dan Abramov's article about presentational- and container- components:
When you notice that some components don’t use the props they receive but merely forward them down and you have to rewire all those intermediate components any time the children need more data, it’s a good time to introduce some container components. This way you can get the data and the behavior props to the leaf components without burdening the unrelated components in the middle of the tree.
...meaning it is perfectly fine to have a container component inside another container component if you feel the need for it.
It's not easy to find which component should stay "dumb" and which component should be aware of application and become a container. I don't think it's a problem / anti-pattern to use a container in another one. If a part of your application is used on different pages it can be a container, be connected and use in differents pages/containers, Just be aware : this "container component" will specific to this application
Hey guys!
We used to write our UnitTests with FlexUnit and we were just testing our model. Now we want to test the view too. Before i run my tests i create an instance of my view and my model to test the stuff. When i try to access the view i get a null pointer exception. If i add the view to the displaylist it somehow works - even if i remove it from the list right after adding.
it looks something like this:
var myView: MyView = new myView();
//myView.initialize(); will throw error
Application.application.addChild(view);
Application.application.removeChild(view);
myView.initialize(); // will work
Hope you can give me a hint.
Sims
Flex UIComponents do not walk through the component lifecycle until after they are added to a container. As such, variables may not be initialized and children may not be created if you never add it to a container.
More info on the Flex Component LifeCycle. You'll notice there are 11 steps after the component is added to the container.
I suspect that adding it, then removing it, could cause other issues but it depends what you're trying to test.
To know your exact error, we'd have to see what code is in the initialize method on the view. Most likely it accesses a child that was not created yet.
MXML components will often masks the lifecycle steps, but a component will still go through them.
I hope this helps; but since you didn't ask a question I'm not sure if that was the information you were after.
In addition to what (www.Flextras.com) wrote, which I was just about to post as well, you might consider a different approach to testing your views.
First, consider a separation pattern like Presentation Model, MVP or MVC. They allow you to separate your view from your view behavior and test the behavior separate from the view. An approach like this, when done correctly, will take you a long way because you minimize or eliminate the AS3 code in your view.
If you really want to test your views, I would suggest that you use a functional testing tool for this. Unit test frameworks are good for testing classes in isolation. Once you start talking about views, which have complicated lifecycles, a functional testing framework starts to make sense.
Look at FlexMonkey as an example of a functional UI testing framework for Flex.
I recommend you to use User Interface Facade described here or here. This functionality is designed specially for UI componets testing.
For developing simple games with the Flex SDK, what are the consequences of using a Canvas object, versus a UIComponent object, as a drawing surface? Are there performance issues with either one? Are the methods generally the same? Searching around, it seems that most sample code I've found uses UIComponent. Is this just customary, or are there reasons?
I already know one odd difference - I had developed a simple Pong game using:
public class MyGameCanvas extends UIComponent
and then decided to replace UIComponent with Canvas. This caused the line to fail:
addChild(paddle);
After spending too many hours searching, I finally found that a Canvas object requires:
rawChildren.addChild(paddle);
due to the inheritance chain of objects, Sprites being higher than Canvas.
But that doesn't seem like a reason to prefer one class to another. Are there any specific reasons? Thanks.
Update:
Okay, I guess Canvas is out, and UIComponent is in. The only reason I even tried a Canvas object is the name. I mean, it's a Canvas - isn't that where you're supposed to do drawing? :)
So the second question that has popped up is about using the Flex SDK (and I don't know if this should be a totally new question, or here is okay).
However, I have to confirm something, being new to Flex and the various terminology. I'm presuming that people mean I should not be using MXML for games, when they said Flex SDK. Since I thought the Flex SDK was what provided the compiler that generates .swf files. Otherwise, where/how would I even compile AS3?
Assuming that's the case, then my question would be about the suitability of using both MXML and AS3 for (simple) games. Based on what I've read about both, it seemed like the intended use of them was MXML for the interface elements, and AS3 for everything else. Is the overhead that bad for MXML?
John C>
I think there is no point at all to use flex sdk to develop a game.
Flex SDK has been designed with application development in mind so you shouldn't use it to make games.
Do you have specific reasons to use it instead of a plain AS3 project?
Canvas has a bunch of extra layout code, plus scrollbars. It's definitely heavier than UIComponent alone. Also, it's important to know that Canvas requires all children to be subclasses of UIComponent. Using rawChildren to add non UIComponent is a hack unless you're building some sort of "chrome" for a Flex container (scrollbars on Canvas and the border/background in Panel).
I agree with PeZ, though. The Flex framework probably isn't the right choice for a game. Unless you have a game UI with things like DataGrids, Trees, Charts, etc., you can get a smaller and more optimized SWF without Flex.
If you dont need the additional stuff in canvas, like the scrollbars, that's clearly a reason to prefer UIComponent. Canvas is just an heavier object.
Recently I found out that there are several things that one can do to massivly slowing down a Flex application. One of those things is the use of many nested layout containers. Another thing which is very problematic is the usage of lot's of relative positioning and sizes.
I do understand that there is a very big amount of calculations that must be done before the layout elements can be displayed. What I do not understand is why the rendering is done all the time. With a certain amount of complexity in your layout your CPU usage is 100% all the time even if there are no changes in the layout.
Why is that? And what can I do about that (without redoing the whole layout)?
Thanks a lot!
It is true that nested containers do slow things down, but I haven't yet been able to get the CPU usage up to 100% yet. The framework should only recalculate the layout of a component after its invalidateDisplayList() has been called. Calling this schedules a call to updateDisplayList, in which the layout of a container is calculated. Consequently, the display lists of the component's children are invalidated as well.
Besides doing it yourself, the displayList can be invalidated by the framework for a variety of reasons. For instance, it is always invalidated after invalidateProperties(). It could be that you have something that accidentally invalidates the display list of some high-level container all the time, thus propagating it down to its children.
Do you have any code to share? And what kind of a system are you running?
Any other solution other then refactoring your layout and not use many nested elements means change the way adobe framework works, and you do not want to do it !
My suggestion although might be painfull , change your view components , use absolute size and location where possible , do not nest too many elements .
The reason for the bottle neck with nested components is that the invalidate functions go 2 way , first up the tree from the changed component to the root , then from the root to all its nested elements , that whats taking your cpu .
Finally I found out what exactly the problem with our application was!
The problem was not that we used lot's of nested layout containers. I found out that there was a third party component that we use which attaches an event listener to the ENTER_FRAME-Event. Unfortunately this component does not shutdown properly so the event listener never gets removed. One thing this event triggers is a call to invalidateDisplayList(). I found out that the ENTER_FRAME-Event occurs very often (I still don't know why exactly this happens) and because of that the whole layout is recalculated over and over again. Because of the nested structure of our layouts this is a very time consuming thing to do and therefore the CPU gets very busy!
I could solve this problem by adding some extra code to the component that properly removes the event-listeners if they are no longer needed. The result of that has been that the application now does not need any CPU-power when in idle-mode. Hooray!!