It is likely that each of can see the need for an RIA for certain apps
and/or parts of other apps,
I suspect that there very few cases where we would use an RIA for
flaming logos or barndoor-wipe page transitions -- a lot of overhead,
adds little to the user experience, and gets tedious real fast.
There are a few specialty AV apps I would like to do using mp3s, photos
and movies (manage my own collections of these).
But, I expect the majority the time i would use RIA components for data
grids, drill-downs, data maintenance and menus (popup, trees, etc).
I have one special app that appears to be an ideal candidate for an
RIA. It is a grid of typically 20 columns by 30 rows and represents a
stock portfolio. about 80% of the data is static (days, held, number
of shares, ticker symbol, purchase price, etc). The other data
(current price, profit/loss, potential ROI, buy/sell thresholds, etc.)
is very dynamic during market hours,
The dynamic data comes from a streaming service and is quasi real-time
(there is no artificial delay, the service provides data as fast as it
gets it). When the streaming data is received at the host, the host
programs determines what has changed (and by how much), if any
thresholds are reached (or being approached), etc. Then, only these
changes are sent to the client, where the grid cells are updated. When
the changes are displayed, the individual cells may change color to
indicate amount of profit/loss, that the price is approaching the
target buy/sell price, etc. With all the lights flashing on and off it
is kind of like a big video game-- portfolio pachinko! But it is very
useful -- the colors draw your attention to what needs your attention
or assure you with a glance that a given stock position is/is not
performing as expected.
As I type this MACR is up $.36 at $20.10 --- oops up $.33 at $20.07.
It is towards the high of the $17.50 (Buy) and $21,50 (Sell) thresholds
-- no action required.
I have written 21/2 versions of this program:
1) HTML only refresh entire page (dense update)
2) Flash RIA client with datagrid component (sparse update) - slower
than above, but no annoying page refresh
2 1/2) Hidden frame _javascript_ client (semi-sparse* update) - faster
than either of the above and no annoying page refresh.
* I augmented the code in step 1 to generate a structure with only the
changes. this and the entire (updated) html page are sent to a hidden
frame. The _javascript_ at the client parses the data structure and
updates the individual cells of the grid in the visible frame (no
refresh). It's a hack, but it works pretty well.
I am currently writing version 3 using some client-side web service
_javascript_ routines by Rob Rohan -- looks very promising.
But, that's a story for later. My point here, is that I tried a Flash
RIA and it didn't perform well. The stock streamer service provides a
Java applet, but it is inflexible, doesn't contain required data, and
gets behind real-time by 5-7 minutes during peak market hours.
Why didn't the Flash RIA perform -- the best we could come up with is
it's the nature of the beast -- Flash just isn't a good fit for this
app.
OK, fair enough. But I did gain some experience with Flash and RIAs.
I noticed something that I had never really thought about. there is
quite a price to pay for RIAs (over and above the Flash plugin and the
swf download time). To test my program I had several open windows in
multiple browsers all displaying versions of my RIA app. The overhead
was quite noticeable. Each browser window had a swf with my RIA
competing for resources on the client.
"Well, that's unrealistic!": you might say. But, is it really? As
RIAs gain popularity throughout the web won't there be a high
probability of running multiple RIAs, (from the same or different
sources) concurrently, on a given desktop? Whew, that was a mouth full!
Of course, hardware technology advances will tend to mitigate the issue.
All this recent Flex chatter has made me rethink RIAs in a broader
sense.
To illustrate: If you go to the flex product page:
http://www.macromedia.com/software/flex/?promoid=home_prod_flex_111703#
and click the link to the Flex code explorer.
Aside: I am an old cuss, but it bothers me (more than a little) that
RIA links don't look like regular (HTML) links and the enter key
doesn't submit a form and hints sometimes popup too fast...
Anyway, the Flash Code Explorer pops up in another window.
On my DSL link (and it's a good one), the popup takes about 7 seconds
to load and about 3 seconds to render -- par for the course, I guess,
But, this showcase app feels "heavy" or "sticky".
The tree menu is one of the slowest I have seen... with noticeable
pauses when you open the top folder and push down the others.
Then, with the "sample" tab selected, click through the various tour
items. With each change a little initializing box pops for a second or
2 and then the example is displayed. That seems awfully slow.
Given this uneasiness with what I experienced, I did some rough timings
to see if I could quantify the cost (at the client) of an RIA
Here are my findings:
Mozilla 1.6 Mac OS X 10.3.3 CPU % Threads
Real Mem Virt Mem
----------------------------------- -------- -------
--------- ----------
No windows open......................... 1% 11
46M 425M
Mozilla Home page HTML (1).............. 1% 12
53M 432M
Flex Product page (2)................... 12-17% 19
60M 443M
Flex Samples (Code) Explorer Popup (3).. 25-29% 20
73M 462M
Flex Explorer Popup (4) 11-15% 13
70M 449M
(1) Simple animation (gifs, etc)
(2)
http://www.macromedia.com/software/flex/?promoid=home_prod_flex_111703#
(3) takes 7 seconds to load and about 3 seconds to render)
(3) these measurements have the flex product page and the popup open
concurrently
(4) Popup window is the only window open
Not a scientific timing for sure... just a rough "eyeball" of some
slices in time -- with a normal (for me) mix of other stuff going on.
But, I think the exercise illustrates at least 3 points.
1) RIAs have a cost -- they continuously consume CPU cycles whether
they are being used or not.
2) Multiple RIAs on the same desktop are highly probable and they
compete for valuable client resources.
3) A RIA that performs poorly loses much of its advantage (or, its
reason for existence).
I am a strong advocate of "doing it well" -- as well as you can. I
also believe that "anything worth doing, is worth doing, badly (if
that's the only choice)"
But with RIAs the latter may be inappropriate --a UI is a very personal
thing, like your "favorite" chair ... it's comfortable... or it's not!.
If a RIA is too slow (or too fast) it becomes "uncomfortable" and you
feel bothered, uneasy, distracted... ready to quit!
Then there is the matter of drill-down and data maintenance --
So, instead of downloading the next/prev n records in a drill-down, in
an RIA we download all the records (or a bigger subset) and let the
user browse thru them at the client --
we substitute one large data download for several smaller (and maybe
fewer overall records). Bandwidth isn't free -- neither are the server
cycles and memory to retrieve format (HTML, XML) and serialized the
data. Nor are these items free on the client -- especially not on the
client. If the RIA app is well designed and the optimal amount of data
is pre-downloaded, maybe we get a wssh (versus the next/prev n records)
-- maybe not.
Did you ever browser-refresh a RIA page?
Then I've heard: "you have all the data you need on the client... you
can browse through the data and update any records without any
interaction with the server... once all the updates are complete, you
just send them to the server..."
Gee, How do you program that at the server? What if multiple users
concurrently update the same record? What if the client machine
reboots, the browser crashes, or the user does a browser-refresh
page...
"Are you saying that the changes, I entered for the last 3 hours are
gone...GONE?
Yeah, ain't that rich?
I know that this is a SOT for this forum, but it seems that we, as CF
developers are going be dealing with RIAs in the future if not
presently doing so
I am not so sure that RIAs are worth all the hype, nor that they can
deliver all they being promised to do.
Thoughts
Dick
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
