Tutorial for application to auto update from online source 1

[Microbe]

I am writing a browser based application for a network of volunteer emergency service groups.

There are about 1500 groups spread across the state and I would like the app to check for updates and then download and install them.

While I am reasonable at PHP/mySQL this is a whole new field for me and I don't know where to start.

I challenge anyone to frame a google query for this. With the words PHP and UPDATE the noise to signal is just too huge. Even creating the topic for this post was difficult.

I do not want an answer - I am looking for a resource, a tutorial, some sample code...anything to get me going so I can learn it myself.

Your help is much appreciated.

Steve Davis

http://www.HaHaHa.com.au/weblog

NOTE: This sig does not include any reference to voting, stars, or marking posts as helpful as doing so is cause for membership termination.

 

[jpadie]

Steve

can i try to rephrase your question so that I am sure to understand?

1. you are writing a 'browser based application'. does this mean
(a) it is a single page application that uses javascript and potentially interacts with a server using xmlhttprequest?; or
(b) you are writing an hta for windows only. javascript and xmlhttprequest may also be required
(c) you are writing a toolbar application

2. when you say check for updates, do you mean:
(a) check for updates to the core application (i.e. html and javascript);
(b) check for updates to the data that feeds the application?

3. when you say download do you mean that the application and data would always reside client-side?

 

[Microbe]

1. you are writing a 'browser based application'. does this mean
(a) it is a single page application that uses javascript and potentially interacts with a server using xmlhttprequest?; or
(b) you are writing an hta for windows only. javascript and xmlhttprequest may also be required
(c) you are writing a toolbar application

Actually, none of the above. It is a PHP/mySQL website really. A members database that is tha backbone of some quite complex incident management algorithms. See a really alpha version at

http://www.FireShed.com

2. when you say check for updates, do you mean:
(a) check for updates to the core application (i.e. html and javascript);
(b) check for updates to the data that feeds the application?

Yikes...I never realised there were so many worms in this can.

It would need to update PHP pages with patches and enhancements and perhaps run some .sql code to alter mySQL databases. But I hope I have the db set up properly right from the start.

3. when you say download do you mean that the application and data would always reside client-side?

No, the app and data would be on a single machine in fire stations and is completely independent of the web.

However, when they connect to the intertubes I would like the application to phone home and see if they have the latest version.

If not, an update process should initiate that is essentially transparent to the end user.

Some background on the whole thing to put it in context. I was the boss at a volunteer bushfire brigade for many years. There was/is no software to manage our stations so I created one, initially in ASP/Access. Other brigades eye it enviously so I want to share it.

I have since moved to PHP/mySQL (how much easier and more powerful!!) and am rewriting the whole thing.

Many of the end users are not particularly computer literate so I am trying to make this do what I, as an incident controller and station manager would like, AND make it easy to use.

Part of the ease is to patch it and upgrade it automatically if possible.

Hope that makes it more clear.

Steve Davis

http://www.HaHaHa.com.au/weblog

NOTE: This sig does not include any reference to voting, stars, or marking posts as helpful as doing so is cause for membership termination.

 

[Microbe]

oops...I misread Q3. Yes, it would reside client-side entirely.

Steve Davis

http://www.HaHaHa.com.au/weblog

NOTE: This sig does not include any reference to voting, stars, or marking posts as helpful as doing so is cause for membership termination.

 

[jpadie]

still not quite there in my understanding.

the data: is this all stored centrally for all the fire stations or stored locally only for each fire station? e.g. when you talk about updating the application are you talking about a constant data feed as part of that update or just an 'every now and then' db structure change with no impact on the data?

and just to double check:

each fire station will host its own server in effect. there may be multiple clients at each station, but they will all punch in to a local server running php and apache (or similar).

if this is correct, is this really more efficient than having all the fire brigades access a central server hosted somewhere professionally?

 

[Microbe]

hehe...I think you are thinking it is more complex than it really is.

Each station is a standalone system. There is no central database. Likely no network...each station will have a single computer.

As part of the install their computer will be set up with PHP and mySQL and they will access the local database via their browser.

Obviously there will be bugs found down the track and suggestions will lead to enhancements and more features.

My problem is how to get those out to 1500 brigades automatically. So...back to the original question. I want the application to phone home to my server at fireshed.com and if it isn't the latest version, grab updated files.

More background. This started as a simple database to store member data rather than paper based. Part of the attraction was being able to print out call-out lists and have the members categorised by their rank or whether they had truck license or whatever skill.

It then grew so that any training activity could be added in a lookup, so now we can print the complete training history of either the brigade or an individual.

Then I added the incident management module. Members can be assigned to a truck or a task, flagged as scheduled at a particular time or not at all (we are all volunteers). It all works really well. In fact, when an incident is closed it then creates that incident as a brigade acticity and logs it against all those members.

Finally it will caclulate the number of hours spent on fires during a given period.

All this was effectively impossible before I created this, which is why others want a copy. )

Steve Davis

http://www.HaHaHa.com.au/weblog

NOTE: This sig does not include any reference to voting, stars, or marking posts as helpful as doing so is cause for membership termination.

 

[jpadie]

so all data is always local.

that simplifies things.

i'm not sure that you will find a tutorial anywhere for this. the steps that you should look at are:

1. have a web page on your site that returns either a 1 or a 0 given a specific id. a 1 would be a signal that an update is required. the page need not return anything else.

2. have your webapp perform a file_get_contents on this resource from time to time.

3. if a 1 is returned, the webapp should request the update from your server. the server will typically return a zip file but you could also return a serialized array or whatever. a zip file seems easier.

4. the webapp would then take its current code base and copy it into a backup directory, then manipulate the zip file to overwrite the current directory, leaving prefs files etc intact. If you were using an array, you could parse the array into key->value pairs where each key is a filename and the value is the file contents. you'd need a checksum on this to ensure that the whole thing was properly transferred.

5. the code base would check also for the presence of a runonce.php file in your local code base. if it were there, the commands in runonce.php would be actioned (i.e. database structure alterations) and then the file would delete itself, ensuring that it would not be run again.

 

[jpadie]

i forgot to add ...

when the update is complete the webapp should send a notice to the central site telling it. then the relevant db entry can be changed.

of course, although i went with a zip file or array above, there is nothing to stop you using ftp functions or similar to grab the files more traditionally off the central webserver. there is also nothing to stop you just upgrading single files. i somehow feel a complete overwrite is better since the customer can roll back (probably a call to base here) by changing the directory names of the backup. (incidentally - for the copy across referred to above, you can always invert and rename the relevant parent directory and copy back the pref files, if any are stored in that tree).

 

[Microbe]

Thanks for that. I really god pointer in the right direction.

Much appreciated.

Steve Davis

http://www.HaHaHa.com.au/weblog

NOTE: This sig does not include any reference to voting, stars, or marking posts as helpful as doing so is cause for membership termination.

 

[Microbe]

good god, did I say god instead of good?

Steve Davis

http://www.HaHaHa.com.au/weblog

NOTE: This sig does not include any reference to voting, stars, or marking posts as helpful as doing so is cause for membership termination.