I think I'm overusing the Flex states model. The way the Spark architecture teaches it, states should mainly be used for changing the visual appearance of a certain component. However, being overly excited about the simplicity of using Flex states, and also willing to reuse existing object instances at runtime, I made my components really "thick", injecting different view models, as well as other stuff, based on a certain state change. This created a bunch of problems with synchronization, so I decided to subclass and specialize instead of relying on states that much.
In general, as a rule of thumb, where should the boundary between states and subclassing be put?
Well, from what I understand, you have a huge view that you now want to use inheritance to split it up? Won't that still make your component heavy and hard to manage?
The better solution here is to use composition, not inheritance. Create new, self-managing and small components that come as a whole into a larger one. There really shouldn't be a 'boundary between states and subclassing' because they do 2 completely different things. One is for view based changes while the other is to add functionality.
I think you're just really mixing up your OOP concepts and should really stop what you're doing and go over the theory a bit before continuing. If you continue on your current path, you'll end up where you're heading; spaghetti code.
Related
I am making a game. And this time trying to implement menu (-->tutorial) -> game-> scoreboard -> game over
screens.
These screens themselves are quite different in terms of structure. So i am not sure if states is a 100% correct approach here (as I understand states are good for similar layouts) From the other hand many of them has back button to return to previous state, e.g. in tutorial I will have start game and back to menu buttons, etc.
I wonder if there is a clear solution for a problem like this? Maybe there is a special library to handle such cases?
State machines (not only for visual states) are a good solution to implement the behavior of encapsulated components, such as buttons or - in your case - menu items, perhaps even some of your game logic. They can be described independently for each component, and they help to keep your interactions organized, and thus to prevent errors.
State machines are difficult to maintain, however, when you are looking at an entire application: The interactions are usually multi-dimensional (i.e. not only one component is involved, but many, and at different levels in the hierarchy), and when all the different players are taken into account, the resulting state machine will soon become very complex.
From my experience, it is best to use an event-driven approach combined with Model-View-Controller architecture for your application logic, and use state machines at the component level. I would advise to look at some of the existing Model-View-Controller frameworks for this, most notably RobotLegs, PureMVC and Parsley (though to me, Parsley seems a little less complete than the other two).
Every time I start a project with some graphical toolkit, one of the first conflicts happen with the decision of how to deal with the visual design and the widget layout: A graphical tool or handcoding?
This is a quite tricky/subjective question because most people will decide based on personal preference. It also depends greatly on the quality of the graphical tool. In this case I would like to focus just on the latest version of the QT library. I do not intend to discuss which method is better. I am convinced that the best answer is: depends on the project.
What I want is a reference to a good non biased article, based on experience after several projects. The article should just describe the tradeoffs of both choices
I started with doing everything hand-coded, and of late have been switching to using Qt Designer for most forms. Here are some benefits for each position:
Using Qt Designer
The biggest time saver for me is managing complex layouts; it saves a lot of tedious coding. Simply (very roughly) arrange your widgets, select them, right-click, and put them in the correct type of layout. Especially as layouts become nested, this is so much easier.
It tends to keep your implementation files cleaner instead of filling them with all the boilerplate layout code. I'm type-A, so I like that.
If you are translating your application, it is possible to send your translators the .ui files so they can see on your GUI where the text they are translating will be. (Assuming they are using Qt Linguist.)
Hand-coding
Control. If you have a layout where you need to instantiate / initialize the controls in a very particular order, or dynamically create the controls based on other criteria (database lookup, etc.), this is the easiest way.
If you have custom widgets, you can kind-of-sort-of use the Designer, adding the closest built-in QWidget from which your class derived and then "upgrading" it. But you won't see a preview of your widget unless you make it a designer plugin in a separate project, which is way too much work for most use cases.
If you have custom widgets that take parameters in their constructor beyond the optional QWidget parent, Designer can't handle it. You have no choice but to add that control manually.
Miscellaneous
I don't use the auto-connect SLOTS and SIGNALS feature (based on naming convention such as "on_my_button_clicked".) I have found that I almost invariably have to set up this connection at a determinate time, not whenever Qt does it for me.
For QWizard forms, I have found that I need to use a different UI file for each page. You can do it all in one, but it becomes very awkward to communicate between pages in any kind of custom way.
In summary, I start with Qt Designer and let it take me as far as it can, then hand-code it from there. That's one nice thing about what Qt Designer generates--it is just another class that becomes a member of your class, and you can access it and manipulate it as you need.
My answer is based on two years developing biochemistry applications using PyQt4 (Python bindings to Qt 4) and OpenGL. I have not done C++ Qt, because we only used C++ for performance-critical algorithms. That said, the PyQt4 API greatly resembles Qt4, so much here still applies.
Qt Designer
Good
Exploration. Discover what widgets are available, the names for those widgets, what properties you can set for each, etc.
Enforces separation of UI logic from application logic.
Bad
If you need to add or remove widgets at run-time, you have to have that logic in code. I think it's a bad idea to put your UI logic in two places.
Making changes to nested layouts. When a layout has no widgets in it, it collapses, and it can be really hard to drag and drop a widget in to the location you want.
Hand coding
Good
Fast if you are very familiar with Qt.
Best choice if you need to add or remove widgets at run-time.
Easier than Qt Designer if you have your own custom widgets.
With discipline, you can still separate UI layout from behavior. Just put your code to create and layout widgets in one place, and your code to set signals and slots in another place.
Bad
Slow if you are new to Qt.
Does not enforce separation of layout from behavior.
Tips
Don't just jump into creating your windows. Start by quickly sketching several possible designs, either on paper or using a tool like Balsamiq Mockups. Though you could do this in Qt Designer, I think it is too tempting to spend a lot of time trying to get your windows to look just right before you've even decided if it is the best design.
If you use Qt Designer for PyQt, you have the extra step of running pyuic4 to compile your *.ui files to Python source files. I found it easy to forget this step and scratch my head for a second why my changes didn't work.
If you code your UI by hand, I suggest putting your layout code in one place and your signals and slots in another place. Doing this makes it easier to change the way your widgets are arranged on a window without affecting any of your application logic. Or you can change some behavior without having to wade through all the layout code.
Enjoy Qt! Now that I am using Java Swing for work, I miss it.
I tend to layout dialogs using the designer but I do all the event handling stuff in the main code. I also do all the main windows, toolbars, menus in direct code.
The designer is just frustrating - a pity since decent drag and drop sizer based designers have been around for more than a decade
It depends on the number of different windows/panels you need for your application. If the number is small, use a graphical tool. It is much faster to get a few windows designed perfectly. If the number is large, the graphical tool can (and should) only be used for prototypes. You need to code the layout to be able to make application-wide changes at acceptable cost.
That includes creating a model of how the UI of the application works and dynamically adding and removing widgets at runtime. For an excellent example of such a model (in a different environment), take a look at the glamour model for creating object browsers.
I object to the suggestion that it is tricky/subjective (at least more than other development choices). It is easy to come up with criteria to decide on. Personal experience and preference are important for that, as they decide when the number of different windows should be considered small. The same goes for tool quality.
My personal opinion (just personal), all GUI based development distracts me too much, my imagination or my mind works very bad when i'm seeing gui objects, i prefer to hand-coding most the time because my imagination works better, you know, is like you were reading a book with no images... when i see nothing else than code its looks like i finish faster...
Second reason, i like c++ so much, so I see the good side of hand-coding, is that I keep my c++ practice no matter if I'm writing something redundant... Coding skill is improved when you only use text... Indeed, i could use nano or vim, but that is too far slow for debuging.
Hand-coding here ++vote
I use a combination of both:
I find for x,y coordinates, Designer is the way to go.
A lot of the other UI properties etc can be set in your code.
I think trying to do UI completely by hand-coding would be a very time consuming project. It's not as simple as setting up HTML tables.
Yes version 4 is bad, but people at work who have used version 3 said it was REALLY bad. Lots of crashing.
I, along with my fellow QTers, are truly hoping that version 5 will be an improvement.
I know this is an old question, but I hope this helps! One man's experience.
I'm faced with a business requirement that I believe may be solved by implementing CSS variables.
Basically, while the front-end developers on this project are in charge of CSS implementation, the designer wants to be able to introduce different "themes" for the site.
By swapping one theme for another, a range of changes (such as font-size, font color, border width, etc) can be made without having to change too much code.
Currently we're trying to fit this requirement by splitting up the styling of components into different CSS files - e.g. one for layout, one for typography, one for colors, etc.
But I don't like this approach. It makes the CSS quite unmaintainable, and it's difficult to separate out all the CSS for one particular component, which is becoming a frequent requirement.
I'm hoping to instead introduce a standard set of "variables", which can be tied to a particular theme.
The CSS will be pre-processed and the variables will be swapped for the actual value depending on the theme used.
This will enable us developers to organize our code most effectively, while still keeping it flexible enough to be customized according to the designer's tastes.
Any thoughts on the pro's/con's of this?
The only disadvantage that I can think of is the added complexity of having to use or write a pre-processor, and appropriately manage the caching of the output in order not to have each request pass through the pre-processor.
You might also have some issues with syntax highlighting in editors when you use your new variable syntax, but that can probably could be solved.
Apart from that, I guess it should be all advantages.
You might be interested in checking out LESS:
#brand_color: #4D926F;
#header {
color: #brand_color;
}
h2 {
color: #brand_color;
}
Pre-processing a CSS seems like a good idea. The disadvantage I see is that, this additional abstraction will entail its own problems - bugs in the processing code might lead to an invalid or buggy CSS. Overtime things might become difficult to maintain.
You might want to have one fully working CSS without the variable, and then have another pre-processed CSS with the minimal required variable stuff, which overrides the original CSS.
I don't see any improvement over just having different css-files for the themes: You say you just add some variables to change fonts, colors and the like. What about borders, alignment and a lot of other stuff? Themes are not just 2-3 color variables. A theme for a bigger webpage can get pretty big and different themes for the same page might not only differ by a few colorcodes. I don't think it's a good idea. Let the front-end designers just create different css-files for the themes and load the css-files that belong to a theme.
A big disadvantage is certainly that you aren't writing CSS anymore. You are writing in a proprietary language, that compiles to CSS. Inventing your own programming language is on page one of the things-that-are-a-bad-idea-for-business book. If you are doing this as an experiment or for a personal project, then go ahead, but otherwise I'd say that you're asking for trouble.
A concrete problem I could foresee is that developers might have editors/IDE's that knows how to deal with CSS, but don't know how to deal with your dialect of CSS. That could restrict said developers quite a bit.
But really - The point isn't listing up pros and cons. The point is that you're moving into uncharted territory, and that's - out of principle - a bad idea, unless it's your core business.
Edit:
I'd just like to moderate my answer a bit. From a technical perspective, it may well be a good idea - Depending on how well you control your environment, how able you are to retrace your steps and a lot more. This is essentially a type of external-DSL, which can be a very powerful instrument. I don't think I would apply it here though, since you're targeting (frontend) developers, and I think external-DSL's are better used at administrators/non-developers. But it could be used successfully.
My main concern is that you're only approaching this from a technical point of view, which is a common fallacy for us developers. From a business-perspective (assuming you are a business), it's probably a really bad idea. That's what I was trying to voice.
Knowledge has no limits but still in your opions, what are the basic requirements for an individual, where he can call himself a flex developer. To make it a bit concrete lets say after having a 2-3 years experience.
In my perspective it should be something like below. It is a very (very) rough idea and please let me know your views and suggestions on this.
BASIC:
(1) Knowldge about basic GUI components like tab, vbox, etc. Their properties and the ability to decide which component suits better in a condition.
(2) Knowledge to use services like HTTP, wsdl, remote objects, etc.
(3) knowledge about basic event handling mechanisms and bindings.
(4) Knowledge about basic Object Oriented principles.
EXCITING:
(1) Knowledge about advanced GUI components.
(2) Knowledge about architectures like cairngorm, live cycle data services, etc.
(3) Knowledge to write custom components and renderes and using advanced properties of components.
(4) Knowledge about Design principles.
Also, are there some FREE online tests/certifications etc where one can test his/her flex/as skills ?
Thanks in advance.
Someone who has been coding with Flex daily for 2-3 years should have a pretty deep knowledge of the framework. They shouldn't just know how to use the framework but also how the framework itself works and how to extend it. If they don't, you probably don't want to hire them. :)
Advanced Flex developers should understand how UIComponent works and be able to explain the purpose of all these methods:
initialize
stylesInitialized
createChildren
invalidateProperties / commitProperties
invalidateSize / measure
invaldiateDisplayList / updateDisplayList
setActualSize
getExplicitOrMeasuredWidth/Height
validateNow
getStyle / setStyle / clearStyle
They should know what the Flex "invalidation model" is and how it affects the "invalidate" methods and their counterparts. They should also be able to discuss a few of these topics:
How does container layout work? How does a Box container decide how to position and size its children?
How do Lists display their data and what makes item renderers special? How is a List different from a Repeater?
It's impossible to cover all of the things that a Flex dev should know in a short post here but having a deep understanding of UIComponent, its lifecycle and the invalidation model is super important.
I've just found out about View States in Flex (v3.0), but I am not really sure how widely this is used in real-world applications. Is it a good practice to use it? Are there any pitfalls such as maintainability for instance?
I also used states in an enterprise-level app. But very lightly.
States can be really useful to clean up your code for some cases. There is a performance down side, if a state adds a child, the child will not be removed from the list until you go back to that state and and add a new child.
I think states can be useful if you need to enable/disable make visible/invisible a bunch of components back and forth (depending on a state). This is the ideal use-case of states in Flex.
I've used states heavily and find them a far more elegant solution that lots of conditional code. Indeed, I initially avoided them for some of the reasons given above, but after the app became very complex, with multiple variant "states" I realized that I was fighting the framework.
Frankly, I'd make the same observation about bindings. If you don't understand some of the subtleties, they can be your undoing, it's true. However, writing your own code to achieve the same thing seems like duplication of effort. Take a look at the generated code sometime and also read some of the good deep-dives on bindings out there.
I started using states in my app (enterprise-level application) in various places, and have since refactored them all out. Most of my MXML has been replaced by pure AS3 components, and I'm skeptical of binding and the flex component lifecycle. There's a lot of convenience tricks advertised in the Flex framework that begin to feel cumbersome and slow once you really start using them.
Like anything, your own mileage will vary. They might be useful if you can avoid the "everything is a nail" syndrome. Maybe I couldn't.