viwow blogging

Viwow: Yet another approach to client application

2005-04-18T10:48:00.000-07:00

Defining Viwow
1. View design using Flash IDE
2. Separating the design and development work
3. Forcing the separation of UI and functional code
4. A complete solution to debug, test and log Flash application
5. Making Flash multi-window-able
6. Making Flash api-limitless
7. Deploy to everywhere(both web and desktop)

The tree type of clients

2005-04-16T22:26:00.000-07:00

http://www.fankai.com/index.php?op=ViewArticle&articleId=24&blogId=1

fan kai said, there are three type of clients. I thought there exists the fourth:
central and java web start. Although it was used rarely, but it do differs from standalone RCP.
summary them all up:
1. Integrated as a web site RIA
2. Distributed and pop-up RIA
3. Standalone and executable RCP
4. Central RCP
I am trying to figure out if it is possible to write a flash framework to support all these types.

Some thoughts on Flash

2005-04-06T08:34:00.000-07:00

My standpoint: Flash will be the final solution for most RIA situtaion

let's begin from the drawbacks of tranditional flash development.

1. It's hard to do coding in FlashIDE
I solve this problem in a tricky way, but if you get used to it, you will find it rather convenient, much eaiser then doing it inside Flash IDE. There is one key tool, called MTASC, a open source ActionScript Compiler. It can replace the MMC compiled class with its production. So it makes doing coding and compiling in Eclipse possible. You can code in Eclipse with the help of ASDT(like JDT), and then compile the code using MTASC with help of ANT make file. The output is a new swf file with classes replaced.

2. It's impossible to open a new window outside a Flash window.

yes, you can open a new window inside a flash window with the window component. But it is very common request to open a new window and let people do conversitation outside the parent window.I can not open new window in "one" application either...But we can use multiple applications, right? Open a new window can be interepted as open a new Browser Window containing a new flash application. Then if we can communicate between these two applications, we can let the new one acts as a window of the previous one. That is possible, and with some level abstraction, you can use it with just a little plumbing boring messing.

3. You can only use it on Web

sure, for most advanced flasher, it is not a real problem. You can use projector, the flash player can do this for you. But the projector realis on the flash control which is only avaialbe on windows platform.This problem can be solved by using other flash "control". The mozilla browser has flash plugin, and it is platform netural. So you can write a application in a platform netural language and containing a mozilla browser inside your application, then you can load your flash movie. Then your RIA become real executable file on almost all the mainstream platforms.

4. the api of flash is limited

Flash is invented as a movie tool so is a web application. The biggest impact is the lackness of concern on the rich functionalitiy which needs the support from the direct OS rather than browser. The most famouse is FileSystemAccess. If we want to deploy flash RIA as executables, then such kind of limit is somewhat inacceptable.Central solved this problem with the help of a new virtual machine. But we can not use central for enterprise application, because we can not make our application feels standalone. And central extend the flash using a new virtual machine which is impossible for we guys outside macromedia. So we have to find out a new way to extend the power of flash. The sceret leaked out by Gush, a jabber client write its UI in flash. Its code was written in python, so there must exits some way to communicate between UI and background. When the focus comes to communication, the socket become a reasonable consideration. Yes, Gush is using socket, and I thought it may be the only way to extend flash(LocalConnection may be another direction, but it is hard to let it become less tricky, and platform netural).

last, comes to the conclusion:with the help of a new flash development environment(Flash IDE + Eclipse IDE + MTASC + ANT), and a window framework(to hide the detail level and plumbing code of LocalConnection), and a platform netural projector(Mozilla is the hero here), and a extended flash api library(socket...but it works), we can write a flash RIA one time, and deploy it on web and desktop with different function&experience.

Extending Flash

2005-04-04T08:19:00.000-07:00

No, no, I am talking about jsfl, or writing your own components, I am talking about the possibility to extending the api of flash. If you have once seen what central can do, you will know what is such "extending" really mean.
As you are writing flash, you are somewhat be limited to the environment of web, so is the functionality of the api, for example, you can not access the file system. But central can let you do so...How can central enable you having the magic? Yeah, that is the topic I want to discuss.
Another example is Gush, a flash client(semi-flash at least) of jabber and blogging. It can do the communication using SSL socket, which is impossible in pure flash, it is also some kind of magic. And I am lucky to have found the secret behind.
Central and Gush, two classical way to extend flash. They are different, and they both extended the api or to say the possibility of flash. First, let's examine the central. If you have ever examined central carefully, you will find the right-mouse menu is different from the normal flash application. And if you have ever used the control provided by Macromedia, you will find it is not possible to do so if you are using the normal flash control(.ocx), and even the mozilla version of flash plugin. Then I am sure the central is not using the normal flash control, instead, Macromedia wrote another Virtual Machine for flash, that is central. Yes, flash player is a virtual machine, just like the JRE. So the magic is so straight to explain, a new virtual machine with new power for sure. But what will happen if you run those swf intended to be used inside central in normal flash player? I tried, nothing happens. I guess the default implemention of those api is empty, and central will catch those api when running, and interpret it in a different way.
Then, comes the Gush turn. It was made outside Macromedia, it was not writing a new virtual machine for sure, then what is the source of the magic? If you ever examined the installtion folder of Gush, you will find bunch of python compiled code. Yeah, it was written in python, rather then actionscript. So I call Gush a semi-flash client, because it just use flash as the UI layer. The real logic of programme was implemented in python, so with more powerful api. Then, the focus come to the connection between flash and python. Flash doesn't have any thing like JNI with no doubts, then flash can not call anything outside flash. If you run a swf and a python programme concurrently, they are in different process, so what about IPC? Yeah, Gush used the socket (XMLSocket of ActionScript) to do IPC. If you use "netstat" command, you will find I am right. By the way, the famouse LocalConnection was also created using IPC also...
Now, the conclusion, if you are really guru of flash, you can write a new virtual machine as the Macromedia can do. If you are only the poor guy just like me, you have to do IPC (or more specifiectly the socket) to extend the api of flash.

Start blogging today

2005-04-02T12:41:00.000-08:00

viwow~