Related
It's been a couple of years since I've done any Java work, my last efforts were using Swing. I'm poking around with a cross-platform client app that will interact with a Rails web service. JavaFX is one of the options I'm considering, but I'm concerned at the out-of-the-box aesthetic. Does JavaFX have a native look and feel option for the JavaFX controls (not Swing)?
I'm getting the impression that if I want to build a line of business application in Java, I should probably stick with Swing which is a shame since I like some of the features of JavaFX like binding, a terse syntax, and easy support for REST client programming.
I haven't see that. At best, you can use the extensive support of CSS styling we got with 1.3 to mimic native look and feel, but that's a big job! Not even sure how to deal with various themes we got on modern systems...
I suppose the point of RIAs is to bring their own look or to be flexible enough to allow to do your own shinny look, not to look like a random bland application on your platform... :-)
(Now, if I like skinnable applications, I also appreciate GUI frameworks using native controls or looking as such, like Qt (vs. GTK+ for example), precisely to provide good old "bland" applications not breaking user experience.)
JavaFX 2.0 has only one Look by default that is called "Caspian".
With Java 8 a second one was introduced, called "Modena".
Both are cross-platform Look&Feels.
See announcement of Modena, with screenshots.
At the moment some developers create native Styles for JavaFX as OpenSource projects. You can find an overview here:
http://www.guigarage.com/2013/01/this-is-for-the-native-ones/
If you are interested in the Mac OS L&F (AquaFX) for JavaFX, here are some posts with previews:
http://www.guigarage.com/category/aquafx/
Native look and feel is not supported by Oracle in the default JavaFX 2.x distribution.
A proof of concept on button styles by one of the JavaFX developers demonstrates that JavaFX is flexible enough to generate widgets that look like native widgets.
For OS X, you can try the third party AquaFX style for JavaFX, which makes JavaFX applications look like native OS X applications. AquaFX appears quite complete and comprehensive to me.
There have been other 3rd party projects which partially create native look and feels for other platforms, but their coverage is currently nowhere near comprehensive.
Some third party projects (all of which seem currently experimental and incomplete) are:
JMetro in jfx-styles
javafx-native-themes (JavaFX look and feels for: default swing, iOS, windows 7...)
you could definitely embed some css in your application to make the javafx components look more like the standard swing look. With scene builder its actually really easy to get all your tags setup correctly.
Check this out
http://docs.oracle.com/javafx/2/css_tutorial/jfxpub-css_tutorial.htm
Interesting thing is in javaFx is, you can give the rich look and feel to native application also.You can apply css to the javaFx components. Not only that you can embed the HTML Css and pages in JAVAFX application.Which i can feel great revolution in terms of UI building for Standalone applications.
Which would be more comprehensive for game development?
It depends.
Are you working by yourself or in a
team ?
Are you more a designer or a
developer ?
What's your level of comfort with
actionscript ?
If you're just starting with actionscript, you're somewhat
comfortable with the Flash IDE and you want to make fun indy
games for people to bash buttons and destroy mice, go with Flash.
The look will weigh more at this stage and interaction will be simpler.
Never the less you can create some addictive games with very simple interaction.
If you're more of a developer, I would suggest using Flash to generate your assets
(characters, animations, etc.), or have your designer do that for you,
but use a proper IDE to write your code.
As Flemish Bee Cycle mentioned, you can try Flex Builder or if you're on a PC,
Flash Develop is an awesome IDE( free, lightweight, fast )
You could try to write you're own mini game engine, or use an existing one, like the PushButtonEngine.
As far as I can see SWF is the dominant output for online games:
Miniclip
Kongregate
Nonoba
MochiMedia
FlashGameLicense
HTH
Use Flash for games. Games involve more animations (suits flash) than data driven user interface controls (suits flex).
Since HTML5 is the future, you might also want to check out Processing.js, if you don't mind considering alternatives to Flash.
Processing.js uses Javascript to draw
shapes and manipulate images on the
HTML5 Canvas element. The code is
light-weight, simple to learn and
makes an ideal tool for visualizing
data, creating user-interfaces and
developing web-based games.
HTML5 aims to reduce the need for proprietary plug-in-based technologies such as Adobe Flash, Microsoft Silverlight, and Sun JavaFX. (Wikipedia: HTML5)
In this case, you would have a vast choice of Editors or IDEs.
Do the code in Flash Builder, as it is a better tool for coding; and the graphic resources in Flash.
flash is aimed at designers.
flex is aimed at programmers
so it depends on your function in the game team.
The editor in Flash is terrible. Flex Builder is based off of Eclipse, so if you're used to / or like Eclipse, you'll probably like Flex Builder. But I'd say neither, and give http://www.flashdevelop.org a try.
you can use flex as there are many inbuilt UIComponents for Tabs and mobile phones.It reduces overhead of many design like like touch scroller.It is better for game development in terms of programmer
Has anyone built application to compare the performances of them?
(performances like speed, different between GUI etc.)
If no, Can anyone recommend me which function (in each of them) should I use to compare them?
Thanks
Try the Bubblemark animation test: http://bubblemark.com/
It runs with multiple versions of Silverlight, JavaFX, Flash/Flex, and even includes DHTML and some other frameworks.
I used all three.
From my experience I can tell that Flash output (Flex produces) is fastest. Silverlight is also OK. JavaFX is again slow like applets.
The best gui is provided by Flex. But this is about taste. JavaFx also has great features about ui. But it is really slow. Noone would want to wait for it.
If you use Flex the output will be flash so nearly everyone will see it. But some may not see silverlight since they don't install the plugin or some does not have jre so they can't see the javafx.
And also there is "Open Laszlo" It is opensource and may output flash or dhtml. Does good job.
You should try RIABench: http://www.timo-ernst.net/riabench-start/
It's much more sophisticated than Bubblemark because it's split into multiple tests and is based on true scientific methods of performance testing.
I've tried looking everywhere for a concise list of the advantages and disadvantages of using Flex vs. Flash.
Coming from a programming background, I absolutely love Flex. It's easy to pick up, and since it can use flash classes, why would I want to use Flash without flex?
Flex:
Pros:
good for RIA development
provides many user-input options out of the box
Build in lay-outing system
the MXML is easier for non-programmers
You can quickly combine components to create small applications
components can provide an advantage in large-scale projects because of their modular
nature.
can be developed using linux
has a nice component lifecycle for validation, etc.
Cons:
increases the size of your .swf
Customizing the look of components can take a lot longer than anticipated, depending on the visual style you're looking for
when you find out you need a custom component that doesn't exist, you might need to go back to Flash to do the real programming work and packaging of the component
The "flexibility" of Flex means you will be reading a lot of documentation
Bugs in the Flex framework
You eventually will need to compromise with the architecture of the Flex framework
Flash
Pros:
good for making movies/animations
Timeline can be easier for designers/animators to conceptualize
when working from scratch, provides a great deal of control.
easier for someone with a programming background
You can program whatever you like; no compromises with existing frameworks
Cons:
only provides basic user input (text box) out of the box.
timeline can be daunting for programmers (although you can quite safely ignore it)
Development of certain types of applications will be slower than with Flex
can't be developed using linux
user input validation must all be handled in the code. No built-in validation.
need to implement your own lay-outing system
Please correct me if I missed anything said so far.
Flash and Flex both use the same underlying rendering engine, just with different front-ends. Flash is better suited for making movies and animations. Flex is better for application development.
From a programmer's viewpoint, the big difference between Flash and Flex is not so much which IDE/application you use for programming, but whether you program in ActionScript (AS) only, or use the Flex framework and MXML to program your applications.
I would say pure ActionScript is better for programming (whether you use Flash IDE or Flex IDE is not that relevant), and MXML is better for non-programmers to combine the components programmed in AS.
I would add to your list these pros/cons:
Flex:
Pros:
Easier for non-programmers to get into application development
You can quickly combine components to create small applications
Components can provide an advantage in large-scale projects
Cons:
Customizing the look of components can take a lot longer than anticipated, depending on the visual style you're looking for
When you find out you need a custom component that doesn't exist, you might need to go back to Flash to do the real programming work and packaging of the component
The "flexibility" of Flex means you will be reading a lot of documentation
Bugs in the Flex framework
You eventually will need to compromise with the architecture of the Flex framework
Flash (or Flex IDE in ActionScript project mode):
Pros:
Easier for someone with a programming background ;)
You can program whatever you like; no compromises with existing frameworks
Cons:
Timeline can be daunting for programmers (although you can quite safely ignore it)
Development of certain types of applications will be slower than with Flex
In short: pick the right tool for the right task.
Flex is a library of code written in ActionScript3, so it adds lots of capabilities and standard-library-like stuff to Flash. The downside is that it a is a huges amount code that gets included into your application. If you use any Flex at all in your app, the download size of the SWF goes up by 100's of K.
If your application has any kind of user interface widgets, then you almost have to use Flex as Flash itself only has the most basic things like text boxes. Flex has a whole XML GUI with layouts, data binding and XML setup etc.
Doing that in flash, you end up having to write from scratch things like list boxes...
In my opinion, the most important feature of the Flex framework is the component lifecycle, which provides a really elegant model for validation/invalidation of properties, component size, and hierarchical rendering.
The benefit to developers is that it creates discrete application phases for business logic and rendering, avoiding expensive geometry & rendering code until the last possible moment before drawing a frame.
Here's a really good presentation, explaining how it works:
http://tv.adobe.com/#vi+f15384v1002
The model is so well-designed that the component lifecycle remains almost entirely invisible during the majority of Flex development, when you're using the framework default components and containers. You only need to learn the inner-workings when you start developing your own components.
Developing in the Flash environment, or in pure Actionscript, you don't get any of that. Anyone developing pure AS3 applications either needs to code very carefully to separate business logic from rendering, or will suffer severely decreased performance.
[...] why would I want to use Flash without flex?
Flex is a new product, whereas Flash existed from the Macromedia days. Designer, animators and most anybody who is not brought up on a staple diet of programming education will probably find Flash easier to master than most other such solutions.
Target is different.
Flex is more dedicated for programmer while Flash is more friendly to Artist / web designer.
Flash is the IDE used (generally) to create animations and things that work well on a timeline.
Flex works better for creating internet applications which have interactions more akin to a desktop.
Why use Flash? Well, if you need to do something more specifically attached to a timeline, of course!
I see Flex as more of a solution for doing RIA applications where you need to develop application based solutions. There's quite a lot you get right out of the box with using Flex but it also comes at a price in terms of file size, granularity, etc.
If on the other hand you are working on a totally custom solution such as a game then perhaps Flash is the way to go because you can start fresh with a blank canvas. Many people still use Flash because they don't need all the app based bells and whistles of the Flex platform.
I like the freedom of Flash, and its really simple to embed assets in Flash, a little more confusing to do in Flex.
One thing that I love about flex is the ability to make a fluid application with minimal effort. Which would take forever in Flash.
Anything you can do in flex you can do in flash, just may take a lot longer to do. You can't do everything in flex that you can do in flash though.
Flex takes care of all the UI programming for you and lets you focus on the business logic, with flash you will spend a majority of time programming the UI.
You can develop Flex applications under Linux easily but with Flash you simply can't.
Another solution that was not suggested at here, will be to use them both. You can add flex components to flash movie clips using ContainerMovieClip. And you can add flash movie clips to flex components using SpriteVisualElement. Another thing that wasn't mentioned was lay-outing your application. It will be flex pros against flash disadvantage, because you got build in flex lay-outing system. But again when you are using them both, you can layout your movie clips with flex lay-outing system.
Also flex become Apache top-level project. And it become more and more excepted by the community now.
Flash and Flex are 2 complete different things, one is a design tool with support for action script, the other one is a framework that also has action script but is maily built around MXML which is a XML based UI definition "Language".
I just got started using Adobe Flex SDK. I was very excited because it's the first time I've found a good, free way to create Flash applications. But then I noticed something: Flex doesn't seem to be much about making animations or designs. It seems more like an application to build forms and menus and the like... which I can already do in (D)HTML.
What features does Flex have that make it better than HTML in some cases?
Also, are there any techniques/software programs that would allow me to add the flash/design components that I mentioned earlier?
Thanks!
Flex, like Silverlight, is marketed for the creation of something called RIA = rich internet application. The idea being that (D)HTML isn't really well-suited to create large-scale, well-responding applications on the web. I'm not sure whether this is really (still) true but historically, it fits.
Flex and Silverlight attempt to correct this by providing two things: a different, extensible technology along with a large library and an adapted toolset for the creation of applications. The disadvantage in both cases is the dependency from further (non-free, non-standard) components. The advantage is a potentially much more productive workflow and better performance.
Flex has a cohesive component model, and the basic building blocks were designed to support applications. HTML, on the other hand was designed for displaying text, and the DOM is a sorry excuse for a component model -- and it was most definitely not designed with applications in mind.
There is a plethora of JavaScript libraries that try to implement a workable platform on top of the DOM, and to even out the differences between browsers. While these work fine in many situations most of them don't come near the richness of the Flex component model, or even the more basic Flash API:s.
However impressing libraries like Dojo, YUI and jQuery are, they are limited by the platform, and it is limited indeed. Flex has all the benefits of the Flash Player platform, like vector graphics, remote objects, video support, cross-domain loading, sockets, font embedding, etc. but also a very good component model, data binding and skinning capabilities, to name but a few. If you're writing rich internet applications Flex is as rich as it gets.
Flex is a layer on top of Flash, and was designed from the ground up for building applications. As such it has very powerful capabilities when it comes to interface construction and data manipulation. If you are interested in movies and animation sticking with Flash is more appropriate.
The advantages of Flex over DHTML (AJAX) include:
- Faster prototyping
- Better cross-browser support
- Better support for data management
- More "serious"
Disadvantages include:
- Stuck with a single vendor
- Requires the Flash plugin
You can do audio and video in Flex/Flash vs DHTML.
Some more details and comparisons are in this The Top 10 Things You Should Know About Flex article.
If you're interested in leveraging the graphics potential of Flex, why not go check out Degrafa which is an open source graphing and general graphics api. It's pretty cool, very well documented, and quote - "Adobe has asked if the Degrafa team would consider helping directly contribute to the Flex Graphics open source effort." - which they are!
It's not just all about charts and graphs.
Just a quick clarification - to be clear, Flex is built on top of Flash. What that means is that anything you can do in Flash, you can do in Flex when it comes to programming. Flex Builder does not come with any tools that let you make animations with timelines or vector art or anything like that, but all of those elements are still usable provided you have the tools to make them elsewhere.
Flex is really about bridging Actionscript 3 as a language and Flash as a runtime into an environment where application programmers can feel truly comfortable with it.
As stated above, "Better cross-browser support." That's probably the biggest factor right now for me.
A few more...
It's a lot easier to get "pixel perfect" designs in place.
It's really easy to integrate Flash content into Flex. Which makes it easier to work with designers.
Actionscript is better than Javascript (go ahead and flame me!)
There aren't any really good alternatives to buying the Flash product for making timeline based animations.
The bad sides:
Sometimes, html is just plain easier / more powerful
Make sure to pick the right tool for the right job. Sometimes DHTML, sometimes Flex, sometimes Flash, and many times a combination of those.
What you're talking about is Flash versus Javascript. Flex is Flash, DHTML is Javascript.
Flex allows for rapid prototyping, an alternate IDE for building Flash .swf s, and fits nicely into Air - Javascript only runs in browsers, includes less animation support by default (although there are plenty of well-established libraries that provide that functionality) and doesn't require a plugin to work.
Also with Flex you don't have to deal with JSON, XMLHttpRequest, compatibility issues and the likes... Everything works like magic.
Unless you need a lot of animations, HTML will feel more lightweight than Flex.
No "loading" screen.
On OS X performance of Flex is abysmal. Even DHTML animations are faster! (see GUIMark).
HTML has wider compatibility than Flex. It may not be as easy as writing for single implementation from single vendor, but OTOH you're not limited to that single implementation:
No problems with iPhone or 64-bit Linux.
With graceful degradation basic functionality might even be accessible from Lynx or BlackBerry browser.
HTML is better integrated with the browser and OS:
Form elements can have native look'n'feel.
Text has preferred type of anti-aliasing, no problems with ClearType.
Keyboard shortcuts, context menus and text selection work as expected.
Browser extensions can improve DHTML apps, but Flex is impenetrable.
Accessibility tools have better support for HTML.