Google answers online state dilemma with non-answer
As I discussed in my previous post There isn't a way to maintain online state with Google Gears. I just found an entry on Google Code which addresses the subject when it comes to database stores. I totally understand Google's point about wanting developers to ensure synchs are reliable and not assume online = success. That still doesn't address my issue with LocalServer rather than the Database module of Gears.
A bit frustrating also is to see that on the same page Google provides essentially the same code I discussed previously to ping the server with AJAX to verify that it is available. GaH! Wasted effort!
I have to say that I do think Google is cutting off it's nose to spite it's face here. While an isOnline() function might be abused when it comes to the local database, it's entirely necessary (as I've demonstrated) for the localServer which is 1/3 of the gears trinity. In addition, I've seen time and time again that you can't use technology to make programmers do their job correctly (I've tried). You have to empower them to make good design decisions on their own, warn them of the pitfalls, and then let them deal with the consequences if they don't do their job well. It's an annoying fact of life in IT (I would know, I've done a lot of cleanup after bad programmers). That's my 2 cents anyhow.
posted by Brando @ 5:35 AM
2 Comments:
Hi Brandon,
I work on the Gears team. People always want an isOnline() function, but the truth is that there is no way to reliably detect whether you're online. If we implemented this function in Gears, it would have the same problem you describe in this post.
The localserver and database module s are designed to prevent your application from needing to know whether it is online.
The localserver serves your pages directly from the cache whether you are online or offline. It doesn't know the difference. The pages get updated in the background whenever possible.
For data updates, instead of sending them directly to your server via AJAX, the idea is that you store them in the database instead. Separately from that, you have a loop running that tries to pull things out of the database and send them to the server. If that fails for any reason, you leave the updates in the database and try again next time.
This way you do not usually need to know whether your are online or offline. Your application works the same either way. This is basically how applications like local mail clients work as well.
I hope this helps. If you have any more questions, or if this is not clear at all, feel free to join the Google Groups list and ask:
http://groups.google.com/group/google-gears
Aaron,
I appreciate you taking the time to comment on my blog. Your suggestions are duly noted, and in 90% of scenarios they apply. Mine is special however. I'm not submitting the information to my database when I sync (checking to see if I am online first) I send it too to another database to be imported to a lotus notes system later. So I don't want my app checking if it can sync all the time. Based on your suggestion though I think when a user chooses to "upload" the document they are working on I will move it to a new table, and that table will keep trying to upload to the other system until it has a success. You can see how this is still a bit of a catch 22 for me though, as the user isn't quite sure if their document actually made it online unless they check back later to see. It'd be nicer to validate up front. I suppose that the paradigm that is web programming though, right?
Post a Comment
<< Home