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.
Related
This maybe a bit of a 'wide' question, but am putting together a brief overview of a new system I'm proposing at work.
It will be a POS style system, that does quotes and invoices + crm for our work enviroment across 100 + locations.
It will communicate with server via the Internet. Flex / Air feature set (offline SQL is Internet goes down, Rich communications, rich client environment etc), the fact that we run Macs + PC makes it looks like a great choice. I know HTML 5 has offline SQL and stuff, but flex feature set is way more comprehensive / usable etc..
Something just feels risky about using Flex / Air, versus HTML.
Is anyone doing any big corporate Flex / Air projects that need to last a long time? Or are you pushing HTML and its new technologies to provide a more safe investment.
We have developed some fairly large systems in Flex for various types of businesses and IMO, this was the best technology choice we could make. The Flash Player and the Flex SDK certainly have their issues, especially if you push the boundaries in terms of performance, but in the end there is no valid alternative that offers you a ubiquitous runtime, with a single codebase, that is so widely used.
I think it's safe to say that the Flash platform and Flex/AIR have reached a certain level of maturity. There is tooling, frameworks, libraries, a vibrant community, ... Flash is everywhere and is not going anywhere soon.
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.
This is not a pure technical question, but I believe answers will help the RIA community.
We are a software development company working on development of a stock trading product. We chose to use Adobe Flex (in mid of 2008) due to its browser penetration and its maturity relative to Silverlight. We already developed the system, and we are quite happy with it.
Now we are planning to launch the second version of our product, and it will feature a much more advanced user interface -- basically a framework of dockable windows and panes as in Visual Studio 2005 and onward, etc. We searched on the internet and found that the market of 3rd party components for Adobe Flex is still very small, but for Microsoft's Silverlight there are many advanced 3rd party components available e.g. data grids, docking frameworks, etc.
When can we expect the same type of components in Adobe Flex? What do experts think if we develop to the new version of Silverlight (Expertise in Adobe Flex vs. Silverlight is not an issue at the moment, assuming we have to develop everything from scratch).
The launch of next version is expected to be in mid 2010. Any feedback regarding this is highly appreciated.
I can tell you from direct experience that Flex is a more productive platform. I work for a large RIA consultancy that builds a large number of apps with both Flex and Silverlight and we see that equivalent functionality in SL takes about 10-20% longer to develop than in Flex. Data binding support in Flex is significantly easier to use than in SL. I can also tell you that a suitably-experienced Flex developer could easily build a MDI toolkit in Flex with a couple of weeks of development time. So I would advise you to consider hiring experienced Flex developers rather than shelling out money for SL components.
SL does have a big advantage in that C# can be used on both the client and server and business logic can be reused in both tiers. This is significant and should not be discounted. ActionScript doesn't have a server-side counterpart and lacks this ability, although Flex does play nicely with a number of different backend technologies, especially Java using BlazeDS. Silverlight services integration has a variety of options on the .NET side (see Bart's comment below) while Flex can use very performant AMF in both RPC and data push (messaging). BlazeDS is free and open source.
I also think basing your decision for a development platform solely off the availability of 3rd party components is not a great idea. Putting that aside, MS platforms have always had a huge number of component development shops and a wide variety of components to choose from. It's likely even with a smaller market share that SL will have a bigger selection of 3rd party components than Flex moving forward.
Finally, I don't think MS is going to be giving up on Silverlight anytime soon. They are aggressively developing new features for SL4 and the Blend tool offers some innovations for designer/developer interactions that even Adobe is struggling to match with their new Catalyst tool.
If you have to make the decision today, I'd say go with Flex, especially for a public-facing application where you don't want to lose users because they can't or won't install the SL plugin. In 12-18 months I'm confident that SL will give Flex a much bigger run for its money but I don't think it's there, yet.
Although I cannot give you the desired answer, I hope I can give you a couple of good questions and ideas that maybe help you in the process:
City Coder: Flex 3 versus Silverlight 3 in Enterprise development
Microsoft Silverlight vs. Adobe AIR/Flex Debate
I personally think, that Adobe Flash is going to lose a noticeable user base in the near future duo to new features in the upcoming html 5.0 standard. Furthermore I prefer the tools (Visual Studio), addons and languages (C#) over the Adobe equivalents and I would consider these superior. However I have to emphasis that this is only from my perspective.. :)
A few people in this thread assume that you can't develop Flex or Flash-based projects with Visual Studio. From 30th August, 2010 that is no longer true. You may want to look at Amethyst which is a VS visual (drag+drop) Flash Platform IDE with a multi-process debugger, IntelliSense and refactoring: http://www.sapphiresteel.com
best wishes
Huw
actually i am also thorn between the 2. in fact, i still considered Flash, but sort of struck that off because thats more for animations rather than RIAs. with Flex, theres AIR to enable deployment in both desktop and web, tho i havent tried it and dunno how easy isit to use. and i also am not sure if Silverlight can be used as a desktop app anyone?
comparing Flex and Silverlight, i dont think we shld just base our judgment on what is more widely used now. Silverlight maybe something good!
just starting exploring the 2 and find Silverlight's XAML markup more intuitive than Flex mxml. further more Silverlight will integrate with C# which is getting better with LINQ and all. so data binding, an important part of any RIA is better. for Flex, one can probably link up with something like PHP with AMF but seems abit harder from what i saw. that said i am not really familiar with both.
UPDATE: and Flex is open source now while Silverlight closed right? so Flex can be said to be cheaper to use.
One thing to consider is Microsoft's dedication to Silverlight. Silverlight is not taking off. How long are they going to stick with it? If the next version of Silverlight doesn't get significant market penetration, is Microsoft going to continue supporting it?
Even if they do stick with it, and even if it does take off, are they going to do like they did with Internet Explorer: develop it into the most awesome browser available at the time with IE6, and then coast for 5+ years and become a major thorn in developers' hides?
Silverlight doesn't have a lot to do with Windows. People using Silverlight does not make Microsoft much money. There's not an especially compelling business case for MS to push Silverlight.
Silverlight doesn't offer anything to the users that Flash doesn't. It's the users that are going to drive Silverlight adoption, and until there's a compelling case for me to install it on my computer (which it's not, incidentally), it's staying off.
Flex is a natural companion to Flash, which is one of Adobe's flagship products. Adobe's not going to drop Flex. Even if they did, it's entirely open-source, and Flex development could quite definitely proceed even if Adobe fell into the ocean tomorrow. (Flash runtime is not open source, unfortunately, but it's a quite good multiplatform implementation of a mostly open SWF standard, with open source implementations progressing)
I work in a .NET/Flash shop. We use Flex to talk to a .NET back-end. It can be a pain in the ass to get them to interoperate (although not impossible). I like .NET. It would be great to be able to develop our front-end in C#. I would love it. But we're not willing to bet the farm on Silverlight, given MS's technology parade.
One of the most important thing in our decision on our future RIA technology is RTL support (specifically Arabic). I am very disappointed to hear that Arabic(RTL) is still not supported in Silverlight 3.0, on the other hand it is now supported on Adobe Flex 4. and I don't want to apply all non-standard tricks again that we used in our existing version of application (which is based on Flex 3). so Now One problem is solved in Flex but still remains in Silverlight... and still no docking framework in Flex, so it is going to be stalemate I guess.. :).
I will keep you updated regarding any new findings of our research...
One word (or two) --> "Open-source"
The world is going open source. Think android vs apple
How will you run applications for clients on Linux platform with any amount of confidence.
Right now I am not a netflix customer because no "Moonlight" support.
I have three computers at home all running Linux (Cannot shellout money to buy Windoze license) !
Think target market (and where it will be in the next few yrs)
Flex is more compatible with browsers, as it runs on top of Flash. Silverlight, however, needs to be downloaded, which might be a problem for users behind a proxy or network (in a workplace, for example, you can't install things). Flex also has a better framework than Silverlight, so you can customize a component in a few clicks and keystrokes.
I agree with you that VS and C# are more mature than their Flex counterparts (FB3 and ActionScript, respectively), but you'll get used to it quickly.
Then again, I am a Flex developer, and not a Silverlight developer, so my opinion can be somewhat biased. However, I did choose Flex over Silverlight because I thought that it was more compatible (nearly everyone has Flash Player) and has better support than Silverlight, and I don't regret my decision thus far.
If it is a stock trading product, does it stream the stock price in real-time? If it does, the cost of streaming the data will make some difference.
Both of them support some kind of data push (RTMP vs. Socket) and smart polling (RTMPT/RTMPS vs. HttpDuplexPollingChannel).
Infrastructural cost: Flex uses LCDS/BlazeDS while Silverlight uses IIS.
Development cost: RTMP/RTMPT/RTMPS is already defined (and cannot be changed) while you need to define your own protocol for socket (you need to handle security and compression yourself)
From programming perspective, Silverlight should be better since XAML is drawing the interface and C# updates the state of XAML components. There are plenty of C# developers and Expression Studio to create the XAML components.
MXML is relative simple and you need Flash to draw the fancy UI. You can wait for Flex 4 (in beta) with FXG support, however. Then, it might get better support for third-party components.
If you have expertise on both products is hard to say, from my side having an IDE like Visual Studio is a plus (I'm a .net developer), and using the same language on server (services) and client side it's something that makes me feel quite comfortable.
I would say... go for a Proof of Concept, take a week, make two teams (same level approx.), and check in a week (without any formal testing, or formal designing) to progress in Flex and SL (for the third parties they can take advante of all the trial versions). After that week check how far the have gone and their findings.
A waste of time one week? Try to focus as a live wireframe for your final app.
Good luck
Braulio
I don't think I could speculate on when or if Flex will have a similar number of 3rd party components. Many of the Silverlight components developed by companies like Telerik and DevExpress are ports or updates of existing .NET components. You might want to do a survey of companies that develop components for other Adobe products and ask on their forums if they plan to release a Flex product. Aside from that all I have to go on is what's available today and it sounds like you've already done the research on existing technologies. Good luck!
I have worked a bit with Flex but being more .Net oriented I can't say Flex can get any close to Silverlight in terms of developing business apps. Specially with RIA Services V2 and all the suit of .Net framework and visual studio everything is so integrated and professional.
The only reason I would consider not using Silverlight is if the product has public audience and you are going to loose customers due to low penetration of silverlight.
Ther is flex dock : http://code.google.com/p/flexdock/
And there is dock able flex : http://code.google.com/p/dockableflex/
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.
One of the stated goals of the PureMVC framework is to avoid platform dependencies in order to be portable. Considering that because of language and API differences application code will always be heavily dependent on the platform, and that avoiding platform dependencies makes the framework reinvent the wheel and/or only provide a least-common-denominator feature set, in what way does the portability of the framework benefit me as an application developer?
I've worked with PureMVC. They're trying to implement their stuff in quite a lot of languages. You may be right about the least common denominator, but overall, it's not a bad framework, and I've seen a really nice AS3 app in PureMVC.
I don't think they're talking about portability in terms of porting actual code. The idea there is more that you're using a generalized MVC architecture, which you could apply to other projects and other languages.
They're trying to say that if you become familiar with the PureMVC pattern, you could potentially come into a new PureMVC codebase, even if it's another language, and you would already know the lay of the land.
You might also say that developers who develop good PureMVC skills are likely to develop good habits which will translate as they go from language to language. But then again, maybe not.. for the reasons you mentioned.
We've been using PureMVC on two projects now and in my opinion the attempted language-independence is quite a burden.
The promise of jumping straight in a project because the framework is already know does not seem relevant to me if the languages are not already pretty similar (C# to java would make sense, as3 to php not) -- I agree that it is useful to have known ways of solving things, but for that the 'plain' patterns are good enough.
However, I also don't really agree with the usage of the various patterns the project uses, so our choice to not use it on the next project might be related to both issues, and not just the attempt at language/platform independence.
PureMVC's portability will help you when you migrate to or reimplement in another language.
I can't count the number of platforms and languages I've written code for that are now extinct and for which, even if I still had the source code it would be mostly worthless and have to be rewritten from the ground up today, since the code was usually 100% platform specific.
But all application code need not be heavily dependent upon the platform. View components and services (the boundaries of your application) will necessarily be, but your application logic which is sandwiched between the boundaries need not be.
The scope of PureMVC is really quite narrow; merely to help you split your code into the three tiers proscribed by the MVC meta-pattern. There is no reason why this code has to be tied deeply to your platform in order to be optimal.
When it comes time to migrate, you'll appreciate that the framework actors and their roles, responsibilities and collaborations remain the same. This leaves you to deal with syntactic differences of the language, recreating the view components and services. At least you won't have to completely re-architect.
And for the case of reimplementing in a different language, imagine you're trying to capture a significant part of the mobile market with your app. The market is so fractured, you'll have to implement the same program on 2 or more of Windows Mobile, iPhone, Flash, and Java. Sure you'll probably have separate teams in charge of the apps, but why have a totally different architecture? With PureMVC, you could have a single architecture for all versions of your application.
-=Cliff>
PureMVC is the only real option for Flash Platform developers who choose not to use the Flex Framework. For certain projects the size cost of Flex is too expensive (it happens!).
I like to prototype in Flex and then rip it out and replace my views with custom components when the application is near completion. PureMVC makes this really easy to do with it's Mediator pattern. I'm not sure there is any other framework that would allow me this workflow.
Personally, I think PureMVC went too far with it's portability goals: I enjoy that fact that it works with Flash AND Flex (for the reasons mentioned above), but feel that it should have stopped there, and made use of the native Flash Player event architecture.
Are there examples of people using PureMVC to build and port applications across multiple platforms?
My company is building a Flex application that we may need to port to other platforms:
Silverlight (likely)
Mobile (maybe)
Desktop (maybe -- not just AIR!)
TV sets (maybe eventually)
I am considering PureMVC as a framework if it can ease porting and maintenance. I am curious to know if other people have ported a PureMVC app to a different platform and what their experience was with porting and then having development proceed in parallel for the app on multiple platforms.
Cheers,
Karthik
PureMVC does not rely on a platform for its internal workings (Flash Events etc).
So, while it does not make porting any easier per-say, it can assist simply by showing us its friendly and familiar face wherever we may choose to go ;-)