Register
Submit a solution
The challenge is finished.

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!

 

Challenge Summary

 

The purpose of this challenge is to extend our existing Swift application prototype use make use of our SFDC API to populate the data on the homepage. This challenge is a direct extension of the following previous challenges:

 

- UNI - Sales Portal iPad iOS Swift Prototype1 - realworldswift

- UNI Sales Portal Tablet App - SFDC REST Service Implementation Part 1

- UNI Sales Portal Tablet App - SFDC REST Service Implementation Part 2

 

This challenge focuses on using the API to populate data for the following areas of the Home Screen:

 

- ‘Seller Global Menu’

- ‘To-Do List’

- ‘Calendar’

- ‘Route List’ (Prospecting Button)

- ‘Notifications’

Detail

 

‘Seller Global Menu’

 

Implement linking in the Global Menu as follows:

 

  1. Gmail - Opens iOS Mail

  2. Prospecting - opens GEOPointe to modal window. Supply necessary credentials using Salesforce frontdoor protocol.

  3. Calendar - opens SFDC's calendar in modal window. Supply necessary credentials using Salesforce frontdoor protocol.

  4. Connect

    1. Opens Google Hangout App

    2. SF Chatter - Opens SFDC - Chatter page in global link. Supply necessary credentials using Salesforce frontdoor protocol.

  5. Create New

    1. Opens blank Page for accounts (not required for this task)

    2. Presentation - not requird for this task

    3. Quote - not required for this task

  6. G&K

    1. G&K Services.com:  Link to gkservices.com - open modal window to this page.

    2. G&K Direct.com:  Link to gkdirect.com  - open modal window to this page.

    3. Gaming:  Link to gaming application  - open modal window to this page.

    4. Training:  Link to G&K Training application  - open modal window to this page.

    5. Support:  NEED LINK

    6. G&K Employee Portal:  Link HR Portal  - open modal window to this page.

    7. G&K Reports:  Link to SFDC reporting   - open modal window to this page. Supply necessary credentials using Salesforce frontdoor protocol.

    8. Salesforce.com:  Link to SFDC as external link - open modal window to this page. Supply necessary credentials using Salesforce frontdoor protocol.

 

‘To-Do list’

  1. Populate the ‘TO-DO LIST’ area of the Seller Home Page. Use the ‘Retrieve Upcoming Tasks Calendar’ /Calendar/RetrieveUpcomingTasks{?date}{userId} API call to retrieve the data.

  2. Allow each task to be set to ‘Done’ or ‘Cancelled’ using the ‘Disposition Task’ /Calendar/DispositionTask API call.

    1. The user is only allowed to cancel tasks that he created (not tasks created by others)

  3. Reference http://docs.compassproject.apiary.io for details on the API calls.

 

‘To-Do list’ Additional Notes

  1. The TO-DO LIST should refresh each time you go to this page or when you come back from inactive state - load in background, replace UI when returns.

  2. If the list is empty, show a spinny wheel while loading. If the results come back empty, show light text saying "You have no upcoming Tasks".

  3. The TO-DO LIST area should have a “pulldown to refresh” feature, showing a spinny wheel while loading.

  4. If the service fails, give an error to that container and show in the list.


 

‘Calendar’

  1. Populate the CALENDAR area of the Seller Home Page based on the selected date. Use the ‘Retrieve Calendar’ /Calendar/RetrieveCalendar{?date}{userId} API call to retrieve the data.

  2. Allow each task or event to be set to ‘Done’ or ‘Cancelled’ using the ‘Disposition Event’ /Calendar/DispositionEvent and ‘Disposition Task’ /Calendar/DispositionTask API calls.

    1. The user is only allowed to cancel tasks that he created (not tasks created by others)

  3. Allow each task to be ‘Snoozed’ (see the snooze option / button in the UI)

    1. When the user clicks the snooze Working.option, it removes the task from the list and will show it to the user the next calendar day (simulate moving the due date back one day without actually changing the due date).

    2. Use the ‘Disposition Task’ /Calendar/DispositionTask API call to push the chosen “snooze date”.

  4. Reference http://docs.compassproject.apiary.io for details on the API calls.

 

