We are looking for an Android developer to design a system for us to track the deployment of a project and manage the deliverables due back to our client. We have a team of field technicians equipped with Android phones. Here is what we are looking for:
- Each Android phone shall pull a flat file (currently in Excel, could be CSV or whatever) that contains:
A unique site ID, an Address and perhaps other directory-type information, an Engineer name, and a date/time. This file only needs to be read, never written to. It can be made available by http or ftp, but we would like to be able to make changes to it.
- First screen is Technician log in. This can be a pop-up style box with options identified from the Technician column of the CSV file.
- Next screen shall give technician the option to select a site by either: a 2 or 3 digit numeric site id --or-- by choosing from a list of sites scheduled for that technician for today in date/time order. No data validation should be performed that would prohibit a technician from choosing another technicians site or a site that is not scheduled for the current date. A warning dialog box should display alerting that the site is not scheduled for today or for the logged in technician, but the technician should still be able to proceed.
Next screen should give Site Number, Site Name, Address and Directory information, and scheduled date/time. A button should allow the technician to check-in. The check-in feature should send an check-in e-mail to 1 or more e-mail addresses containing site specific information and the local check-in time. The exact addresses and formatting of this e-mail are to be provided later. Please let us know if it is easy to send this e-mail with a specific "from" address rather than the address stored in the Android. We can provide an SMTP server and authentication settings if necessary. We may wish to apply rounding rules to the check-in time.
Once checked in, we are in the deliverables collection area. This area will collect the following types of information: Check-box type items (Checked/un checked), radio button type options (Red, Yellow, Green), free text type options (example: 75), ability to capture approx. 3 photos and name these photos following either a static naming convention OR a combination of site id and static name. These photos should be able to be re-taken if necessary. Specifics on this section will be provided later.
Once the deliverables collection process is complete, an additional e-mail template containing site-specific information, information collected in the deliverables screen, and attached photos should be e-mailed to 1 or more e-mail addresses (similar to check-in). It should also include the check-in and check-out times. The check-out time would be determined by clicking a Complete button at the end of the deliverables collection. Some validation of data may be required (for example, that a photo was taken or that a number is greater than 0).
The site number that was completed should be stored on the device only for the purpose of allowing it to now be indicated as complete when the technician returns to their schedule.
Additional notes: the application should have options to force a new download of the schedule file from the http/ftp server. The application should have an Exit button. The menu option should have the ability to store several Speed Dial numbers that the phone would call. In addition to the download of the Schedule file, I would like you to discuss with us the feasibility of downloading a file with options information, such as e-mail addresses that information gets sent to, and names for the deliverables, etc. Basically, give us the ability to easily make minor changes. Expect less than 200 records and less than 10 sites per technician per day for the design of screens and planning purposes. A site listed as "Completed" should still be able to be entered again. This will be rare and the previous information should not be stored. It should be empty. We are looking to have a prototype to test with by April 9, 2010.