The Application will be used to synchronize groups of time sensitive PDF files between a web server and a remote device. Files are divided into two groups, "Directories" and "Procedures". Typically, a user will have a set of each file type on his mobile device. "Directory" files will expire on a 56 day cycle. "Procedure" files will expire on a 28 day cycle. The application should manage the storage structure of the files on the remote device, automatically check for the availability of new files, and handle the download process of new files.
The Application ("Synch App") described in this document will be used to synchronize groups of time sensitive PDF files between a web server and a remote device. Files are divided into two groups, "Directories" and "Procedures". Typically, a user will have a set of each file type on his mobile device. "Directory" files will expire on a 56 day cycle. "Procedure" files will expire on a 28 day cycle. The application should manage the storage structure of the files on the remote device, automatically check for the availability of new files, and handle the download process of new files.
The App is intended to run on an Android platform. The intended device has the specifications outlined below, however, the application is expected to be ported to other Android platforms and **must be** designed to accommodate this.
**Internal Memory:** 4 GB (3 GB for user)
**LCD Touchscreen Display Size:** 1024 x 600 (10.1")
**Operating System:** Linux with Google® Android®
**Screen Rotation:** 90 and 180 degrees
**Connectivity:** WiFi [url removed, login to view] b/g, Bluetooth capability, 3G (future availability)
**Mobile Modem (optional):** EVDO or HSDPA
**External Memory:** SD card slot, 2 USB ports
**Input:** Stylus input. Virtual keyboard. Bluetooth and USB keyboard (optional)
**Web Server File Storage**
Presently, the files are stored on a web server running IIS 7. Files are made available for download over FTP and HTTP. Most likely, a dedicated directory would be set up and made available to the Synch App. A SQL Server database that is accessible over the internet contains tables with information about the current cycle of files. This table contains the effective dates of each cycle for both types of files. A second table contains information about each individual file, including the name of the file and the path information needed for download. Custom tables could be developed and pulished for the Synch App. Any queries or stored procedures required by the app will be provided - the developer shall specify his requirements. Database programming is not part of the developer's scope, unless a SQL Server database platform is not suitable.
Typical size: 20-40 MB
Typical size: 100-200 MB (some as small as 3 MB but this is not normal)
It is anticipated that some users will wish to keep all files on their device, but some users will only want a subset of the information. Total size of all files is around 4.1 GB. Due to limitations of the intended device, it is expected that the files may be stored on an SD card or USB memory.
Typical users are male in the range of 25 years of age to 60 years of age. The user will have some technical ability but will not necessarily be savvy with modern computing platforms. Consideration should be given to font sizes and buttons, as some users may have near vision limitations (not visually impaired, per se, but "old eyes" - there is no specific requirement around this, it is just a consideration for the developer).
There could be several thousand unique users, though not all of them will be synchronizing data at the same time. Each user has a unique user name and password that is authenticated against a table in the SQL Server database. For the short term, a max of 1000 unique users should be considered a good estimate.
**Synch App Requirements**
The requirements defined in this section will be tested prior to acceptance of the application. As part of the quotation, the developer should list specific features that he is not able to provide.
1. Clean, simple user interface that uses intuitive menus and navigation (developer and customer shall agree on screens and menus prior to detailed programming)
2. Store the user's credentials and customization settings on the local device or in a database profile (local where practical)
3. Authenticate the user upon startup (user name and password supplied to stored procedure, integer return code for valid, invalid, expired subscription)
4. Present user with a list of available files for each file type (Directory and Procedure)
5. Check web server for most recent files (customer can provide a stored procedure with a list of file names)
6. Check local device for the most recent files
7. Retrieve new files from the web server
8. Delete old files from local device (user is given option for this to be automatic or manual)
9. Handle a user's 'favorite' files so they do not have to manually choose files each time (user favorites can be stored on database server, customer can provide stored procedure with this information for each user)
10. Handle errors in the download process - if the download fails, retry it automatically.
11. Notify user if any files could not be updated.
12. Notify user if any local files are expired.
Most of the functionality described above has already been developed for a Windows desktop application. Algorithms and code can be provided as examples for the developer, however it is expected that the developer will need to start from scratch.
Upon acceptance, all source code shall be provided to and become the property of the customer. It is expected that the developer will fully comment the code and use a standard naming convention for all procedures and variables.
Hardware will not be available until early 2010. However, it is desired that development begin as soon as possible so that testing may begin when the hardware is released. It might be possible to obtain demo hardware for short periods of time for user interface testing. Developer can expect to have a loaner device for testing sometime in February 2010.