Mobile Application for Iphone

Job: Customer Service Case Submission Application
We require an experienced iPhone application developer with a demonstrable portfolio of work and good references to develop an application which will be used by clients of our company to submit and track customer service cases.
Our company uses salesforce.com for tracking customer service cases, and this application will make use of the salesforce.com web services API documented at http://www.salesforce.com/apidoc to create new Cases and to list and inspect existing open cases.
Application Details
Initialisation Screen
When a client signs up for our service they will receive a unique identifier which can be used to locate their Contact record in salesforce.com via the Web Services API. When the client first runs the application they will be prompted to enter this unique code, their postcode, and to set two application preferences:
• Password (nulls allowed)
• Submit Location With Requests (Boolean)
Their unique identifier, their postcode, and their two preference values should then be used to update their Contact record in salesforce.com via the web services API. Additionally, their unique identifier, password preference (i.e. whether they have set a password or not), and geolocation preference should be stored locally on the device. If a password is specified it should be encrypted using the best available algorithm present on the device before submission to the server. The password should not be stored on the device. If no password is entered this should be updated to their salesforce.com Contact record as a preference. If the unique identifier and postcode the user provided do not match a Contact record on the server, the user should be informed of the mismatch and given the opportunity to correct the values they entered. The warning message should not specify whether it was the unique identifier of the postcode which failed to match, just that the combination failed to match. The user should also have the option to exit the application without completing sign up in case they change their mind or are unable to enter consistent values for the unique identifier and postcode. If they do exit before this initialisation process is completed, then the initialisation process should resume when the application is next launched. All other errors such as a lack of internet connection should be reported to the user and handled gracefully as per standard procedures for the device. Once a user’s preferences have been successfully updated to the salesforce.com server, the user should move to the main application screen.

Login Screen
When the application is launched if the user has specified a password they should be prompted to enter it. It should then be encrypted and compared against the encrypted password value stored against their Contact record on the server. If they match, the user should proceed to the Main Application Screen. If there is a mismatch the user should be presented two further chances to correct their password. If they fail after three attempts they should be offered the opportunity to call the Customer Service desk on a number retrieved from the saleforce.com server via the web services API. If they accept this option the call should be placed. If they decline this option they can continue trying to enter their password up to 10 times, after which a web services call to the salesforce.com server should be used to mark their account as locked, and all further attempts to login should be denied, even if the correct credentials are supplied. The account can subsequently only be unlocked by a call to customer services where they will need to re-establish their identity. Alternatively, customer services will pick up on the fact that an account has been locked and call the customer directly to resolve the problem.

Main Application Screen
When the application is launched after having been successfully initialised, it should display the Main Application Screen. This screen should display a scrollable list of any open cases the user has, and a text area and submit button. If a user selects one of the open cases from the list, the details of that case should be displayed on the Case Details screen (see below). In the list, each case is represented by the date and time at which it was submitted, and the first few words from the body of the case message.
To submit a new case, the user enters text into the text area on the main application screen, and taps the Submit button. If their preference so specified, their location is detected, and then along with their Case details and unique identifier, used to create a new case for them in salesforce.com via the web services API. Once successfully submitted, a dialog should inform them that their case has been successfully submitted. When the dialog is dismissed they return to the main application screen where their new case will now be shown in the open cases list, and the New Case text area is cleared.
From the Main Application Screen it should also be possible to choose to view the Application Preferences, to place a call to the customer service desk on a number retrieved via the web services API, or to exit the application.

Case Details Screen
The Case Details Screen should display a scrollable log of customer-visible entries for the case as retrieved via a web services call to salesforce.com. The screen should also display below this a text area and Submit button which can be used to submit new case information in the same way as on the Main Application Screen. If an update is submitted a dialog should be displayed informing them of the successful submission and when this is dismissed, they should be returned to the Case Details screen where their new message will now have appeared at the bottom of the scrollable log, and the text-entry field will have been cleared. From this screen there should be the option to return to the Main Application Screen, to exit the application, or to call the customer service desk on a number retrieved by a web services call to the salesforce.com server.

Application Preferences Screen
The Application Preferences Screen should display the user’s unique identifier in a non-editable field at the top. It should also display an editable password field which is either blank if no password is specified, or is populated with asterisks (*) if one was provided. The password is never stored on the device. The screen should also display a checkbox preference labelled “Submit location with new requests”. At the bottom of the screen should be an Update button. When tapped, this should update the password and location preferences to the user’s salesforce.com Contact record via the web services API. Once updated the user should be shown a dialog informing them of the successful update. When dismissed they should then be returned to the Main Application Screen. The Preferences Screen should also have a Cancel button and an option to exit the application.

Additional Jobs
Blackberry Application Developer: We also require the same application to be developed for the Blackberry, and would welcome applicants that could deliver the application on both platforms.
iPad Application Developer: We require a simple form-submission application to be developed for the iPad which will be used to create new Contacts in our salesforce server. See separate job listing.