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
-
Password
-
newuser@123
-
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.
Ordinarily navigation to this screen would happen from the Set Up screen, however, due to that being a work in progress, for the purposes of this contest please display the Build Invoices screen when Fit Session is selected from the Account Screen.
Contest Requirements
For this contest you will be asked to create the Build Invoices screen based on the mockup provided.
This screen is composed of three Primary sections - The Header, The Content Area, and the Footer.
In addition there are 3 additional Modals to create and display - Create New Invoice, Edit Invoice, and Invoice Review.
Detailed Requirements
The Header
Should display the text “Build Invoices” followed by the name of the Account in Italics below it.
-
Review & Mark Complete button
-
When pressed display the Invoice Review Modal.
-
-
The “+ New Note” button
-
This button should display an additional Modal over top of it, used for creating new Notes on the Account associated with this Fit Session.
-
TODO: Get WS3 UI Prototypes merged in so we can repurpose that UI.
-
The Footer
This should consist of one button that says “Save & Go Back to Set Up”, which should have an associated Save function, and should close this modal when pressed. It should also have a “Show Tips” text indicator, which should display the Show Tips overlay.
Show Tips
This is a very basic static overlay, that you will need to build to match the visual mockup that has been provided. The overlay should cover the entire screen, including the global menu. It should be a darkened semi-transparent screen, with custom views scattered through it to provide helpful text about using the set-up screen.
While displayed, a tap anywhere on the screen should cause the overlay to hide. This tap should not pass through to any elements below the overlay.
The Content Area
The Content area is composed of two columns - the Department/Wearer Table View and the Invoice Table View.
The Department/Wearer Table
The Department/Wearer Table is composed of all Departments that have wearers. The Departments should be rendered as Table Sections, with Wearers rendered as Cells underneath that section. All Wearer Table Cells should be tappable to reveal a Table of Order Items associated with that Wearer (display the name of the Order Item’s Product).
The Wearer cell should listen for a drag-gesture and be able to be dragged to an invoice in the Invoice Table View on the right hand column. When dragged there, the Wearer should be hidden from the Table as it can no longer be associated to another invoice.
Likewise, the Department header should be able to be similarly dragged, and when this occurs, it should add all Wearers associated with that department to the invoice, and hide the Department and its Wearers from the Department/Wearer Table View as they can no longer be associated with another invoice.
The exception is Facility Services, which is a special case Wearer that is part of a Department of the same name. All “Non-Personnel” type Products should be defaulted to the Facility Services Wearer. This section should be rendered with Facility Services as the Header, but the child cells should not be able to expand to reveal any children.
If an item from Facility Services is dragged to an Invoice, create a new Facility Services Wearer and Department or if one already exists, use the existing Facility Services Wearer/Department for that Invoice, and add a new Order Item to that Wearer for the selected Product. The quantity should default to the defaultQuantity of the product. It should not be hidden, as it can be associated with another invoice. If the Facility Services header is dragged, do the same, but add all Products as Order Items.
The Invoice Table
This table should display all Invoices associated with the Fit Session.
Invoice Cells should display a Header displaying the Name of that Invoice, as well as an Edit Button. When Tapped, the Edit button should display the Edit Invoice modal, with all fields and tables pre-populated with data from the Invoice object.
Beneath the header of the cell, should be the sub-header which displays information about how the invoice is broken down. You should flesh out the departmentCount, wearerCount, and productCount computed fields such that they provide the correct number of unique departments, wearers, and products associated with the Invoice so that this section can utilize those numbers.
Just after the sub-header, the address of the invoice should be displayed in smaller type.
Then the Drag Recepticle area should be rendered. If any items dragged from the Department/Wearer table are dropped here, process the item appropriately. Add the appropriate Order Items to the Invoice, and update the counts of unique Departments, Wearers, and Products.
The final cell of this table should be the “+ New Invoice” cell. When tapped, display the Create New Invoice Modal.
Create New Invoice
This screen should provide the user with some basic Invoice property fields to set for creating new invoices. The Name, and necessary Address fields.
If the user taps the “X” or Cancel close this modal without creating a new Invoice.
If the user taps the “Save” button, close this modal and create a new Invoice object with that name in the Invoice Table View described above.
Edit Invoice
When loaded, this screen should pre-populate the fields from the chosen Invoice. This page should maintain a copy of that invoice until changes are saved. This screen should provide the user with the basic Invoice properties to modify - Name and Address.
Additionally, it should provide an additional column that is “Products Included” and a table detailing the Departments, Wearers, and Products associated with the Invoice.
They should be rendered exactly as above, except that they should have X buttons on the cells to allow them to be removed from the Invoice.
-
X Pressed on Department
-
Remove all Order Items associated with that Department, as well as their wearers.
-
-
X Pressed on Wearer
-
Remove all Order Items associated with that Wearer, and the Wearer itself.
-
DO NOT RENDER X ON WEARER PRODUCTS THEY CANNOT BE REMOVED SEPARATELY FROM THEIR WEARER. THIS WAS AN ERROR ON THE DESIGN.
-
-
X Pressed on Facility Services
-
Remove all Order Items associated with Facility Services, as well as the entire Facility Services section.
-
-
X Pressed on Facility Services Products
-
Remove that Order Item from the Invoice, and but not the Facility Services wearer or department.
-
-
For all X’d items, when tapped, display a confirmation alert "Are you sure you want to remove this item?" before removing the item from the Invoice.
Again, Facility Services will be an exception here. In addition to the difference in behavior described above, the user can also modify the quantity of a Facility Service Order Item on this screen. This field should take only a numeric value.
-
When Cancel or “X” is tapped
-
If user has edited any fields or removed items from the invoice
-
Display an “Are you sure you want to cancel?” confirmation dialog before closing the modal.
-
-
Close the modal without saving changes
-
-
When Save is tapped
-
Overwrite the pre-existing Invoice object with the changes, and then close the modal.
-
Invoice Review
This screen should show a Collection of Invoices with the Department/Wearer Tables displayed underneath the Header and Subheader of the Invoice Cell. By Default these cells should have all Departments collapsed, and can be tapped to expand and show the Wearers, which can in turn, be tapped to display their Products. Facility Services remains an exception, which should expand to show all Products and their Order Item quantities in their table cells, as depicted in the mockup.
This screen should display two columns of Invoices and scroll vertically should any overflow happen.
If the “X” button is tapped, cancel this modal by closing it.
If the “Mark Fit Session Complete” button is tapped, present a confirmation dialog saying “Are you sure that you want to mark this fit session as complete?” If they confirm, close this modal, and all subsequent modals to return to the Account Screen.
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).
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.1 with a deployment target of iOS 7.0.
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/fit-session-invoice-ui
- 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.1 with a deployment target of iOS 7.0
- 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.