You have chosen to sponsor your bid up to a maximum amount of .
We have an app we've developed (go to Google Play and search on "Hyper-Reach" to download existing app.
We want this app converted to iOS.
The App, and all its ancillary components provides the following utility:
1) Registers locations for emergency notification calls
2) Provides Emergency personnel with a real-time update on user’s location
3) Allows user to be notified of emergency alerts for other locations, such as family, friends, and business offices
4) Tracks phone location in case it’s lost or stolen
5) Lets you originate alerts to family and friends (later version).
The system is comprised of 3 major active components:
1) The phone application
2) The central server (CS) that communicates with the phones
3) An administration portal that allows management and configuration
The app interacts with a Linux server running Java and sends/receives data from the server.
We will supply the source code of the Android app which can be used to see the algorithms used for certain operations.
Here is a description of those operations:
The Phone Application has both a user interface and a component that runs as a background service. The background service maintains communication with a central server. The App will maintain the following data:
1) Its own configuration information (e.g. splash screen sponsor, addresses)
2) The non-deleted alerts
3) Current location data
Smart Phone App - User Interface
The User Interface registers the device to a particular community (e.g., customer)
The UI enables the user to manage multiple locations of interest (home, work, etc.)
The UI enables the user to manage the interval of alert retrieval as well as what action to take when an alert is received (play sound, vibrate).
Smart Phone App - Background Process
The background service runs continuously while the phone is powered on, and performs the following tasks:
1) It performs all direct communication with the CS, starting with the initial device registration
2) It transfers (uploads) address information gathered by the UI to the central service.
3) It updates local configuration information from the CS (at startup).
4) It receives sponsorship information
5) It polls for alerts
The background service polls the central service periodically. This will be a bandwidth efficient protocol that requests any active alerts. Each alert will contain the geographic boundaries to which it applies. The SmartPhone App compares that information with its own location and the locations in its configuration, then puts up a message on the phone if one or more apply.
The alert displays immediately and briefly on the screen, then leaves an icon in the device’s notification list.
The Administrative Application will manage data by directly manipulating the Local CS database.
SmartPhone App Background Process to Central Server
Register – I’m a new user, should happen once to assign a device ID.
Startup – I’m alive, should happen every time the phone powers up with the App enabled.
Address check – sends 1 location that the user configured on the phone in order to assign a customer ID to it.
Poll for new alerts – requests any new alerts since the last poll.
A full design document will be provided to the winning bidder. Confidentiality agreement required on bid acceptance.
Maximum initial milestone will be 50% of total bid. Nothing released until beta version is provided for initial review. Full payment will not be released until fully tested app is accepted. The application must work at least as well as the APK running on Android 4.0.
Deliverables must include commented source code.