Any Android users?
Hi all,
Just wanted to give a heads-up to any Android users out there... I've uploaded an Echo-based application to the Android market. It's called "WebSharing" and uses a client-side Echo3 app served up by a phone-based Jetty HTTP server to allow a user to upload/download files, music, and photos from their device.
Of specific interest to Echo users is the fact that the application has two "live grid/table" type Echo components, both of which will be open-sourced and added to Extras. One of the components displays a column-based table of items (as used in the music player), and the other displays items in a grid (as used in the photo viewer). They are currently client-side (server-side peers have not yet been written), but that will change. I'll try to get these posted fairly soon.
More info can be found @ the new NextApp Android site, http://android.nextapp.com. The app is currently free, though it will be paid app once it's received adequate testing. You can find it on the Android market by searching for "WebSharing".
Merry Christmas and Happy Holidays!
--Tod
Interesting
I just installed it on a coworker's phone. (I'm still stuck on a SE P1i )
Here some feedback:
- Interesting application
- No preview of pictures (not sure where the problem is) but full display works
- Sometimes FF 3.5 on a slow PC (Older 2.4GHz CPU, 512MB Ram) shows the FF waring about a long running script
- Nice to see a table with fixed headers ;)
- Unfortunately we did not see paging, since the lists had at most 47 items in it.
Question: Is it 100% javascript ?
André
With the previews, are you
With the previews, are you talking about in the files tab or the photos tab? There's no preview in the files tab yet (just that stock image icon), but I'll probably add one at some point. In the photos tab you should definitely see thumbnails. If the problem is in the photos tab, are you seeing a bunch of "clock" icons or broken images? You could also try turning off SHA-256 signatures on all requests (it's in the settings menu under "Network"), and see if that could be the problem.
There are no pagers anywhere in the app...everything is in a "list view" or "flow view". The scrollbar is not actually connected to the DIV, it's something we render deliberately based on the calculated height of the displayed content vs. the total height. Each of those components determines how tall a row of data is. As the scroll bar moves, the component will render only the portion of content which is actually on the screen. The model which backs it also prefetches data as you scroll from the server (phone) to try and ensure that you can smoothly peruse a list without ever realizing that content is being fetched from a remote source.
Note that the "files" tab does not yet use list view/flow view, it actually renders everything. If you have a very large directory and saw it take a little long to render, this could be to blame. The files tab will updated to use list and flow views (with a view-as-list/view-as-grid option) in a future release.
The client UI is almost entirely JavaScript. A flash control, SoundManager2 ( http://www.schillmania.com/projects/soundmanager2/ ), is used for audio playback (and hopefully video playback in the future). It's a great little offscreen control that you just feed an MP3 URL. You can then control playback and receive information via commands and events. And then of course its using SWFUpload as packaged in Echo3 FileTransfer.
The server-side is a slightly thinned out Jetty 6.1.22 (only for size reasons, the whole works will run on Android).
It *really* shouldn't be hanging with a long-running script error in FF, any more info on how/where this happens would be extremely appreciated. I'm testing on a 6.5 year old first-generation Pentium 4 2.4GHz with Ubuntu 9.04 + FF 3.0. The only thing I've noticed performance wise is that the flow components don't scroll as smooth as I'd like. (And Linux FF 3.0 is horribly slow). I've never seen the long-running-script warning during development (except of course when I forgot to increment a variable in a loop :D).
Everything it does is asynchronous...it never waits on any XMLHttpRequests.
The one unusual thing the app does do is fire off multiple XHRs to the server if it takes too long to receive a response. This is done to work around incredibly flaky and connection-dropping consumer grade wifi-routers. I've seen wifi equipment that will work fine for hours (e.g. my Linux-powered LinkSys WRT54G) and equipment that seems to drop 1 in 40 connections. Each XHR carries a sequentially assigned id such that the server will only process a request once and the client will only process the response once. And there's a delay before additional requests are fired. I hope to eventually add this into server-side Echo3 to solve issues where bad networks are dropping or corrupting XHR requests.
Flaky routers
I'm quite concerned about this flaky router issue. Our software is approaching release and whilst it is B2B I'm fully expecting that some businesses that use it will be very small and could have these flaky routers.
Would hugely appreciate the server-side mechanism you talk about being implemented.
I'm looking into doing it,
I'm looking into doing it, want it in 3.0 (a.k.a. soon). It does seem to have completely eliminated the problem with the mobile app.
You're seeing truncated requests as well, not just delays, correct? Not a problem, given that we'll just treat invalid/non-parseable responses the same as non-responses.
The biggest concern would be dealing with operations that legitimately take a long time and/or high-load conditions. With the mobile app, all the requests/responses are fairly short, and there's only one client, so we know were not bothering the server in a time of crisis when our request takes too long to process. This will be a bit trickier with Echo3 server-side, otherwise clients will attack an overloaded server at the worst possible time.
I see lost or incomplete XHR errors on wireless modems
When I demo our app to clients I use my laptop connected to a wireless (G3) modem that's part of my Nokia E51 phone. The connection works fine for surfing most sites on the web on the laptop except when I hit the Echo side of our app. At that point I see the occassional red screen of death. I wonder if it's caused by the connection dropping problem you mention.
Step Ahead Software
Makers of Javelin Modeler+Coder for Java.
Automatic persistence of your object model using JDO and Hibernate.
http://stepaheadsoftware.com/products/javelin/javelin.htm