System Overview - Revision history

Anw at 13:42, 6 June 2013

2013-06-06T13:42:08Z

Anw: /* PDA Client */

2013-06-06T13:18:04Z

PDA Client

← Older revision		Revision as of 15:18, 6 June 2013
Line 255:		Line 255:

	====Login====		====Login====
	Application Start		* Application Start
	PreStart Checks		** PreStart Checks
	IF first login		*** IF first login
	*Android		**** {{PDAType\|Android=Y}} Open Config Form
	Open Config Form		**** {{PDAType\|WinMo=Y}} IF Config XML file exists
	*~~WM6.5~~		***** Send Grace Login Request
	IF Config XML file exists		**** ELSE
	Send Grace Login Request		***** Open Config Form
	ELSE		*** ELSE
	Open Config Form		**** Load User Data (DBConnection.cs and Program.cs)
	ELSE		*** Open Login Form
	Load User Data (DBConnection.cs and Program.cs)		*** {{PDAType\|Android=Y}} Wait for Login or Config
	Open Login Form		**** IF Login
	*Android		***** Send Login Request
	Wait for Login or Config		***** Perform Local Login
	IF Login		***** IF Success
	Send Login Request		****** Open JobList Form
	Perform Local Login		***** ELSE Prompt
	IF Success		**** IF Config
	Open JobList Form		***** Open Config Form
	ELSE Prompt		*** {{PDAType\|WinMo=Y}} Wait for Login
	IF Config		*** Perform Local Login
	Open Config Form		*** IF Success
	*~~WM6.5~~		**** IF User ADMIN
	Wait for Login		***** Open Config Form
	Perform Local Login		**** ELSE
	IF Success		***** Send Login Request
	IF User ADMIN		***** Open JobList Form
	Open Config Form		*** ELSE Prompt
	ELSE
	Send Login Request
	Open JobList Form
	ELSE Prompt

	====Job List====		====Job List====
Line 315:		Line 311:
	===GUI===		===GUI===
	Both device work on the principles of a card stack. Each form or window will open another and on exiting of a window will refresh the data it is currently displaying showing any modifications. (You need to beware that this means you are holding the previous window open in memory and on some** devices this is limited).		Both device work on the principles of a card stack. Each form or window will open another and on exiting of a window will refresh the data it is currently displaying showing any modifications. (You need to beware that this means you are holding the previous window open in memory and on some** devices this is limited).
	Each Form or Window will run some ~~setup~~ either both loading or at the point of loading which will ~~setup~~ any user or background controls, as well as ~~gettting~~ any data from resources it may need.		Each Form or Window will run some set-up either both loading or at the point of loading which will set up any user or background controls, as well as getting any data from resources it may need.
	Once at this point all interaction is user driven (other than ~~seperate~~ timed processes).		Once at this point all interaction is user driven (other than separate timed processes).

	===Communications===		===Communications===
Line 344:		Line 340:

	====WM6.5====		====WM6.5====
	The WM6.5 client uses the standard build in soap calls to VS2008. This allows you to add the ~~serivce~~ as a webmethod within the project and reference it as a standard method.		The WM6.5 client uses the standard build in soap calls to VS2008. This allows you to add the service as a webmethod within the project and reference it as a standard method.

	===Photos===		===Photos===
	The photos function on both phone utilising the native camera application, the image from this is then compressed to a .JPEG image, converted to base64 and stored within the database in this format. From the database they can then be transmitted to the server.		The photos function on both phone utilising the native camera application, the image from this is then compressed to a .JPEG image, converted to base64 and stored within the database in this format. From the database they can then be transmitted to the server.

	~~====WM6.5====~~		The client post version 1.31.1.0 will now attempt to split images over 50kb into chunks to send back to the server. Upon job completion and cancellation, the job object is passed to the process photos function which will recursively check the job hierarchy for photos. If any photos are present they are loaded into a photo object and the data of the photo is split into chunks and each chunk written to a photo request message.
	The ~~WM6.5~~ client post version 1.31.1.0 will now attempt to split images over 50kb into chunks to send back to the server. Upon job completion and ~~cancelation~~, the job object is passed to the process photos function which will recursively check the job hierarchy for photos. If any photos are present they are loaded into a photo object and the data of the photo is split into chunks and each chunk written to a photo request message.
	~~Alternatively in versions pre version 1.31.1.0 this is the same process but sent in a one shot message within spliting the image into chunks~~.

	~~====Android====~~
	~~The android client uses the mechanism used in WM6.5 pre version 1.31.1.0.~~

	===GPS===		===GPS===

Milesl: /* Photos */

2012-10-17T10:59:39Z

Photos