‘Calendar’ Additional Notes

  1. The tasks shown are only those with a due date of the date selected (the API takes care of this).

  2. The seller can cancel, snooze, or complete a task from the homepage if the task was created by the seller.

  3. The seller can snooze or complete a task from the homepage if the task was created by another user than the seller.

  4. The seller can click on an account from an event and be taken to the account screen.

  5. The seller can access GeoPointe by selecting the location from an event (taken to GeoPointe with the location set on that of the account).

 

‘Route List’ (Prospecting Button)

  1. When the user activate the Prospecting button on the sidebar menu, push a WebView into the mainContentArea pointed at the prospecting screen in Salesforce via the frontdoor.jsp url with proper credentials passed in. (https://geopointe.cs2.visual.force.com/apex/Map)

  2. Do the same when the user presses the Prospecting button below the TO-DO LIST.

 

‘Notifications’

Develop a static background module - CompassNotificationManager - to periodically make REST requests, maintain a list of received approval and lead objects, and dispatch notifications to the active UI elements when an update is pulled.

 

  1. The CompassNotificationManager should be a singleton class.

  2. As with other singletons, the CompassNotificationManager should be accessible by a public static class method. e.g. CompassNotificationManager.sharedManager()

  3. REST requests should be made through the Salesforce Mobile SDK SFRestAPI's SFRestRequest object. e.g. var request = SFRestRequest(); request.path = "{PATH}"; request.endpoint = "{Endpoint}"

    1. Should retrieve through the Retrieve Notifications REST Service.

      1. ‘Retrieve Notifications’ /Notifications/Retrieve{?lastCheck}

    2. The first "lastCheck" time sent to the service should be from a NSUserDefault property "kLastNotificationReadTime"

      1. If this NSUserDefault property doesn't exist, set it to the current time.

      2. If the NSUserDefault property didn't exist, use the current time minus seven days for an initial notification request of the previous week's results.

    3. Every time a request is made with a successful callback, save the time of that request as the lastCheck variable on the singleton.

    4. Use the lastCheck variable's time as the lastCheck parameter on all subsequent requests.

    5. When a request is successful

      1. Store all Approvals in an Approvals list

      2. Store all Leads in a Leads list

      3. Dispatch a "CompassNewNotificationsReceived" event through NSNotificationCenter's defaultCenter

      4. In the UI, have the Leads and Notifications buttons on the Seller Home Page sidebar respond to the "CompassNewNotificationsReceived" event

        1. the CompassNotificationManager should be called to get a count of new Leads for the Leads button

        2. the CompassNotificationManager should be called to get a count of new Approvals for the Notifications button

        3. In either case, if the retrieved count is greater than 0

          1. Background of the button should fade transition to the red color

          2. A white circle with red text should display on the right hand side.

          3. The text in the circle should match the count of that was retrieved.

  4. CompassNotificationManager should have a time frame in seconds that determines how often it should perform a REST Request

    1. This property should be configurable programattically, and default to 60 seconds.

  5. CompassNotificationManager should have a function for clearing Leads

    1. The array should be emptied

    2. The kLastNotificationReadTime NSUserDefault should be set to the current lastCheck time.

    3. A copy array of the original array should be returned.

  6. CompassNotificationManager should have a function for clearing Approvals

    1. The array should be emptied

    2. The kLastNotificationReadTime NSUserDefault should be set to the current lastCheck time.

    3. A copy array of the original array should be returned.

General Guidelines

- All usage of API results should be null-safe. When populating objects from the JSON results if fields are missing, ensure that all usages appropriately handle the optional values.

- When loading data for a UITableView (To-Do List, DayPlan) if no results are returned, or if the specified filter has no results display the “NoDataTableViewCell” in the app.

- When loading data for a UITableView (To-Do List, DayPlan) if there is an error retrieving data display ErrorTableViewCell within the table. Set the label text to “Error loading data: {ERROR MESSAGE TRUNCATED TO ONE LINE}\nPull to try again” as the label on the ErrorTableViewCell.

- For all other service calls, if an error occurs dispatch a “ServiceErrorOccurred” event through NSNotificationCenter.defaultCenter()

 

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 codes 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.

ELIGIBLE EVENTS:

2015 topcoder Open

Review style

Final Review

Community Review Board

Approval

User Sign-Off

ID: 30047017