another nice weekend
i have added the ability to jargo to save settings.
there's now a formal panel whereby users can choose if they:
- want the gps to automatically connect
- want the the sending of co-ordinates to be automatic [given above succeeds]
- interval at which co-ordinates are sent
i also now provide the user with a friendly name of their gps unit
----
the the coveted sending of UUID to the phone - DONE. this has taken me the most.
as i had to extend Jargo and the submit page of the web server.
the workflow is now as follows - the user when adding a device, generates a 'ticket' - which is a word from a list of 14000 that i borrowed from the *nix dictionary file (anything that isn't alpha has been ripped out, as well as anything below 4 characters and longer than 8).
after a user generates this Ticket - it is put away together with a UUID generated for the users device into a table in the db.
this word the user can then enter into Jargo's settings - which proceeds to contact the server and receives the UUID.
This saves the user from entering 30 odd characters which are a combination of hyphens, letters and numbers - nothing worse for a mobile phone user.
---
i then provided a page for users of pda's and laptops - or anyone who has direct access and is able to with ease enter the uuid generated.
----
the following procedures were added tonight:
generateUUIDTicket - used by webserver to get the words
addUUIDTicket - used by webserver to append new tickets/uuid's
----
Database interoperability.
Daniel wants for us to implement the ability to switch between backends. All fine and dandy - but due to our database being 5 weeks late, and everything unraveling very nicely - feature additions like this are hard to come by/achieve in the timeframe given.
nevertheless - i started building a uniform data provider for the portal, which allows each storedProcedure call to go through it.
here I can then control which database is being used, and what is the associated syntax.
for example - all parameters i am loading into a hashtable which i process before execution and depending on the database put in the appropriate tags - such as "@" for MSSQL.
the next step is to install Oracle DB - to give it a go, and I will hopefully finish moving all the controls ' databinding and data calls to this new data layer.
there's now a formal panel whereby users can choose if they:
- want the gps to automatically connect
- want the the sending of co-ordinates to be automatic [given above succeeds]
- interval at which co-ordinates are sent
i also now provide the user with a friendly name of their gps unit
----
the the coveted sending of UUID to the phone - DONE. this has taken me the most.
as i had to extend Jargo and the submit page of the web server.
the workflow is now as follows - the user when adding a device, generates a 'ticket' - which is a word from a list of 14000 that i borrowed from the *nix dictionary file (anything that isn't alpha has been ripped out, as well as anything below 4 characters and longer than 8).
after a user generates this Ticket - it is put away together with a UUID generated for the users device into a table in the db.
this word the user can then enter into Jargo's settings - which proceeds to contact the server and receives the UUID.
This saves the user from entering 30 odd characters which are a combination of hyphens, letters and numbers - nothing worse for a mobile phone user.
---
i then provided a page for users of pda's and laptops - or anyone who has direct access and is able to with ease enter the uuid generated.
----
the following procedures were added tonight:
generateUUIDTicket - used by webserver to get the words
addUUIDTicket - used by webserver to append new tickets/uuid's
----
Database interoperability.
Daniel wants for us to implement the ability to switch between backends. All fine and dandy - but due to our database being 5 weeks late, and everything unraveling very nicely - feature additions like this are hard to come by/achieve in the timeframe given.
nevertheless - i started building a uniform data provider for the portal, which allows each storedProcedure call to go through it.
here I can then control which database is being used, and what is the associated syntax.
for example - all parameters i am loading into a hashtable which i process before execution and depending on the database put in the appropriate tags - such as "@" for MSSQL.
the next step is to install Oracle DB - to give it a go, and I will hopefully finish moving all the controls ' databinding and data calls to this new data layer.
posted by Anonymous at
00:35
0 Comments:
Post a Comment
<< Home