← Older revision		Revision as of 12:59, 17 October 2012
Line 356:		Line 356:
	The android client uses the mechanism used in WM6.5 pre version 1.31.1.0.		The android client uses the mechanism used in WM6.5 pre version 1.31.1.0.

	====~~Android~~====		===GPS===
			The Android client writes a GPS_STATUS_REQUEST to the pending data table once every X seconds.
			This is done through a timer on the device which will fire a method to retrieve the GPS Lat and Long and then write the following message to the pending data table:
			<GPS_STATUS_REQUEST ID="X" GPS_STAMP="Lat,Long">
			<EPL_LOAD_ID></EPL_LOAD_ID>
			<EPL_VEHICLE></EPL_VEHICLE>
			<REQUEST_TIME_DATE></REQUEST_TIME_DATE>
			</GPS_STATUS_REQUEST>

	==Development Tools List==		==Development Tools List==

Milesl: /* Job List */

2012-10-17T10:05:05Z

Job List

← Older revision		Revision as of 12:05, 17 October 2012
Line 300:		Line 300:
	*Android		*Android
	START GPS Timer		START GPS Timer
			AUTO-UPDATE timer fires
			Send Load update request
			If Updates
			BIND Updates to Job List
			IF User Selects Job
			Open Job Detail
			On Close
			IF Check for load with uncompleted (Status I & P) jobs on local DB == FALSE
			PROMPT for more work
			SEND Load Request or Exit
			ELSE
			BIND GET * JOB DATA to Job List

	===GUI===		===GUI===

Milesl: /* PDA Client */

2012-10-17T09:57:34Z

PDA Client

@@ Line 288: / Line 288: @@
          Open JobList Form
        ELSE Prompt
 ===GUI===

Milesl: /* Process Flow */

2012-10-17T09:44:09Z

Process Flow

← Older revision		Revision as of 11:44, 17 October 2012
Line 253:		Line 253:

	===Process Flow===		===Process Flow===

			====Login====
	Application Start		Application Start
	PreStart Checks		PreStart Checks
	IF first login		IF first login
			*Android
			Open Config Form
			*WM6.5
	IF Config XML file exists		IF Config XML file exists
	Send Grace Login Request		Send Grace Login Request
Line 283:		Line 288:
	Open JobList Form		Open JobList Form
	ELSE Prompt		ELSE Prompt




	===GUI===		===GUI===

Milesl: /* PDA Client */

2012-10-17T09:40:08Z

PDA Client

@@ Line 251: / Line 251: @@
 ==PDA Client==
 ePOD system current has two PDA clients Windows Mobile and Android. These both have local databases and communicate to the centralised server using the pre-specified web services.
 ===GUI===

Milesl: /* PDA Client */

2012-10-17T09:18:02Z

PDA Client

@@ Line 284: / Line 284: @@
 ====WM6.5====
 The WM6.5 client uses the standard build in soap calls to VS2008. This allows you to add the serivce as a webmethod within the project and reference it as a standard method.
 ==Development Tools List==

Milesl: /* PDA Client */

2012-10-17T09:02:17Z

PDA Client

← Older revision		Revision as of 11:02, 17 October 2012
Line 278:		Line 278:
	This uses the same mechanism as Send and Wait. A timed process is started on the device that reads data from the Pending data table in the local database (this will contain XML written to it for job updates ect), if a records is found then it will send the data to the server and await a response. Once receieved the data will then be removed from the local database and the next record sent.		This uses the same mechanism as Send and Wait. A timed process is started on the device that reads data from the Pending data table in the local database (this will contain XML written to it for job updates ect), if a records is found then it will send the data to the server and await a response. Once receieved the data will then be removed from the local database and the next record sent.
	To conserve battery (timers are a expensive resource) the timers are only started when data is written to or existing in the table, once all data is sent they are shutdown until the next record is written.		To conserve battery (timers are a expensive resource) the timers are only started when data is written to or existing in the table, once all data is sent they are shutdown until the next record is written.

			====Android====
			Android uses a modified suds.js (Suds2.js) client (https://github.com/kwhinnery/Suds). This is a javascript implementation of SOAP. This has been modified in the invoke method to handle our webservices.

			====WM6.5====
			The WM6.5 client uses the standard build in soap calls to VS2008. This allows you to add the serivce as a webmethod within the project and reference it as a standard method.

	==Development Tools List==		==Development Tools List==

Milesl: /* GUI */

2012-10-16T16:12:19Z

GUI

← Older revision		Revision as of 18:12, 16 October 2012
Line 253:		Line 253:

	===GUI===		===GUI===
	Both device work on the principles of a card stack. Each form or window will open another and on exiting of a window will refresh the data it is currently displaying showing any modifications. (You need to beware that this means you are holding the previous window open in memory and on some devices this is limited).		Both device work on the principles of a card stack. Each form or window will open another and on exiting of a window will refresh the data it is currently displaying showing any modifications. (You need to beware that this means you are holding the previous window open in memory and on some** devices this is limited).
	Each Form or Window will run some setup either both loading or at the point of loading which will setup any user or background controls, as well as gettting any data from resources it may need.		Each Form or Window will run some setup either both loading or at the point of loading which will setup any user or background controls, as well as gettting any data from resources it may need.
	Once at this point all interaction is user driven (other than seperate timed processes).		Once at this point all interaction is user driven (other than seperate timed processes).