How good is a Flex app in handling large amount of data (say, for a reporting kind of application)
Are there any memory management issues that need to be kept in mind while developing for such an app
Are there any issues in running a Flex app on a Mac?
1) great as long as you're not transferring huge amounts of data at one time using HTTPService. A good AMF remoting like amfPHP runs super fast.
2) Flash player runs on the clients machine, you would need to make sure you aren't using more memory than they have available.
3) If I remember right flash player is kind of weak on the mac, much slower than PCs but I haven't bench-marked them in a while
Flex can use a lot of memory in a poorly written application. A well written application will manage it's assets well and will not use more memory than needed. Flex is wonderful for a reporting application since you can do data manipulation on the client and do a lot of client side analysis and re-presentation of data.
Profiling. Flex Builder has a decent memory profiler so make sure you use it and don't leave dangling references around. Event handlers can keep references you don't realize if you don't clean them up. States can also cause problems if they're used inappropriately--to manage the state of the whole application for example instead of in a small scale within individual application components.
Flex is slower on the mac. This is largely due to the limited api provided by browsers on the mac. On PC the Flash Player has access to GPU acceleration and other low level API's which can make it faster. This is going to get better when Flash Player 10.1 is released since it will take advantage of new core animation api's available in Safari 4 on OSX 10.6.
Related
I am interested in Kotlin GUI system and I found Tornado FX.
I noticed that we can transform javaFX app as a webapp, so my question is : Can we do the same with Tornado FX and if we can, How should we do that?
Anything you can do with JavaFX, you can do with TornadoFX, as it is basically a higher level API on top of JavaFX.
JavaFX itself has no rendering capability that targets the web, but JPro has rather geniously made that possible by "rendering" the JavaFX UI as SVG directly to the browser using WebSockets.
Infact, TornadoFX has special support to make it easier to create JPro based apps.
Your starting point would be https://www.jpro.one/
The TornadoFX guide contains information about how to use JPro as well:
https://github.com/edvin/tornadofx-guide/blob/master/part2/Scopes.md#using-tornadofx-with-jpro
JPro is a commercial offering, starting av 99 EURO per month for one server with 8GB memory at the time of writing (2018-11-20). Each user would get their own instance of the application, though still running within the same JVM.
While this system works remarkably well, it is best suited for situations where there is low latency and preferably high bandwidth between the client and the server, as every event will be transferred over the WebSocket connection. It would typically be a bad choice for a public facing web page, but it is doable. In fact, http://jpro.one is actually a JavaFX app!
Disclaimer: I am not affiliated with JPro, I'm merely telling you about the (only) way to make JavaFX apps available through the browser.
I'm pretty familiar with using Adobe Flex & AS3, and compared with writing apps in JS/HTML I think it's very cool. However, since AIR is essentially a non-browser version of Flex with benefits like local storage, it seems to be competing as a cross-platform desktop application platform... and in that space it's much less mature than more established desktop technologies.
So what's the advantage of creating a desktop application using AIR compared to something like Java (or C++ using a cross-platform GUI library like wxWidgets)? Java's equally capable of communicating with the server for instance, I'm not quite sure what AIR adds when competing head-to-head in the desktop development world?
In my opinion the biggest advantage is productivity (if you are interested only on desktop)- it's much more faster to build a nice UI using Flex compared with Java Swing for example (try to build a transition in Swing). Also the new components from Flex4 allows to do component skinning much easier.
However (as written by Groky) you should take into account also the disadvantages. It would help if you write down what are the main features of your planned app and check how they are handled by various platforms. For example if multithreading is needed AIR is a bad choice.
AIR takes the goodness of Flash Platform cross-platform and as of 10.1 across many cutting edge mobile platforms as well not to mention that Google is actively working with Adobe on the mobile AIR for Android. That's the key perspective here and I think you don't doubt the fact that Google's open-source platform will be big. Android devices make the fastest growing chunk of mobile platforms already. Also, think of the upcoming Chrome OS. Is AIR going to have a role there? I bet it will.
IMHO AIR makes it a lot easier to deploy rich applications across platforms. Rich Applications as in terms of Flash Platform.
See what Wired has done with Adobe on ePublishing. That should answer this question well.
In my experience there is only one advantage:
Cross-platform
However there are a number of disadvantages:
No communication with native platform except by installing a separate server!
Native window handling is very primitive (no modal dialogs!)
Less mature (i.e. buggy)
Fair Question. Well to begin with AIR is not "a non-browser version of Flex" or "a non-browser version of Flash" ADOBE AIR is a run-time that hosts applications created in a variety of protocols including: HTML, JavaScript, AS3. If one is so inclined tools like ADOBE Alchemy will let users who prefer C++/ JAVA to compile code into SWCs and SWFs.
From a designer's perspective ADOBE FLASH, DREAM WEAVER, and FLASHBUILDER provide seamless desktop application development. While from a developers stand point the same code used for web based content becomes available creating desktop application with little to no recoding. This is all without mentioning the ability to leverage existing E-commerce and web based marketing APIs and SDKs; creating a dynamic intelligent experience for the end user on the desktop.
For me and my company, the main advantage is that it's the same code on our website as in our AIR app. This could be a Flex app or HTML/JS app, but you keep the same single codebase.
AIR 2.0 will address Groky's issues, with access to native applications, better window handling, and much less memory intensive, which led to lots of bugs in 1.0/1.5.
If you don't have a web app already, and you're not locked into AS/JS, then there's no real reason to go with AIR over Java/.Net/PxWidgets... unless you like the look of the latest Flex 4 components, which is quite nice.
I think it's because:
Cross platform
Very easy to develop - learning AS/JS/HTML is much easier than learning C++/Java/MFC. Most of the requirements are not that strict. I developed many tools with AIR/Flash for myself to save me hours of work. If I do that in C++, I will surely waste more.
I have been building enterprise software for the last 10 years. In this time we have seen enterprise applications move from client server to thin clients. We have also seen the move to hosted solutions, albeit under a few names (asp, SaaS, cloud computing). With all these changes the impetuous has been mainly from driven from the IT department not the end user. In the first rounds of these revolutions the user experience was reduced in the name of single point of management and reduced desktop footprint.
During this time there have been many attempts to give the user a rich experience while still satisfying the crotchety IT department. The first was by the industry leader Microsoft in the form of the ActiveX control. The guys from Sun then followed suit with the applet and then more recently java webstart. All of these solutions seemed to scratch the itch but never gained wide expectance by the more stringent IT departments.
Then flex came on the scene from Macromedia. What did they do differently? Is it sustainable? Does Microsoft’s emulation with Silverlight prove they have changed the rules of the game? Will Web programming be changed forever?
Adobe have succeeded because almost all users of the main browsers on the main platforms already have installed the only runtime component required for Flex; which is the Flash player. The Flash player has already demonstrated that it isn't a vector for Bad Stuff; it runs in its own sandbox in the browser, isolated from the hardware and the OS. So no new (and potentially dangerous) software is installed.
There exists a substantial developer community for Flash technology, and the addition of some new controls in Flash, and maturity in ActionScript for writing software, has tipped it over the threshold for being fully useful as a RUI.
(Activex is Windows-0nly; Anything in java is perceived as destabilizing and too heavy; and java hasn't managed to wangle its way into ubiquity, nor will it probably ever do so. So both generally get installed by edict, rather than user choice. This in spite of the fact that Adobe is probably the most disruptive source of unrequested "update-checkers" and other near-malware we deal with in our ecosystem.)
Microsoft started out with Silverlight pretty aggressively, requiring only the installation of the equivalent of the Flash runtime; but it's not ubiquitous even on Windows machines yet; penetration to other platforms is quite a way in the future; and MS hasn't proven to have the political smarts to appear harmless yet. But don't count it out. I think they've moved a step back by switching to .NET languages (with a limited CLR) for development; this seems to me to be the same strategy that has deoxygenated their WinCE strategy; but again we'll see. But at least they have made an obvious move away from language agnosticism to appearing to want to coerce developers into .NETland.
Web programming is changing forever one way or another; users will demand a better, more fine-grained UI; there's no perfect answer in sight yet, but at least there is competition for hearts and minds. I think the most encouraging signs come from Microsoft's strong move into platform-neutral stuff like MVC, Iron Stuff, and increasingly unpolluted code streams to the browser.
My take on Flex's success:
1- Adobe made the right move in opensourcing not only AIR, but Flex, the Flash VM, and the PDF standard now as well.
2- Flex's rich Flash heritage (it runs on any Flash enabled browser) means that the vast majority of browsers already support it and do not need to download a large plugin to access it.
3- Adobe embraced all the major server-side technologies and provided support for them so that a PHP. MS, or Java shop would all feel comfortable using Adobe's client side technology.
Previously, Flex was closed-source, expensive, and even relied on a server-side installation, which negated it's reach even though the Flash client was so widely available.
YouTube and the general ubiquity of
Flash video entrenched the Flash
player into over 95% of the browsers
that are accessing the public
Internet.
Incorporating Flex GUI for form
design with widgets and an extremely
well designed GUI SDK was a major
turning point for the Flash player.
Flex 2 and Flashplayer 9 were the
tipping points of when this
technology really jelled. Enterprise
developers began to quickly realize
that this technology was just the
right approach for doing their
applications. (At JavaOne in 2006,
Adobe Flex 2 was the most impressive
and pivatol technology that I saw
there.)
The Flash runtime has just enough
stuff to run RIA GUI well in a web
browser sandbox setting - Java
applets required the full JRE (about
16 MB). The Flash runtime was a much
leaner and smarter design for its
intended purpose. (Sun has only now
begun to remedy this for Java via
their JavaFX and redesigned JRE that
can download a few MB as sufficient
to run a web applet. They don't have
anything like YouTube Flash video to
drive their installations, though.)
Writing Flex RIA applications is a
very leveraged experience compared
to writing old-school web
HTML/JavaScript AJAX apps. Can
achieve a great deal more and have
less effort to accomplish such.
Adobe bolstered Flex with other
important pieces, such as BlazeDS
(and now they're cooperating with
SpringSource to make BlazeDS and
Spring-Framework a smoother
integration).
The single-thread GUI in combination
to async service calls (or
messaging), and ActionScript3
closures is great programming model:
Flex Async I/O vs Java and C#
Explicit Threading
Likewise, Adobe Flex has a great
implementation of properties,
events, and databinding.
A declarative language, ala MXML, is
indeed a better approach to
describing a form (what is
essentially the view in the MVC
pattern). It is more concise than
equivalent imperative ActionScript
code that would accomplish the same
thing, and thus clearer. The
hierarchical structure of MXML
script tends to naturally match well
to the panel/widget construction of
views as well.
With Flex RIA approach, the MVC
pattern can be implemented
completely on the client tier. Web
frameworks that implemented MVC in
the middle-tier - with the
presentation layer executing in the
remote client-tier, was a
fundamentally flawed approach to
MVC. MVC should be done right at the
tier that is directly user-facing.
(Once again, Adobe Flex does things
right architecturally.)
Despite that HTML/DOM/JavaScript is
considered the pervasive standard of
the Internet web, the Adobe Flash
player is actually a more ubiquitous
and consistent standard - spanning
different browsers and operating
system platforms. The
HTML/DOM/JavaScript standard is in
actuality a fragmented mess that
grows more fragmented everyday as
Google and Microsoft drive different
directions on things regarding the
web browser. Adobe Flash player ends
up being a wonderful end-run around
this dilemma. It's a great
programming experience for the
coders and has sufficient ubiquity
for the business suits.
Adobe is smartly well supporting the
major platforms of Windows, Mac OS
X, and Linux. They pay special
attention to the Linux platform.
This will pay off in the long term
as developers are already settling
on Linux to do their development
from, and it's used extensively for
servers hosting their middle-tier.
Adobe's recent 64-bit Flash player
for Linux is just a marvel. They
already have AIR 1.5 available on
Linux. They are doing a decent job
there of supporting the platform
that the developers care about.
I'm working on a project that currently has zero users but we would like to scale up to potentially hundreds. Currently we are running on a MySQL database with AMFPHP interacting with Flex. We used Flex because of its robust graphic features (important to this project) and because the initial developer (not me) already knew ActionScript. We are currently using AIR but might switch to web-based Flash at some point.
My questions are:
Is Flex a good tool for a project like this?
What are the main limitations of Flex that we might encounter?
What are other development platforms we might want to consider?
Thanks.
- Dave
Short answer, Yes. There are already many prime-time Apps using Flex as their UI development platform. If you go to the Adobe site they showcase quite a few.
Speaking personally, I chose Flex for two reasons, first was that, although you probably can do much of what Flex does in HTML or with an appropriate toolkit, Flex is designed for attractive and compelling user experience and has available all of Flash. Plus the development environment and available widgets make it easy and fun to program. I don't want to spark a religious war about HTML vs. Flex, so I'll leave that there - it works for me and my application and customers.
Second, and more important, was that it balances the processing load more towards the client which means my server architecture can be optimised just for serving the content and persisting the data. Most of my business logic has migrated across to the client. Having spent many years in classical architectures I think this is a huge step forward, but I can already her a chorus of disagreement about that too.
My word of caution about Flex comes from needing to adopt the right architecture for your client code. It is pretty easy to create a huge and badly performing app with Flex if you get that wrong. Make everything event driven and apparently asynchronous and you should be OK ('apparently' because the Flash player is single threaded). And that is downside 1, the single threaded Flash player sometimes causes issues.
Downside 2 is perhaps more serious and that is locked down desktops in corporate environments. Quite often your target audience won't have administrative rights to their computer and will have either the wrong flash player or none at all. This is particularly true in public sector organisations and the military, so if you are heading there I would test carefully the presence of Flash amongst your users.
Other than that I heartily recommend Flex. It's also a great thing to have on your CV!
HTH
Flex has no inherent scalability problems, however if you have a graphic intensive application, proper serving of these resources might be a problem, but that has little to do with Flex.
The only note-worthy and likely platform you won't be able to run on is the iPhone (no flash) and some older non-flash mobile devices (although most support Flash-lite nowadays)
As for alternatives, if you are Graphics heavy, and don't mind the iPhone, then Flex is good if not best cross platform solution besides using pure HTML technologies, the trick here is HTML alone can do 99% of what Flex can do, but if your App requires the missing 1% then you're out of Luck, also Flex will reduce crossplatform and most browser compatibility issues. So it might make your work more productive.
Silverlight 2 is an alternative to consider. WPF if you're looking for something with offline support.
Yes, the scale and type of project
fits.
Immaturity of frameworks and libraries you might depend on. Immaturity of IDE's.
Silverlight, JavaFX.
Flex + AIR is probably as good a tool as Visual Basic was; it may be a better tool for having a much more flexible programming language and having free development tools, but keep the limitations in mind....
The main limitation I've seen from working with it is documentation. There seems to be not enough documentation, not good enough documentation, and not enough high-visibility work on it in the community. (This is coming from years in .NET; I've been constantly upset with how little MSDN says about methods but generally able to deal with it by finding the most useful blog posts.)
Other possible development platforms would depend very heavily on the specifics of the project. Web-based platforms bog down in deep, stateful interactions with data sets (even with nice AJAX libraries), whereas maintaining client-side installations of any thick client program (say, Flex + AIR) might be overkill if it's just a few CRUD forms.
My company has been working on a Flex dashboard that displays realtime financial information. It will be deployed over a corporate WAN to perhaps a few dozen users.
This is our first Flex project, and while development has been very pleasant, we're a little concerned about what production issues might come up (users not having the right Flash player installed, long download times,BlazeDS performance, etc).
Our stack is RDBMS/Spring/BlazeDS (remoting and messaging)/Flex.
Does anyone with experience deploying a commercial Flex app have any words of advice?
Your biggest problems are likely to be:
your users not having the correct version of the flash player
your users having locked-down desktops and either not being able to download the right version of the player or not being allowed to use the player at all
download speeds of the swf if you have a big app
intermittent loss of connection to your back-end due to either bugs in your code or unavailable network connection
restrictive browser policies
None of these are insurmountable, but you are likely to encounter all of them in the first few months.
I am presuming that you have tested your app for performance under reasonable load and will have fixed those scalability issues already :-)
HTH
If you're talking about a few dozen users I don't think you'll have a lot of performance issues. In my opinion the first tree bullets of Simon will be the most likely problems.
We have a flex business solution with a .NET/WebORB backend and a MS SQL2005 server.
The swf of the frontend application is about 1.2 Mb big. If you have a broadband internet connection, then download time is not an issue (as it is corporately deployed in WAN, I guess this is no issue). If not, then the first time the user loads the swf it will take some time, but then it should be cached. (caching is another issue if you often have new builds. Best is to have a contextmenu in your swf where you can see the buildversion. If a user has problems with the application, one of the first things I check is whether they have laoded the last version.).
At times the frontend player is simultaneously used by 500 candidates. Each player loads and saves data regularely to the server. We have had no problems so far and I know that using cache on the server side performance can be increased a lot. Stresstests are important here as a lot depends on your architecture, hardware, concurrent users, ...
We also use messaging for pessimistic concurrency control and that's a whole other story. We have done a lot of testing here to get things up and running well.
Security doesn't seem a great issue in your project as it is deployed corporately. But be aware that remote calls available to the swf are not secured without security.
Lieven Cardoen aka Johlero
our logs showed that flex apps would randomly drop connections to our servers. We ended up adding automatic retry logic to all of our REST calls.