UNI - Sales Portal iPad iOS Swift Account Phases prototype - realworldswift

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
  • uniapi@tc.com
• 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.

 

Contest Requirements

For this challenge you will be required to build out the AccountViewController screen for this application. This is the screen that will supply information about the accounts and any related objects. There are 4 major components to this screen, as detailed in the sections below.

 

The Account Header

This header is a pretty major departure from the headers on all other screens of the application. Please ensure that it is built to match the mockup, and fulfills the following requirements:

• The header should respond to the change in available space when the Global Menu goes between ICONS_ONLY and FULLY_CLOSED states.
  • When this occurs have the spacing between the 5 action buttons be reduced.
  • Maintain equal spacing between the action buttons
  • The total space reduction when in ICONS_ONLY is a difference of 38 pts.
• The data depicted within the header should come from an instance of the Account model object.
  • Account.name should go where “Samual Adams Brewing Company, LTD” is in the mockup.
  • The quick info line below the name is composed of the” Account.incumbent | (Account.ced1 or “No CED”) | Account.Industry”
  • Address Line 1 + Suite Number + Phone Number should be displayed on two or three lines depending on the existence of a Suite #.
    • Vertically center the text here
  • The 5 action buttons should be displayed as Buttons without text, but with images
    • When the Phone icon is tapped display an alert that says “Now Calling - \(Account Phone Number)”
    • When the Map icon is tapped, pull up a ModalViewController with the Account.name as the title, and a content area that is a UIWebView pointed at the URL “http://www.salesforce.com”
    • When the Computer Monitor icon is tapped, pull up a ModalViewController with the Account.name as the title, and a content area that is a UIWebView pointed at the Account.website URL.
    • When the LinkedIn icon is tapped, pull up a ModalViewController with the Account.name as the title, and a content area that is a UIWebView pointed at the URL “http://www.linkedin.com”
    • When the Google+ icon is tapped, pull up a ModalViewController with the Account.name as the title, and a content area that is a UIWebView pointed at the URL “https://www.google.com/#q=\(Account.name)”
      • When populating the Google URL please properly URL Encode the Account name by using “.stringByAddingPercentEncodingWithAllowedCharacters(.URLHostAllowedCharacterSet()”

 

The Left Sidebar

This sidebar is different from the other left-hand sidebars that are contained within the application in that it cannot be closed. But there are some new elements that need to be built to satisfy the requirements of this challenge. Please create a static sidebar element that fulfills these requirements:

 

• There are two sub-sections that need to be built with a modified form of LeftTableViewController’s LeftTableCell.
  • The Account Phase Table
    • This should have a different Title depending on the Account.stage.
      • Approach
      • Discovery
      • Present/Close
      • Install Prep
    • The following items should use the standard LeftTableCell for display, and bring up a ModalViewController when tapped. They will appear regardless of the Account.stage
      • Create Quote
      • Sales Tools
      • Presentations
      • N.A. Materials
      • Large Account Planning
    • The following items should appear according to the Account.stage value. They should be rendered as a grey version of the LeftTableCell, and always at the top of the Account Phase table. When tapped they should bring up a ModalViewController.
      • Approach
        • Closest Customer
      • Discovery
        • Discovery Worksheet
        • Site Assessment
        • Closest Customer
      • Present/Close
        • Transition Schedule
        • Closest Customer
      • Install Prep
        • Transition Schedule
        • Install Roadmap
        • Pre-Install Meeting
  • The Checklist Table
    • This will have the same items regardless of phase.
    • The elements here should be white like the LeftTableCell, but should be configurable to have checkmarks display in them.
    • For the purposes of this prototype, when a user has tapped to view these documents, set them to checked. Never uncheck them.
    • These items, regardless of whether they are checked or not, should display a ModalViewController when tapped.
    • These items are:
      • Credit Check
      • Soil Evaluation
      • Emblem
      • Service Agreement
      • Fit Session

 

The Right Sidebar

There are two components to the right side bar. A simple button that says “Take Next Steps”, which is a bright blue color, and displays a ModalViewController when tapped. The other component is the “Know, Say, Show” accordion and it should work as follows:

• These will function as an accordion-style UI element.
• Section titles are displayed as horizontal bars with the Slate color when in the inactive state.
• When the section headers should show this behavior:
  • Initially the background should fade to red.
  • Once fully red, the tapped item has become active, the background should then fade to white, and the text to Red.
  • If the new item is below the previously active item
    • In approximately half a second, the Active Item should slide itself, and the items stacked prior to it to the top of the container.
      • If items are already stacked at the top of the container, do not animate those items.
  • If the new item is above the previously active item.
    • The previously active item should slide down to the lowest extent that it can.
      • Its bottom edge should meet the top of the item below it in the list.
      • If there is no item below it in the list, it should line up with the bottom of the container.
  • While the Slide animations occur, the internal container of the previously active Accordion Section should be hidden, while the new one is revealed beneath the new active header.
  • Simultaneously to this animation process, the previously active header should fade from white background to the slate-colored background, and its text from red to white.
• Each section header should be associated with an internal content area that represents its content.
  • When not active, the internal content area of that section should not be rendered, and should not receive any tap gestures or selections.
  • Each content section will be a TableView of links.
    • These links may be one or more lines of text. Adjust their sizing accordingly to fit all the text.
    • When any item in a central content area is tapped a ModalViewController should slide up from the bottom of the screen.
• The three sections inside this accordion should be as follows:
  • Know
  • Say
  • Show

 

Because the next section of the application will also be utilizing the Accordion View standard, please write this as a resusable and configurable View Controller that accepts multiple sections, and a specified ViewController for each section.

 

The Central Accordion

The Central Content area of the Account screens should be an accordion, that functions much like the one described in the “Know, Say, Show” section of the right sidebar. Please make it function as follows:

• Section titles are displayed as horizontal bars with the Slate color when in the inactive state.
• When the section headers should show this behavior:
  • Initially the background should fade to red.
  • Once fully red, the tapped item has become active, the background should then fade to white, and the text to Red.
  • Simultaneous to this, the Active Header should expand to the active header size shown in the mockups.
    • Please make the Active Header size configurable when setting up the accordion view.
  • If the new item is below the previously active item
    • In approximately half a second, the Active Item should slide itself, and the items stacked prior to it to the top of the container.
      • If items are already stacked at the top of the container, do not animate those items.
  • If the new item is above the previously active item.
    • The previously active item should slide down to the lowest extent that it can.
      • Its bottom edge should meet the top of the item below it in the list.
      • If there is no item below it in the list, it should line up with the bottom of the container.
  • While the Slide animations occur, the internal container of the previously active Accordion Section should be hidden, while the new one is revealed beneath the new active header.
  • Simultaneously to this animation process, the previously active header should fade from white background to the slate-colored background, and its text from red to white. It should also shrink to the standard inactive header size.
• Each section header should be associated with an internal content area that represents its content.
  • When not active, the internal content area of that section should not be rendered, and should not receive any tap gestures or selections.
  • Each content section should be its own custom view controller.
• The sections inside this accordion should be as follows:
  • Account Info
    • Account Info View Controller
  • Contacts
    • SampleViewControllerWithLabel
      • Should say “Contacts”
  • Notes & Attachments
    • SampleViewControllerWithLabel
      • Should say “Notes & Attachments”
  • Activities
    • SampleViewControllerWithLabel
      • Should say “Activities”
  • Opportunities & Quotes
    • SampleViewControllerWithLabel
      • Should say “Opportunities & Quotes”
• If the view controllers within the Accordion Sections would be longer than the available viewing area, they should scroll within the Accordion Section.

 

Account Info View Controller

Please also build out the AccountInfoViewController that will be displayed in the Account Info accordion section. It should match the design in the Mockup, and should display fields based on the Account object. Note: Fields displayed here are subject to change, and may not all be available at this time. If they are not on the associate object, add a property to Account.swift

 

Please ensure that this View Controller meets the following requirements:

• Display each field with a Field Name header, and then the value of that field beneath it.
  • E.G.,
    Account

Samual Adams Brewing Co
Acme Account Alias

• Display the following fields, matching the layout and design of the mockup:
  • General Information section
    • Account
      • Account.name
      • Account.alias
    • Phone
      • Account.phone
      • This should highlight valid phone numbers, and when tapped should display an alert saying “Now Calling \(Account.phone)”
    • Address
      • Address
      • Suite #
      • City, State ZipCode
  • Lower Section (no name)
    • Est. Value
      • Account.estimatedCashValue
    • Program Type
      • Account.programType1
    • Last Activity
      • Account.lastActivity
    • CED1
      • Account.ced1
    • CED Secondary
      • Account.ced2
    • Agreement Name
      • Account.agreementName
    • Total Employees
      • Account.gkEmployeesHere
    • # of Wearers
      • Account.numberOfWearers
    • Mega Segment
      • Account.segment
    • Location Type
      • Account.locationType
    • # of Locations
      • Account.numberOfLocations
    • Date Quit
      • Account.quitDate
    • Quit Reason
      • Account.quitReason

 

General Guidelines

This is an iOS Swift Challenge, as such the design implementation should be done with the latest version of XCode and the latest standards for iOS Development.

Interface items should be built in Interface Builder. Elements within the interface should be positioned and sized using standard UIConstraints. Wherever possible, elements should be customized within interface builder, with little­to­no interface customization done programmatically. If there is no other possible way to achieve the aesthetic as presented in our design PDF, or if there would be significant performance detriment by not customizing via code, programmatic customization is acceptable.

The views within ViewControllers should be created with their own XIB files. Elements within the design (such as the sidebar) should be built with re­use in mind.

With multi­language support being an eventual goal of this project, please populate static labels from the Settings.bundle > en.lproj > Root.strings file. When you create a static label, make sure to add it to this file.

Please make sure any colors used match the brand value in "G k brand hex values.png"

 

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.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/homepage-assembly-challenge

- 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

- Provide deployment guide documentation 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.