It think that native clients for IPhone/Android are great ideas and the more the merrier, however it seems to me that it would be a lot easier to make Data API based clients first.
Sent from my iPhone On 5 באפר 2011, at 12:02, Thomas Wrobel <[email protected]> wrote: >>> I'm working on a mobile android wave client, > >> Do you think we can share the same software requirements document? > > Id happy to share resources, but we haven't got anything so organised as that. > We started with a couple of simple use cases and built the code around them. > We have been mostly focusing on the UI and 3D aspects of our project > the last few months (arwave.org), as we haven't had much luck making a > working connection to the WiaB server yet. (we previously had a > working read/write FedOne connection on a android device, so we know > its possible). > We are currently waiting to see how the c/s protocol of WiaB > progress's, as extracting the neccessery bits from the server code > (and in some cases backporting to java 1.5) seems a lot of work for > something likely to change still. > > > > On 5 April 2011 01:10, James Purser <[email protected]> wrote: >>> >>> uhm... are you sure? why? I think that a mobile client shall require a >>> connection to work, like a browser... >>> >>> Mobile connection is by its nature unreliable. I find it best to code with >> the assumption that the network may not be available. Hence the need for >> some sort of offline storage. > > Indeed. > I didn't mean to suggest its strictly required, merely that its very > desirable for the end user to be able to "cache and sycn" there > updates. I think the gmail app is a pretty perfect example of how it > should work in that regard. > > Of course, however, my own project is all geolocation focused > (arwave.org), so the end user will probably be moving and offline a > lot more often then other applications of connecting to a wfp server.
