StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
2269449
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2010-02-15T22:39:49.777
FavoriteCount
0
LastActivityDate
2010-02-16T00:55:03.503
LastEditDate
2010-02-16T00:55:03.503
LastEditorUserId
169992
OwnerUserId
169992
ParentId
2269328
PostTypeId
2
Score
8
ViewCount
0
LastEditorDisplayName
text
Body
First, I 100% recommend studying this presentation by <a href="http://www.effectiveui.com/" rel="noreferrer">EffectiveUI</a>: <ul> <li><a href="http://tv.adobe.com/watch/360flex-conference/diving-deep-with-the-flex-component-lifecycle" rel="noreferrer">Diving Deep with the Flex Component Lifecycle</a></li> </ul> and this by <a href="http://www.linkedin.com/in/labriola" rel="noreferrer">Michael Labriola</a> from <a href="http://blogs.digitalprimates.net/codeslinger/index.cfm?mode=entry&entry=E183CFC3-FFF8-98FF-6D00B91ADAB60593" rel="noreferrer">Digital Primates</a>: <ul> <li><a href="http://tv.adobe.com/watch/360flex-conference/diving-in-the-data-binding-waters-by-michael-labriola/" rel="noreferrer">Diving in the Data Binding Waters</a></li> </ul> They go into things you'll never find in the docs but that are super practical for understanding the Flex Component Lifecycle. From my experience, the only time you need to worry about overriding core lifecycle methods is if you are creating components. I make a distinction between Application Views and the Components. <ul> <li>Components are things that need to be nearly perfect, highly optimized, and extremely versatile/abstract.</li> <li>Views are things that you may only need in one Application, but could reuse if you so desired (LoginScreen, ContactForm, etc.).</li> </ul> Views, for the most part, are just adding things to the display list of a more generic component (Canvas, Group, Container, VBox, List, etc.). You, as a View/Application developer, don't really care about how the "dataProvider" creates it's itemRenderers, it just works. Components are a different story though. When you create a component, you want it to fit perfectly into that system Flex has set up: the Component Lifecycle. It's pretty tough when you first try to build a component like they do, but after you wrap your head around it it's super easy. Here's how I think of the methods when I develop components: createChildren() <ol> <li>Called once when component is constructed</li> <li>Called top down. So if <code>Panel</code> calls <code>createChildren</code>, it's <code>createChildren</code> method will call <code>addChild</code> on all of it's children, which calls <code>initialize</code>, which calls <code>createChildren</code>.</li> </ol> If you created a custom component, say a StarRatingComponent, you might want to add 5 stars to the stage when the component is constructed. So you'd override <code>createChildren()</code> to do add stars to the component you're in. By default, though, all Container components in the Flex SDK add their children here (lists do it a bit differently), so you never have to do this if you're building MXML views or something not-to-be-extremeley-reusable. The next 3 methods are called 1 frame after properties are set. measure() <ol> <li>If the parent doesn't have any sizing (percent or explicit), it will need to be sized based on it's children's sizes. This can only happen from the bottom up (took me quite a while to really wrap my head around that).</li> <li>If the parent has explicit or percent sizes, it skips this step.</li> </ol> You override <code>measure</code> if you want to: <ol> <li>Have <code>measuredWidth</code> or <code>measuredHeight</code> return a useful value. So if you build a custom CoverFlowContainer component, and <code>measuredWidth/measuredHeight</code> aren't set (because <code>measure</code> was not overriden), then if you don't specify any sizing on CoverFlowContainer, it would be 0 width 0 height. So instead, override <code>measure</code> and have it set <code>measuredWidth</code> to <code>radius * 2</code> or something like that, and now you don't need to give it a size!</li> <li>If the component does not have an explicit or percent size, measure will be used to size the component. Otherwise it's skipped.</li> </ol> commitProperties <ol> <li>Called after <code>measure</code>.</li> <li>Applies all property changes (from setting properties on the component) to the component (they were stored in private variables for that first frame).</li> <li>Called a frame after initial property settings.</li> </ol> This is the most important method to override in my opinion. So for your CoverFlowContainer, say you set the hypothetical <code>distance</code>, <code>gap</code>, <code>selectedItem</code>, and <code>tilt</code> properties. When you set them, store them in private variables. Flex will wait a frame, and call <code>commitProperties</code>. In your overridden <code>commitProperties</code>, you can then say <code>layout.updateEverything(selectedItem, distance, gap, tilt);</code> so to speak. So this is the method you override to make all property changes be applied at once. updateDisplayList <ol> <li>Called after <code>commitProperties</code></li> <li>Called top down.</li> </ol> You only override this to set visible properties on the component, such as <code>setActualSize</code>, <code>graphics</code>, etc. But by now (because of `commitProperties), you have all your required variables to update the display set to the right values. Overall So from my experience, I worked a lot with these lifecycle methods when creating a component library for things I would use in a million projects: <ul> <li>TitleWindow (my own version)</li> <li>View3D (for Away3D/Papervision)</li> <li>Tree and Stack for Flex 4</li> <li>TextArea (with prompt, expandable, etc.)</li> <li>ToolTip (easier to skin tooltip)</li> </ul> I needed to make sure everything was updated and rendered perfectly according to the lifecycle. Reading and understanding the <a href="http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/frameworks/projects/spark" rel="noreferrer">Flex 4 Spark Source Code</a> really helps clarify when to override these methods. As does the <a href="http://code.google.com/p/openflux/source/browse/#svn/branches/phoenix/OpenFlux/com/openflux" rel="noreferrer">Openflux Source Code</a> (very simple, clear alternative to the Flex Framework. Not as feature rich so it shows how to bare-bone override those methods to accomplish some pretty advanced things). When I develop applications and make things like <code>AdvertismentView</code>, <code>MenuView</code> and <code>LoginView</code>, I don't ever think about it because all the components I'm using have already solved those problems (ViewStack, Group, List, etc.). I'm basically just setting properties they've defined and updated in their own <code>commitProperties</code> override. The only time I would start overriding lifecycle methods in a View would be when I need to access custom variables from outside the view. So say I had a custom RichTextEditor and I created some properties called <code>showFontControls</code> and <code>showStylePanel</code>. When I set those variables, I would probably do what they described in the <a href="http://tv.adobe.com/watch/360flex-conference/diving-in-the-data-binding-waters-by-michael-labriola/" rel="noreferrer">Data Binding Presentation</a>: accessor sets private variable and calls the invalidation methods, lifecycle methods execute a frame later and I have overridden <code>commitProperties</code> and <code>updateDisplayList</code> to show those panels and fonts. But in practice, that's probably overkill because it wouldn't offer that much of a performance gain for the amount of work it would take. I'd just set up some binding to a <code>visible</code> property in that case. Nevertheless.... The best thing to do to really get into this is to just download the <a href="http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/frameworks/projects/" rel="noreferrer">Flex SDK Source</a> and see what they're doing. Hope that helps. Lance
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POwhen should I override 1 of the lifecycle methods?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USLance Pollard
UserOwnerUserId
1. USLance Pollard
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POwhen should I override 1 of the lifecycle methods?
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COExcellent breakdown. I especially like how you distinguish between components and views.
 singulars
 PostPostId
 PO
 UserUserId
 USJonathan Dumaine

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.