Challenge Overview
Project Overview
Our partner is developing a state-of-the-art tablet based sales and order processing tool. Their sales team will be managing client visits, tasks, calendars, notifications, and order processing all through this tool. The platform is the Apple iPad. Want to learn Swift? Great - why not get paid for it, we need your help! There will be a long series of challenges over the coming weeks leading to the final product, so get involved now!
Setup
In order to obtain the code source to modify for this challenge, you will need to be added to the UNI-Mobile github repository. Make a request for access in the forums.
This contest will not require you to do any direct work with the Salesforce Mobile SDK, but it is a required element of the overall application. As such you will need to be able to login to Salesforce the first time you run the application in order to access the other components of the application. The credentials are as follows:
-
Username
-
cu@tc.com
-
-
Password
-
TCContest1
-
Again, you will not be required to utilize the Salesforce Mobile SDK for any of the customization you are doing in this challenge. But the application leverages it, so logging in is essential.
This contest will require you to hook into the AccountViewController’s Fit Session checklist item button. To get to the Account screen, you will need to log into Salesforce with the provided credentials. This will take you to the Homepage, which has a Calendar. There should be a Meeting (EventsTableViewCell) in that calendar. When you tap on that it will expand, and tapping the Person Icon will take you to the Account Screen.
Contest Requirements
For this contest you will be tasked with building two new modal modules for the UNI-Mobile application. For these modules you will create the screens for our lead management functionality, and our approval management. These screens will have two slightly different sets of functionality, depending on if the user is a Sales Manager, or a Seller. For the purposes of this project, please ensure that you provide a means of designating which type is needed in the code.
Detailed Requirements
Leads Modal - Both User Types
At the top of this modal, above the accordion, should be a “+ New Lead” button. When this is pressed display another modal over top of this one that shows a webview pointed at “http://www.salesforce.com”. The actual functionality will be implemented in a later challenge.
This modal screen makes heavy leverage of our existing Accordion UI element. You’ll need to modify this element such that it supports the ability for rows to have number indicators for showing how many leads are in that section. If the number 0 is sent to this element, do not show this indicator on that section. The indicator, when the section is not the active accordion section will need to be white with red text, and when the section is active it will need to be red with white text.
The actual content of each of these sections will need to be shown as a TableViewController with sortable columns. Each row should have a column for the name of the company, the owner of the lead, the company’s phone number, the zip code of the location, date added, Action, and a Done button. All columns except Action and Done should be able to be sorted. Done should not have a column header.The column headers of the table should be rendered at 50% opacity in the standard iOS 8 blurred style. Text in columns should truncate with an ellipsis (. . . ) if it would cause the text to extend into the next column. Show full text in our standard tooltip (same tooltip style across application) on tap and hold and should disappear on release.
When a row is tapped, the row should expand to show additional details about the lead as depicted in the mockup. Expanding a row should cause the currently expanded row to collapse. These fields are subject to change, but please include the Primary Contact name, the Title of the primary contact, their email, an indicator of whether this lead was signed up for emails, the address of the lead, Industry, # of Employees, Source of the lead, Description of the lead, comments of the lead, The campaign this lead is associated with, Reason we’re contacting the lead, and then suggested services to sell them. Show full text of Description and Comments in our standard tooltip (same tooltip style across application) on tap and hold and should disappear on release.
The Action drop-select should behave like all other drop-selects in the application. The selectable options should be “Convert to Account”, “Pass to Manager”, “Pass to Marketing”, and “Kill It”. When the user taps done perform the following actions based on the Action selected:
-
“Select Action”
-
Nothing
-
-
“Convert to Account”
-
Bring up a ModalViewController with a webview pointed at “https://www.salesforce.com”
-
When the modal returns from that modal, remove this row from the table.
-
-
“Pass to Manager”
-
Bring up a MFMailComposeViewController and prepopulate the text of the email with the details of the lead object.
-
On send of the email, remove the lead from the table.
-
-
“Pass to Marketing”
-
Remove the row from the table.
-
-
“Kill It”
-
Present confirmation dialog: “Are you sure you want to kill this lead? This cannot be undone.”
-
If Yes - remove the row.
-
Else - Do nothing.
-
This modal will be the same for Sellers as it is for Managers.
Approvals Modal - Manager
This modal screen will use the same sortable table structure you used in the Leads modal above. Unlike with that table, there is no expanded view of these table rows.
Each row should have an Account Name column, a Type Column, Submitted Date, Seller Name, Status, and Notes. All should be sortable except Notes.
The name data (blue link) will trigger a second modal sliding up from the bottom to cover this modal, containing external PDF content. For now, display the CoreValues pdf that is displayed on the Seller Home page.
The Status column will require you to create a 3-state UISwitch. The left state should color the bar black, and display an “R” in the circle. The middle state should have no letter in the circle, and should use the default inactive gray for the bar color. The right state should color the bar blue and put an “A” in the circle. In order to move from the “R” state to the “A” state, or vice versa, the user must move to the middle state first. When sorting this column - in ascending the middle state should be sorted to the top, then the “A” state, then the “R” state. Use the opposed in descending sorting.
The notes icon should be gray if no notes exist, and blue if notes have been input on the record before. When the user taps the notes icon they should be presented a small UITextArea in a UIPopover view that they can use to input notes. If they cancel, hide this view. If the save button is hit, add the notes to the Approval record and dismiss the view. Do not dismiss this view unless it is canceled or saved.
If the user has changed the state of the status or input notes, the Done button should be presented with Red text, indicating that the user has not yet finished modifying the approval. If the user tries to close the modal and there are any outstanding rows, present a dialog that says “Are you sure you want to leave the screen without completing your work? Unsaved progress will be lost.” If they tap Yes, dismiss this modal and don’t save the modifications. Else, do nothing.
When the user taps “Done”, call a save function, which should return the DONE text to the inactive gray color.
Approvals Modal - Seller
Largely the same as the Manager version. The changes are as follows:
The Name column is no longer tappable to reveal the PDF of the document to be approved.
Rather than a “Seller” column, there is now a “Reviewer” column. Tapping on this icon should bring up an MFMailComposeViewController with the recipient listed as the Reviewer’s email address.
The status column here will be plain text. Approved, Rejected, or Pending. Sort the same as above, with Approved corresponding with the “A” state, Pending being the middle state, and Rejected corresponding with the “R” state.
There should be no done button.
If the Approval has Notes, display the blue text icon. Do not display an icon if no notes are there. When tapped display the tool-tip popover that displays the full text of that note. The user can either tap outside of the popover or on the X to close this popover.
There is also now a “Reviewed” column, which corresponds with the date that the manager approved or denied this approval request. The mockup improperly has the submitted column as being able to have empty values, it should be this column instead.
General Guidelines
The Data Model objects referenced in this challenge should all be created in the Model subproject within the UNI Repository. If you have any questions, please ask in the forums, we will help you determine if additional objects not pre-built may be necessary.
“?” icons will trigger tooltips (style defined previously) with two sentences of lorem ipsum (to be edited later).
When removing a row from a table, use a fade animation.
For this challenge if you would like to pull in third party form generation frameworks, that is allowable in order to satisfy any requirements asking for ease of configuration or reusability. If you do incorporate 3rd party frameworks for the construction of these forms, please ensure that these frameworks are Open Source software, and are available with an MIT or similar distribution License. Code submissions that use 3rd party frameworks will be judged based on the ease of use and extensibility of those frameworks.
Environment Setup
GIT: The project will use a code repository at Github, please see additional details and participant responsibilities under Submission Guidelines.
Xcode: All code development should be done in Xcode 6.1 and tested in the simulator.
Framework: Code should be developed with the Cocoa Touch framework using Swift and must compile against iOS SDK 8.0 with a deployment target of iOS 7.1.
Get Started
- Request access to the project in the challenge forums
- Fork this project: git@github.com:cloudspokes/UNI-mobile.git
- Checkout this branch: https://github.com/cloudspokes/UNI-mobile/tree/workstream5-leadsapprovals
- Write and submit your code as a zip file
Final Submission Guidelines
Submission Guidelines
- Cocoa Touch framework Xcode 6.1 project with well commented code
- Code must compile against iOS SDK 8.0 with a deployment target of iOS 7.1
- Upload all source projects as a zip
- After submission phase has completed, make a pull request targeting this branch
- Provide documentation of any special configuration required to run your code.
GIT Guidelines and Requirements
All code for this project will be maintained at Github. Challenge participants will have to request read-only access to the repository during the challenge and are expected to fork and do their coding on the challenge branch. Once contest submission closes, the project owner will update the code in the challenge branch to reflect the current state of development. The winner of the challenge will then be required to update their fork to the current state of the development repository and will be responsible for handling merge conflicts when updating their fork. They will then create a pull request.