{"id":22,"date":"2003-10-31T17:05:46","date_gmt":"2003-10-31T21:05:46","guid":{"rendered":"http:\/\/blogs.law.harvard.edu\/crimsonmedialab\/2003\/10\/31\/abcd-flash-co-chair-on-flash-"},"modified":"2006-08-31T15:46:25","modified_gmt":"2006-08-31T19:46:25","slug":"abcd-flash-co-chair-on-flash-guis-vs-java-guis","status":"publish","type":"post","link":"https:\/\/archive.blogs.harvard.edu\/crimsonmedialab\/2003\/10\/31\/abcd-flash-co-chair-on-flash-guis-vs-java-guis\/","title":{"rendered":"ABCD-Flash Co-Chair on Flash GUIs vs. Java GUIs"},"content":{"rendered":"

<\/a><\/p>\n

Here is an interesting post that occured in the ABCD Flash user group.<\/p>\n

————————————————————-<\/p>\n

If the GUI will be front-end Web-based I sincerely believe that Flash is a better option than using Java Applets.
\nHere are simple but compelling reasons to choose Flash over Java:<\/p>\n

1. Java is installed at only 80% of the browser vs. 98% of Flash. (and it’s isn’t installed by default on XP or Linux)
\n2. There are many compatability problems between different versions and platforms in Java.
\n3. Java requires a much (**much**) larger download.
\n4. Even for the simplest application Java requires at least 8MB of memory just to load the VM, and it has long load-up times.
\n5. Java is generally very slow doing graphic operations, and Flash is faster and scalable due to its\u00a0 vector graphical nature.
\n6. Although Java and Actionscript (Javascript) are both cousins of the language C, they differ substantially. The learning curve for Java is rather steep in comparison to Actionscript. It is said that there is a 3 million Java Army — but how many of them are savvy in J2ME and\/or Swing?
\n7. Flash does UI excellently (java can only hope to catch up) and you can built a GUI with minimal scripting experience with “out-of-the-box”\u00a0 Flash components.<\/p>\n

I understand that Java might be a better back-end server-side solution in some cases but I don’t know enough about it to comment on it.<\/p>\n

However, I would like to clarify and update some of Catie’s “CON-Flash” comments with the latest information about the most recent version of\u00a0
\nFlash MX 2004. See my comments below:<\/p>\n

CON-Flash
\n– Horrible horrible debugging\/error-reporting capabilities – this was the
\none thing that convinced me that it would be a huge headache to develop a
\ncomplex application in Flash. When things failed, the application would
\nstill run but just act strange instead of failing with some proper
\ninformation on why the failure occurred. This makes debugging and
\ntroubleshooting complex interactions incredibly difficult. Flash MX has
\ngreatly improved its debugging capabilities but I still see this as a major
\ndrawback for application development in Flash.<\/p><\/blockquote>\n

In Flash MX 2004 debugging has become much easier and better to track problems.
\nFlash provides several tools for testing ActionScript in your SWF files.
\nThe Debugger, lets you find errors in a SWF file while it’s running in Flash Player (you can also STOP the application). Flash also provides the following additional debugging tools:<\/p>\n

The Output panel, which displays error messages and lists of variables and objects (see Using the Output panel)
\nThe trace statement, which sends programming notes and values of expressions to the Output panel (see Using the trace statement)
\nThe throw and try..catch..finally statements, which let you test and respond to runtime errors from within your script
\nThe availability of comprehensive compiler error messages, which let you diagnose and fix problems more readily.<\/p>\n

Using Flash MX 2004 Professional you can use Data binding which is a series of actions that take place in response to events, such as the following:<\/p>\n

The data of a component property changes.
\nA web service call is completed.
\nAn XML document is fetched.<\/p>\n

All actions that are performed by data binding or web services are reported to a log.<\/p>\n

When you run an application that turns the trace on, a detailed log of data binding and web services events and actions appears in the Output window. The following are the types of things reported:<\/p>\n

Executing bindings
\nCalling web service methods
\nFetching XML documents
\nStatus and result events from WebService and XML components
\nValid and invalid events from validated data fields
\nA variety of errors, invalid settings, and so on that are checked for<\/p>\n

By running your application and then examining the log, you can often find out why things are not working as expected. Sometimes an error is explicitly reported\u2014for example, a missing web service parameter. Sometimes the data is bound to the wrong component, or to no component, and so on. If you find that there is too much information in the log, clear the Output window by selecting Clear from the context menu, to keep the log as short as possible<\/p>\n

– ActionScript is a *lot* less powerful than Java – ActionScript doesn’t
\nsupport basic things — for example —\u00a0 manipulating files (this could be
\nfor security reasons, but there is no ability to certify your flash
\napplication and then gain access to the user’s hard drive as there is with
\napplets and java apps for example).<\/p><\/blockquote>\n

Agreed, but I believe that file manipulation will be added in future versions.
\nYou can manipulate XML files.<\/p>\n

– Very limited Reusability of code – flash applications can’t re-use code
\ncreated in other flash applications without some serious copy and pasting. I
\nimagine you could attempt to get around this by building little modular
\nflash movies that can be imported into other movies, but this seems like
\ndesign gymnastics to get around a problem that doesn’t exist in java.
\nAdditionally, if you wanted to build an application framework that was meant
\nto be extended and used in a variety of different ways this seems virtually
\nimpossible in Flash (though it might be interesting to talk to some serious
\nmacromedia developers and see if they have some insight as to how one might
\ndo this)<\/p><\/blockquote>\n

ActionScript 2.0 (new to Flash MX2004) is a restructuring of the ActionScript language that provides several powerful new programming features found in other programming languages, such as Java. ActionScript 2.0 encourages program structures that are reusable, scalable, robust, and maintainable. It also decreases development time by providing users with thorough coding assistance and debugging information. ActionScript 2.0 conforms to existing standards and is based on the ECMAScript 4 proposal.<\/p>\n

The primary feature of ActionScript 2.0 is a familiar model for creating object-oriented programs. ActionScript 2.0 introduces several new object- oriented concepts and keywords such as class, interface, and packages that will be familiar to you if you’ve ever programmed with Java. You can easily extend Classes now.<\/p>\n

The OOP model provided by ActionScript 2.0 is a “syntactic formalization” of the prototype chaining method used in previous versions of Macromedia Flash to create objects and establish inheritance.<\/p>\n

Strict data typing ActionScript 2.0 also lets you explicitly specify data types for variables, function parameters, and function return types.<\/p>\n

– lack of built-in GUI components that support applications (Java\/Swing
\nencompasses the concepts of application development such as menus, dialogue
\nboxes, etc.) Flash has no such libraries so you either need to build these
\ncomponents from scratch or grab some open-source ones online<\/p><\/blockquote>\n

Flash has a whole family of standard built-in components ( Data, Media and UI–including menus, scroll panes, text-areas, radio buttons etc, ), and many (many) more are available from third party developers (free-ware and $).
\n\u00a0Components are movie clips with parameters that allow you to modify their appearance and behavior. A component can provide a wide range of functionality. A component can be a simple user interface control, such as a radio button or a check box, or it can be a complicated control element, such as a media controller or a scroll pane. A component can even be nonvisual, like the focus manager that allows you to control which object receives focus in an application.
\nComponents are designed to allow developers to reuse and share code, and to encapsulate complex functionality that designers can use and customize without using ActionScript.
\nComponents are built on version 2 (v2) of the Macromedia Component Architecture, which allows you to easily and quickly build robust applications with a consistent appearance and behavior.
\nComponents allow you to separate coding and design. They also allow you to reuse code, and download components created by other developer
\nor create your own components.<\/p>\n","protected":false},"excerpt":{"rendered":"

Here is an interesting post that occured in the ABCD Flash user group. ————————————————————- If the GUI will be front-end Web-based I sincerely believe that Flash is a better option than using Java Applets. Here are simple but compelling reasons to choose Flash over Java: 1. Java is installed at only 80% of the browser […]<\/p>\n","protected":false},"author":105,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[569,572],"tags":[],"class_list":["post-22","post","type-post","status-publish","format-standard","hentry","category-flash","category-projects"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/archive.blogs.harvard.edu\/crimsonmedialab\/wp-json\/wp\/v2\/posts\/22","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/archive.blogs.harvard.edu\/crimsonmedialab\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/archive.blogs.harvard.edu\/crimsonmedialab\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/crimsonmedialab\/wp-json\/wp\/v2\/users\/105"}],"replies":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/crimsonmedialab\/wp-json\/wp\/v2\/comments?post=22"}],"version-history":[{"count":0,"href":"https:\/\/archive.blogs.harvard.edu\/crimsonmedialab\/wp-json\/wp\/v2\/posts\/22\/revisions"}],"wp:attachment":[{"href":"https:\/\/archive.blogs.harvard.edu\/crimsonmedialab\/wp-json\/wp\/v2\/media?parent=22"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/crimsonmedialab\/wp-json\/wp\/v2\/categories?post=22"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/crimsonmedialab\/wp-json\/wp\/v2\/tags?post=22"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}