I’ve recently had the opportunity to dig into Flex 4 skinning a bit deeper with the latest beta. While there is a lot to be desired from the separation of concerns in moving display code into the skin and leaving logic code in the component, there is one LARGE gaping deficiency in Adobe’s model.
I’ve noticed a number of people here (Andy McIntosh), and here (Andy Hulstkamp) working with button icon skins. The main reason for this is that Adobe saw fit to remove the icon property from the Spark button. Being a visual element, it does make some sense for Adobe to let users specify a button icon inside a skin as opposed to putting it in the main Button component.
Now to address the LARGE gaping deficiency in Adobe’s model. Adobe developed the skinning architecture WITHOUT taking something into account that we developers use on a regular basis. This is the Object Oriented principal of Inheritance. Note the following excerpt from Adobe’s livedocs:
Try to encapsulate skinning code. Place code that is used by multiple skins in the component class. Place code that is specific to a particular skin implementation in the skin class.
Most skins use absolute layouts within the skin class.
When creating skins, do not subclass existing skin classes. Instead, copy the source of an existing skin class and create another class. Use this method especially if you are going to reuse the skin for multiple instances of a component or multiple components. If you want to change the appearance of a single instance of a component, you can use FXG inline.
When creating a Spark skin, you can use MXML, FXG, embedded images, or any combination of the above. You do not use run-time loaded assets such as images.
The inability to inherit skins is going to kill my productivity as a developer. For example, let’s say I really liked the code Andy McIntosh had done with the IconButton (which I do) and wanted to re-use it. Let’s say I’ve also done some work on button skinning for my application and I want nice looking gel buttons like this:
Can I set up my GelButtonSkin to inherit from Andy’s IconButtonSkin to take advantage of his image functionality, but override his background drawing with my own? The simple answer from Adobe is NO. In order to accomplish what I want, I’ve have to create a completely new skin class and use copy/paste from both my GelButtonSkin and Andy’s IconButtonSkin to get my desired functionality.
You might say, “Well, Adobe says in the quote above that code that is used by multiple skins should be placed in the component class”. This begs the question though… Why did Adobe remove icon as a button property in the first place? It’s obviously one of those things where you might want different flavors of it. Perhaps a rectangle button /w icon vs. a rounded button /w icon. Instead, we’ll see a fragmentation of Flex while everybody and their brother develops their own flavor of IconButton along with their own custom skins to do exactly what they want. Productivity for developers moving between projects is going to take a hit due to this lack of code re-use.
Note: This post is intentionally antagonistic. I’d love to be proven wrong on my assertions. If someone has come up with an elegant work-around to the problem of skin re-use and inheritance that doesn’t resort to copy/paste, I’d love to be educated and saved from my ignorance.
August 3rd, 2009 at 4:42 pm
So far, I saw all designer very happy with spark. Adobe really made spark with design in mind!
But, as you said, developers aren’t forgotten… may be not entirely, but this code reuse lack is very problematic….
Copy & paste will produce unmaintanable code…. imagine, Andy fixes a bug on icon button…. I will need to search all my code for that skin and replicate the fix…
But I will follow this, hopefully someone was smarter then I and find a fix for that.
VELO
August 3rd, 2009 at 11:46 pm
Hey Andrew,
This is not the only answer but let me take a crack. Our docs may be a little extreme in their wording, but I think it’s to make a point. We really think about the skins when a designer is involved, and gear our docs in this manner. Putting together a hierarchy of classes for skins is not very toolable. How does a designer look at a particular skin and then tweak it? We looked carefully at how designers work, do they think in terms of re-usable pieces, componentize, etc? They don’t! They copy/paste everything! And given that they operate this way, could we find a way to provide skins in a way that made sense to them, and deal with the complications if let’s say they copy a skin and then modify it just a little? If your skin was made up of some superclasses, what if the thing that the designer wanted to modify was not in the leaf? What if they essentially re-parented a base class component? That can’t be done easily in an MXML subclass. So to make skins easily modified by a designer, we recommend putting everything together.
Now, if you’re a developer and you’re only going to work in code with other developers once you get your hands on the skin (designers don’t get to modify in the tool) then maybe you can go ahead and do some hierarchy. Look at the Spark skins, we set up a base class with functionality, but those skins are not created by tools. We write those suckers by hand to make sure all the styling and whatnot is there. In the future, maybe we’ll be able to tool that, but not for now. If this model will work for you, we’re all for it. But we think if you’re going to really be working in a collaborative environment, the designers are not going to be able to handle the skins if you try to think of them as OO classes.
We’re open to feedback on this though, especially for how we can improve the dev side of this in the future.
Matt
August 4th, 2009 at 7:31 am
Velo and Matt. Thanks for your responses. Both make some sense. I think we need to take a look at doing our skins mostly in actionscript for those parts of skins that will be re-usable such as the button image above.
I just can’t see using copy/paste when maintaining a large app. Especially if we decided we needed to change something like how a transition worked in all 1000 text fields.
I guess for my own workflow, I don’t want a designer touching my code and copy/pasting junk everywhere. I’d rather take what they gave me and create something inheritable and re-usable.
Matt,
Have you thought about the possibility of allowing a SkinnableComponent take an array of skin classes? Then I could have a skin that did nothing more than the image and a second one that did my background and just layer them up or reuse them independently. I know there might be an issue with how SkinPart works and searching for those required parameters though.
August 4th, 2009 at 12:58 pm
I think you’re basically talking about making components take a composition of skins. That’s kind of what Halo does, it’s considered a fail according to our goals of making it easy for folks to swap things around in a major way.
Keep in mind that you can of course do things to make skins re-usable for multiple instances. Add styles, make things resizable, etc. Then just assign the same skinClass to your components. You can make a skin complex and it will then be usable however you want. Write it in AS or in MXML, it’s up to you. But as far as what we’re going to encourage, when the stated goal of the architectural change is enabling high-design, it’s going to be the methodology we’ve discussed. As people experiment in more enterprise-focused apps I think we’ll see where the appropriate mixture of approaches plays out.
August 4th, 2009 at 2:45 pm
I’m not sure what workflow you’re going for, but here, designers don’t touch code. They send us images for what they want along with annotations for behaviors. I don’t want them touching code due to the unmaintainable mess this would produce. I guess we’ll have to agree to disagree on this one and see how it plays out.
August 4th, 2009 at 11:57 pm
@Andrew, if you consider that all these changes to Flex skinning seem to be driven by Catalyst, the decisions do look at a lot more reasonable. It seems Adobe wants to get away from the workflow of designers giving PSDs to developers and instead they will give you completed skins or even a semi-functioning prototype. There is a cost to the developer but the benefit to the designer/developer workflow could be much greater, assuming your team gets on the Catalyst bandwagon like Adobe would like you to. Most likely future version of the rest of CS will be able to be more tightly integrated with Flex too.
August 5th, 2009 at 7:09 am
@Darren
The problem is how to reuse this catalyst code….
Imagine you develop a component… let’s say I made a Datagrid to sell (I know it exists and it is free, but let’s assume it doesn’t)…
I can’t sell just the SWC, I need to send the skin source as well, otherwise people won’t be able to skin it.
Or let’s think on this IconButton example…. how many IconButtons will exist around the world? If I need any change I need to create a new one, I can’t extends the original and do my changes.
This lack of code reuses really scares me. It reminds me an old software that I saw, where everybody copy n paste code for everything. No code reuse at all…. maintain that was extreme painful.
VELO
August 5th, 2009 at 7:55 am
@Darren,
I’m still not sold on catylist yet although it does look promising for our designers to work with for prototyping. It really all depends on how clean the generated code is and how maintainable. In all the demos I’ve seen, it’s either a black box of code, or they just don’t like to show us the generated code. If either of those cases is true, no catylist code will be making it into my final products. Call me old fashioned, but I don’t really trust code generators unless I can fully understand and modify the generated code.
August 5th, 2009 at 10:01 am
It scares me big time to hear that we should be copy/pasting code around. VELO made an EXCELLENT point that skins cannot be packed in a SWC file because you wont be able to extend them without handing out the source and having it “copied”. Then if a skin/component is updated, it becomes even more painful merging the differences. What if I don’t want to give out the source?
August 17th, 2009 at 5:35 pm
I’ve had a lot of success with degrafa and advanced css button skin available here: http://www.flexstuff.co.uk/2009/04/30/degrafa-extend-cssskin-to-skin-flex-buttons/ This generally allows me to build a single button, skin it’s states and pass in src variables for its relative up, down, over, disabled icons.
September 20th, 2009 at 10:41 am
Why not update the one skin (and IconButton) to include layout for an icon part? If the icon part has no size, simply don’t position things around it. Spark’s Button will ignore it and never set its source, and your skin will work in both?
December 1st, 2009 at 9:02 am
I have exact issue! I work on flex 4 project where I need designer to take care about design but also have flexibility to change certain elements at same time. I also wrote article about this issue with few work-arounds http://blog.paveljacko.com/?p=29 but I couldn’t find any really clean way how to achieve this goal. please let me know if you find better one:)
December 14th, 2009 at 7:41 pm
This whole post reaks of a lack of understanding of the flexibility and purpose of skins.
While it’s true that skins can not be subclasses, they can be made to be extremely flexible, using custom properties, or states to define their behaviour. There’s no reason you should be using a different skin for each TextField, rather design one robust flexible skin, which takes some parameters, and use that for everything.
In addition, Skins do NOT define functionality . They are simple components, which are only meant to define visual layout corresponding to a given state of a component. So there should be no real concern about updates, or bug fixes.
In the vast majority of cases, because of the nature of what skins do, any bugs should be quite minor and extremely easy to fix. Skins should not really contain super complex logic, or anything that would require some sort of major update.
And I guess as a final thought, having to extend skins would sortof destroy the beauty of them imo. The nice things about them is the FLEXibility, if you need to make a change just do it, and don’t worry about it. Don’t want to be saddled with a bunch of stuff you don’t need, just delete it…. it’s nice.
Everything doesn’t have to be OOP all the time. In some cases, such as this, an OO structure would be a drawback and make things harder rather than easier 90% of the time.
December 14th, 2009 at 9:07 pm
@Shawn
So you are saying that 0 code reuse is a nice think just because is more flexible?
Writing an APP w/o code reuse is fine…. if you don’t need to care about maintain it.
VELO
December 14th, 2009 at 9:19 pm
Shawn, while I agree with you that OOP is not always best approach (with skins that sounds even more to be the case), I don’t think so you get the issue from right angle. Problem with skins is that they are completely flat. Think about them as Paintbrush…yes it’s simple and straightforward. And now compare it to Photoshop. In Photoshop you have layers which allow you to manipulate background without destroying some content in front. And this “little” fact makes huge difference. Obviously it’s not as “simple” as paint but it doesn’t mean you have to layer everything. Just use it when you need. So why designer can’t create background skin and then add some another skin with controls on top and as layer he could just drag background and use it on another component. That doesn’t include any logic in skins at all. But makes huge improvement in maintainability and scalability of project. Obviously it’s not suitable for every scenario, but even for those 10% it would mean big time saving (=>resource saving=>money money=>happy client). And this scenario is generally in large scale project where maintainability is well considered. I wrote about my similar issue on my blog. Would be happy if you can advise me, how to do that without skin inheritance or layering
December 14th, 2009 at 11:03 pm
I’m not disagreeing that being able to extend skins would be “nice”, I’m arguing about the idea that this is somehow a major issue, worthy of such a sensationalist blog title/post.
It would be nice, but is it required to make good maintainable code? I would argue no.
You mention PSD as an analogy, but I would argue that skins are inherently simple objects. So I’m having trouble imagining this hypothetical use case where this is such a huge issue??
Skins are flexible enough that a single project should never have more than a couple different skins for any given component. So where’s this problem with scalability that you mention? For example a single robust skin could handle all image based buttons for an entire app. A skin can make use of custom properties, and custom styles, based on your own components, which *should* give you enough flexibility to make your skins scalable and re-usable throughout any given project.
Of course, you may reach a point where your Skin gets overly complex, and you could save some time by being able to extend it. But even then, is there really a feasible/effective way it could be done? If I need to change one specific part of a skin, I can’t imagine any remotely straightforward way to do that with inheritence. Sure, you could easily hook up new functionality,but again, your skins shouldn’t really be defining alot of functionality…so I just don’t really see the need.
December 15th, 2009 at 6:40 am
@Shawn
I don’t see the Button/LinkButton scenario as overly complex…. although you can’t reuse anything from Button to build the linkButton… same happen on IconButton….
On IconButton is even worse, or I have a skin for each different icon ( which is completely unmanageable but the original suggestion comming from some users ) or I need to create a new class that inherits button just to make some room to configure the icon…. so I will configure a skin property inside the Button just because skin doesn’t allow doing something smarter….
Skins as it is may be great for designer who don’t care about writing 10 hundred skins and won’t need to ensure similar skins behave on a similar way….
And I see this as a major issue also…. a project like flexLib won’t exists for spark…. and people who create new components will have major issues to make their components shareable… specially in non-opensource scenarios….
VELO
December 15th, 2009 at 10:40 am
I’m not sure I follow you. First of all, you do not “need” to make an additional class to configure your button, you can set styles through CSS and read them in your skin, without ever having to declare MetaTags for those styles.
That’s not really best practice, but it’s not like it’s a big deal to set up your own class.
I don’t see the big deal with creating an EnhancedButton and EnhancedButtonSkin, which can handle button’s, link buttons or icon buttons, or any other buttons your specific project needs.
If it’s getting too comple,x split it out into 2 or 3 specific skin types, still very manageable and scalable.
December 15th, 2009 at 10:44 am
As for Skins being great for designers who like to write hundreds of skins….dude there’s tons of shit in there for developers. I can hook up init functions, state change listeners, I can add sprites through AS3 and draw using the graphics API, use state-based properties, access the parent’s properties & styles… i mean it’s pretty sweet.
December 22nd, 2009 at 5:40 am
@shawn: there are quite a few scenarios: for example skins which look the same and share some similar skin parts, but then every skin gets its own skin parts as well. Not to mention custom layout issues, which can’t be just applied via styles.
You would want to use inheritence in such cases to save time, money and avoid problems. And i do think that there should be tool and language support for such cases .
December 22nd, 2009 at 3:55 pm
Well, I agree that there are some fringe cases where extending a skin would be a nice thing to do, I just don’t think it’s something that really needs to be done on any regular basis.
And even then, I still struggle to come up with any “good” way that this can be done, without imposing a whole bunch of structure into the skins that we really don’t need.
Inheritence in OOP works well, because classes have defined functions, and areas of resonsiblity, which can be overriden/modified on an individual bases. In addition, we can decide where and when to call the super() functions should we require them.
Skins have none of that, in order to effective extend, and modify skins, we would need some sort of structure in the skins themselves that identified some discrete areas which could be overriden.
In the end, you would be imposing a whole bunch of crap for developers to deal with, for a use case which may occvur <1% of the time. Doesn't seem worth it.
I supposed they could simply allow you to extend a skin, and we could use getElementAt to modify gfx, but that would be extremely fragile and prone to breakage, so I don't see any benefits coming from there. Being able to extend a skin and override it's AS functions is about the only thing I can see that would work, and is doable, and they should probably implement something that allows us to do this.
December 22nd, 2009 at 3:58 pm
Actually I guess we could use id’s to effectively target/modify a specific skin component, and this could come in handy from time to time. But I still think it’s a rare need.
December 22nd, 2009 at 4:48 pm
Maybe if skin looks like this:
It would be much more usable then it is right now….
Even better if it allow more then one skin to support the multi layer idea…
VELO
January 18th, 2010 at 12:29 am
When I start digging the Flex 4 source code, I do find ways to make skin classes reusable. A simple example I would like to point out is ButtonBarSkin.mxml. With and , most, if not all, skin re-usability problem should be solved if you plan nicely before you code. Just my 2-cents.
January 18th, 2010 at 9:32 am
@Brian, Where do you find ButtonBarSkin.mxml? Is this an Adobe exmple, or something you found on the web? I’m getting ready to kick off a Flex-4 project, so any links to appropriate skinning techniques would help me a great deal. Thanks.
March 9th, 2010 at 1:54 pm
[...] across several blogs that hint that custom Spark skins should not be created via OOP inheritance I felt challenged. [...]
March 17th, 2010 at 9:12 pm
I think the most frustrating thing is adobe deciding not to include things like icon on the base button and just make it an optional skin part. It has been said that the goal is separation of look and functionality… For a button I would almost consider an icon to be identical to the label… Why was the label not considered part of the “look” to be moved into the skin? Most likely it would be ridiculous to expect us to reskin a button for just the label, so that was left in. For some buttons an icon is the label or at least just as important. I really hope Adobe considers putting things like this back on the class as optional skin parts. That should satisfy both sides of the camp. If a designer really wants his button looking exactly how he designed, just don’t include the icon skin part and bake the icon in… This doesn’t seem to unreasonable.
This would help fix the skin inheritance problems to a small degree as well. Right now I have a ButtonSkin, IconButtonSkin, EmphasizedButtonSkin, and an EmphasizedIconButtonSkin… All of these I want to have the same base button look and feel, and when I update that look and feel not have to change 4 different skins to do it. An Icon property on the button and adding emphasized states to the button would really make the OO minded designer happy! This would help cut down on a ton of different skins.
I really hope Adobe watches these situations and takes some time to help us developers out that want our apps looking good. We can’t all have dedicated designers… It’s just not realistic! Help us Obi-Wan Adobe!
March 17th, 2010 at 10:40 pm
Why not just have one skin, that accepts a couple different style properties?
If hostComponent.getStyle(“iconSource”) is set, show the icon. If hostComponent.getStyle(“emphasis”) = true, show emphasis?
March 18th, 2010 at 1:24 pm
Shawn,
have you tried to do what you’re suggesting? Try setting emphasized on a custom skinned spark button and watch what happens…
There’s also a lot of times you need to dynamically change the emphasized value of a button. Why should we have to go through the extra hassle of the style api when there’s a property already on the button to handle whether or not it’s emphasized. The skin should decide what the button looks like when it’s emphasized.
I think that’s the biggest complaint here, why add the extra complexity and code burden on the developers? There’s no clear disadvantage to adding this functionality to the base classes… Unless I’m just really missing something here
March 18th, 2010 at 2:58 pm
Well I’m sure nothing happens, since you need to implement it yourself. But the nice thing is, once you implement it you have it exactly the way you want.
With more power comes more responsibility.
Flex 4 is for the first time, truly flexible. You’re skin can look exactly how you want it, and you never have to bother with being constrained by what Adobe “thinks” you should be able to do.
No more pouring through component definitions, looking at what properties you’re “allowed” to change. You just create your own.
So, ya there’s definately a small amount of extra effort required. But the tradeoff is complete flexibility, and no need to go in and remove a whole bunch of stuff you don’t need.
The main disadvantage to adding to base class, would be that it breaks the seperation of roles. All visual elements should be defined in the skin, all functionality in the .as file. This is fundamental to the way Flex 4 works, and is a great improvement.
They could’ve added the support to the Base Skin file, but there’s a drawback there as well: Performance. Spark components are designed to be as lightweight as possible, you only add what you need. This way you’re not wasting CPU cycles on functionality you’ll never use.
March 18th, 2010 at 3:04 pm
Also, you don’t need to use the style API, that would just be the quick and dirty way of doing it.
In <1minute you could create a new class which extends button, and add a emphasized property.
You could then use this button throughout your project, and all future projects, with any number of skins attached to it (some may look COMPLETELY different than other, but they all share the same functionality), any of these skins can choose how they look when emphasized, and can target the property by saying 'hostComponent.emphasized'
March 18th, 2010 at 3:05 pm
“small amount of extra effort”
Funny choice of word… duplicating every code that doesn’t match your needs doesn’t sound a small effort to me… specially if I had to maintain that code.
March 18th, 2010 at 3:25 pm
http://en.wikipedia.org/wiki/Copy_and_paste_programming
“So, copy-and-paste is not necessarily bad in the short run, if you are copying good code. But it is always bad in the long run. “
March 18th, 2010 at 3:37 pm
“duplicating every code that doesn’t match your needs doesn’t sound a small effort to me…”
What are you even talking about?
I suggest you get your hands dirty, and start making some real apps with Flex 4, then come back actually have an idea what you’re talking about…
March 18th, 2010 at 3:39 pm
Not to mention, how many HOURS have you wasted battling flex components to move things by 1px, or shoehorn in functionality that doesn’t exist? How many hours have you spent pouring over documentation, for each specific component’s visual properties?
Consider that, by and large, you’ll never have to do this again. Once you learn basic SVG techniques, they will apply to all skins and all components.
March 18th, 2010 at 3:39 pm
The old IconButton problem…. You need to DUPLICATE the skin…. or did someone fixed that and made skin reusable?
VELO
March 18th, 2010 at 3:55 pm
Skins are not classes. They do not have discrete functions and properties, therefor inheritence would be much messier than it is with Classes.
If you’re going to complain, offer a solution… how would YOU construct a skin so it’s actually extendable?
I’ve given it some though, and the only ways I can see are pretty ugly…
March 18th, 2010 at 3:58 pm
The spark button already has an emphasized property on it, that’s what I meant by give it a shot
It reskins the button completely when that property is set to true. I have found a work around by overriding the s|Button.emphasized style and setting the skin to EmphasizedButtonSkin, but it just doesn’t feel like it fits in with the new skinning model. I honestly expected an emphasized state on the skin… I would love to have a nice smooth AnimateColor transition between emphasized and non-emphasized states, right now that’s not possible. On the flip side I would hate to see a ton of state bloat to support this, maybe Adobe will come up with something that would allow more flexibility in communication between skin and component.
Like I stated before, what’s the different between a label and an icon? They’re both the same purpose, and both related to the “visual” side of the component. An icon is really nothing more than a graphical representation of the label in 90% of cases. It’s obvious things like this are frustrating developers. A quick Google search on spark icon button will give an idea of how much trouble people are having. Honestly it’s little things like this that can have enough impact on whether or not developers look at other platforms. I mean try telling your boss when he wants an icon on a button that will be a couple of hours of work because the platform doesn’t natively support that. It’s a little like ‘huh’… really? The little things kill…
I guess it just feels like Flex has this great move towards skinning and complete control over look and feel, but it sucks to have to go the extra mile to get something that was so easily accomplishable in Flex 3, and quite honestly is a UX standard. I can’t argue too much with the goal of a lightweight, performant controls though, that’s something we’ve been asking for as well. Like the original post states though, if something like this is being asked for by 95% of the community and it ends up having 100 different implementations, that’s just bad for the platform overall. I’m just hoping Adobe is listening…
March 18th, 2010 at 4:00 pm
“The old IconButton problem…. You need to DUPLICATE the skin…. or did someone fixed that and made skin reusable?
VELO
”
VELO,
The only easy way I’ve found to do this so far is a extending the spark button and build a new optional icon skin part. This will allow you to change icons without creating new skins. You just have to use the new component.
import spark.components.Button;
import spark.primitives.BitmapImage;
public class IconButton extends Button {
public function IconButton() {
super();
}
private var _icon:Class;
[Bindable]
public function get icon():Class {
return _icon;
}
public function set icon(val:Class) : void {
_icon = val;
if (iconElement != null)
iconElement.source = _icon;
}
[SkinPart(required="false")]
public var iconElement:BitmapImage;
override protected function partAdded(partName:String, instance:Object) : void {
super.partAdded(partName, instance);
if (icon != null && instance == iconElement)
iconElement.source = icon;
}
}
March 18th, 2010 at 4:04 pm
”
Not to mention, how many HOURS have you wasted battling flex components to move things by 1px, or shoehorn in functionality that doesn’t exist? How many hours have you spent pouring over documentation, for each specific component’s visual properties?
Consider that, by and large, you’ll never have to do this again. Once you learn basic SVG techniques, they will apply to all skins and all components.”
I’ll agree 100% here. What used to take me a good week to skin an app can now be done in much less than half the time, with much much better results. I just don’t want to see my time shifted from complex things becoming easier to easy things becoming complex… There needs to be a good balance between the two and I think that will evolve over time as people keep yelling “where the hell is my icon!”
March 18th, 2010 at 4:07 pm
this photoshop layer that someone said earlier here seems a good start.
If I could create an skin class like this:
<s:ButtonSkin ….
That does recall me a bit on 2.x and 3.x states
Would be also nice if the skins could be pass as object….
instead of:
do this:
March 18th, 2010 at 4:10 pm
@Merk
Yeah, that is the “best” way right now
But then I need a button with 2 icons, with 3, w/o background….
And buttons are as simple as labels… imagine more complex components like datagrids or trees…
March 18th, 2010 at 5:08 pm
“But then I need a button with 2 icons, with 3, w/o background….”
In all fairness, I do believe this situation is easier to do in Flex 4 than Flex 3… Trying to get a button to display 2 or 3 icons in Flex 3… ugh.
March 18th, 2010 at 5:20 pm
That is something I agree….
Is much easier to do… but you end with code duplication. Then you have to fix something on a button… the problem is you have 10 more clones around there, which you have no idea existed, and you obvious didn’t touch any of this extra class… then QA go check what you did and you fixed only one place, but kept it broken all over….
Was a pain to put a close button on TabNavigator, but once it was there I knew I only have to check it. Not a bunch of classes…
Obviously Flex 4 is much better on the designer perspective which obviously I’m not.
VELO
March 18th, 2010 at 5:48 pm
I have no idea how the old Flex was better for developers.
So, no control at all, and 80% private function/properties which can’t be overridden… is somehow preferable to a system which gives you complete flexibility and control?
To me it’s not even close, the benefits faroutweigh the negatives.
March 18th, 2010 at 6:05 pm
I don’t really understand the big issue with “code duplication”.
Unless you’re referring to duplication between projects??
Skins are flexible/powerful enough (with the ability to read properties and styles from the hostComponent), that you should never need to create more than a couple similar types in any given project…
March 18th, 2010 at 6:21 pm
“To me it’s not even close, the benefits faroutweigh the negatives.”
I completely agree, we’re all just voicing some of the concern we see from a development perspective. From a design perspective things are 100x better. I don’t think anyone here will deny this framework is much more robust for control and design. I also don’t think anyone here is saying that Flex 3 is better, just having a hard time understanding the new component model. There are things that will most likely shake out as more of the community starts embracing the new model and finding its strengths and weaknesses. If we don’t voice it though, there’s nothing Adobe can do to help us.
Almost feels like the jump from 1.0 to 2.0. There was challenge, but much more benefit. Learning from frameworks like degrafa and competition from silverlight are moving the Flash platform in the right direction for sure…
note on your code duplication… I’m not sure from your conversations whether your more design oriented or development oriented, but OOP design lives and breathes getting rid of code duplication with inheritance and composition… It’s one of the top goals of OOP design. Code duplication leads to buggy & inconsistent spaghetti code. The design world doesn’t really concern themselves too much with duplication of art. It’s just a different way of thinking. I imagine it’s as hard to ask a designer to componentize art as it is to ask an OOP programmer to copy and paste (technical challenges aside)… Both would say “huh, why the hell would I do that…?” For skins this really isn’t a huge problem, since there’s nothing that can really break in a skin, but for developer efficiency, especially shops where the design and developer are one, efficiency is key to meeting business goals and Adobe should be doing everything it can to make sure that doesn’t suffer.
March 18th, 2010 at 6:54 pm
I’m a develop, not a designer, and I’ve been using OOP for nearly 10 years. And I support inheritence as a general concept with skins.
What I’m saying though, is this issue is really a red herring.
Code duplication should not be an issue within a single project, as long as you architect your skins in a smart way.
Across projects, there could be a ton of code duplication, but inheritence would not help you here anyways…unless you’re working off of one conslidated global classpath, which in my shop is a major nono, each project needs it’s codebase to be standalone and portable.
So again, please give me a use case. I would love to hear an explanation of why you would ever need “10 buttonSkins” as Velo infers…
March 18th, 2010 at 6:56 pm
Also, I would argue the old flex was better for non-developers, as everything was premade, and you could just set some styles, some properties, and voila you have a custom component.
In Flex4, it actually requires a developer to add the functionality in.
I don’t think it’s better for ‘designers’ at all, it’s better for ‘designs’ though, because it’s about 100% more flexible…
March 19th, 2010 at 9:14 pm
[...] Flex 4 skinning ignores developer needs [...]
August 13th, 2010 at 12:29 pm
Adobe Fail again…
I was a huge Flex fan on Flex 3.
Expected a lot on 4, but adobe only disappoints…
Flex 3 was so simple to skin. Really HTML like, using fireworks, images, css, piece of cake.
It was friendly….
Now the spark “innovation” is unnecessarily complex.
Skinning is another Flex 4 fail.
Why haven’t they kept the MX way of skinning for Spark and add whatever the complex stuff they like??
September 21st, 2010 at 4:28 am
Hi there
For a designer-developer workflow for skinning spark (and custom) components I’m thinking of the following. Any comments thoughts on whether this is a good / bad approach very welcome!!
Basically:
- create custom skin-classes that dynamically references a skin resource via the getStyle() property
To do this:
1. Identify the core spark components to be skinned. There shouldn’t be that many – Button, Scrollbars, ComboBoxes …
2. Get one of the theme samples in the Flash Builder application folder (eg. Arcade). Use these to base your spark skins on.
3. Copy the skin file (Button for example) … and change the reference of hardcoded embedded assets to a style declaration, eg. getStyle(“upSkin”)
I haven’t gone through this process yet, but I imagine I would have a .css file that maps the spark (and other custom) components to the skin-classes and a 2nd .css (for sanity a separate file) that contains the dynamic skins (supporting the skinning workflow from Flex 3)
What does everyone think? Can anyone see any potential problems with this method?
Cheers
Tracy
September 21st, 2010 at 4:38 am
Also, I’m trying to find out which skin assets are the most optimal – i.e are smaller and take less processing to be drawn on the screen.
From much reading I have concluded there are the following skin-asset options:
1. MXML graphics (hand-coded FXG in Flash Builder)
- good if you only have a text editor to create graphics
- vector graphics, so scale optimally
- large & verbose, so not as optimal
2. FXG graphic elements exported from a graphics editing program (eg. Photoshop)
- vector graphics, scale optimally, better performance over (1.)
3. Embedded .swf / .png … assets
Here is my post on the Adobe discussion forum. Still no reply from them, but I would love to get a discussion going around this & the skinning workflow to find out more about the trade-offs, limitations and best practices.
http://forums.adobe.com/thread/696128?tstart=30