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 to make use of the UI prototypes that were built in the previous challenges. The changes that will be touched upon in this challenge are the Account Screen changes. A number of service modifications and design changes have been made, and we need those to be applied where necessary.
Detail
Update Account Info to Include Health Care Fields
First, update the Account Model object so that it holds the following new fields:
-
isHospital
-
Boolean
-
-
hospitalType
-
String
-
-
numBeds
-
Double
-
-
gpoAffiliations
-
String ( , separated)
-
-
hcSystemName
-
String
-
-
operatingIncome
-
Double
-
-
currentCleanRating
-
Double
-
-
previousCleanRating
-
Double
-
-
cleanRatingNationalAvg
-
Double
-
-
cleanRatingStateAvg
-
Double
-
With the latest UI enhancements, a new section inside of Account Info was added for Health Care Info. You’ll want to check that the returned Account Info has the “isHospital” flag set to true. If so, display the Health Care Info in the section. Using the values of the fields above, populate the different elements of the data layout. You should also change the Clean Rating fields, to display and accept numeric values in this info section and NOT be a picklist.
Set Up the Account Info Update to include Health Care Fields
Modify the Update service call to pass in these new fields. You should map the fields to their corresponding Salesforce fields in the accountToUpdateParams function. These mappings should be as follows:
-
numBeds = texcellency__DefHC_NumBeds__c
-
hospitalType = texcellency__DefHC_Hospital_Type__c
-
gpoAffiliations = texcellency__DefHC_AffiliationsGPO__c
-
hcSystemName = texcellency__DefHC_Network_Name__c
-
operatingIncome = texcellency__DefHC_OperatingIncome__c
-
currentCleanRating = DefHC_Room_Bathroom_Clean_Rating_2014__c
-
previousCleanRating = DefHC_Room_Bathroom_Clean_Rating_2012__c
-
cleanRatingNationalAvg = DefHC_Room_Bathroom_Clean_Rate_Natnl_Avg__c
-
cleanRatingStateAvg = DefHC_Room_Bathroom_Clean_Rate_State_Avg__c
Update Notes & Attachments
The Notes & Attachments accordion section has undergone a pretty major change since the last API Integration challenge with the Account Screen. The section now supports Notes & Attachments separately, so you will need to adopt all 3 types accordingly. You’ll note that the /Account/RetrieveAccount/ service should now include the following 3 arrays:
-
notes
-
requestFor{Update/Insert}WithObjectType(“Note”,...
-
Example JSON from /Accounts/RetrieveAccount:
-
"notes": [
-
{
-
"text": "Note for Acme Products",
-
"name": "Note for Acme Products",
-
"lastModifiedDate": "2015-01-15T15:24:02.000Z",
-
"id": "002R0000001rCQ7IAM"
-
}
-
]
-
-
-
attachments
-
requestFor{Update/Insert}WithObjectType(“Attachment”,...
-
Example JSON from /Accounts/RetrieveAccount:
-
"attachments": [
-
{
-
"name": "#1 FF Execute for Approval.pdf",
-
"lastModifiedDate": "2015-02-04T03:26:49.000Z",
-
"id": "00PR0000000uHZGMA2",
-
"description": null,
-
"contentType": "application/pdf",
-
"bodyLength": 703024
-
}
-
],
-
-
-
docs
-
requestFor{Update/Insert}WithObjectType(“GoogleDoc”,...
-
Example JSON from /Accounts/RetrieveAccount:
-
"docs": [
-
{
-
"url": "https://docs.google.com/a/appirio.com/document/d/14SCnpf_Zn54QYxMveEfuXuQTda58XsitmxqNDffal7A/edit",
-
"name": "Icon Swap Challenge",
-
"lastModifiedDate": "2015-02-04T03:27:43.000Z",
-
"id": "098R0000000CaZpIAK"
-
}
-
]
-
-
You should create a singular object for these three types to inherit from, so that they can be held in one array. The fields shown in the JSON are the only fields for those objects. The data should render with the Name or Title as the primary text and the LastModifiedDate formatted as MM/DD/YY. The third data point for Attachments should be the ContentType. For GoogleDocs it should be a truncated form of its URL.
Note CRUD
You need to modify the Save, Update, and Delete functions of the Notes such that they are properly mapped to the new object being used. The className will need to be “Note”. When mapping the data, the following fields are the only ones that should need to be updated:
-
Id
-
from id
-
Only on Updates
-
-
ParentId
-
from Account.Id
-
ONLY ON INSERT
-
-
Title
-
from name
-
-
Body
-
from text
-
When the result of creating a Note is returned, ensure that the Id is properly associated for editing and deleting of the new Note.
Attachment CRUD
You will need to create the Insert, Update, and Delete functions for Attachments.
The Attachment currently has the ability to be edited, this will need to be changed such that only the name of the file can be changed. Remove the +Attachment button from the edit view, but continue to show the image if the attachment is of an image type.
When updating an attachment you should send the following fields:
-
Id
-
from id
-
-
Name
-
from name
-
When initially creating the Attachment, it is a little more complex. You’ll want to set the following fields:
-
ParentId
-
from Account.Id
-
-
Name
-
from name
-
-
Body
-
The selected image encoded as a base64 blob.
-
The Image should be no larger than 25MB. Should they be larger than that, resize and compress such that the 25MB limit is not hit.
When the user taps on the attachment to view it, you will want to present a ModalViewController with a WebView. You will need to follow a process similar to Content Items in order to download the contents of the attachment and insert it into the WebView. The URL for the attachment should be retrievable from /services/data/v32.0/sobjects/Attachment/{attachmentId}/Body via REST. It will return a base64 encoded blob of the ContentType listed in the JSON.
GoogleDoc CRUD
You will need to create the Create, Update, and Delete functions for GoogleDocs. The fields should be as such:
-
Id
-
from Id
-
on Update Only
-
-
ParentId
-
from Account.Id
-
on Insert Only
-
-
Name
-
from name
-
-
Url
-
from url
-
When the result of a GoogleDoc Insert is returned, be sure to associate the returned Id to the object for proper updating and deleting.
Know Say Show Implementation
Another part of this is getting all of the Know Say Show services implemented. To do this you will first need to make a request to /2.0/WebContent/{accountId}. This will respond with the following JSON objects:
{
"message": "SUCCESS",
"isSuccess": true,
"contentsforShow": [],
"contentsforSay": [],
"contentsforKnow": []
}
You’ll need to break out the values in the contentsforShow, contentsforSay, and contentsforKnow arrays, and render them in the proper accordion section in the Know Say Show area of the Account screen. Each of these arrays will contain the JSON for a ContentVersion object from Salesforce. The fields that will be important for you are as follows:
-
ContentDocumentId
-
Used for downloading the Content from Salesforce for viewing. Use the same process as the app does for showing Core Values or Customer Promise.
-
-
Description
-
This is the text used to display in the cell item.
-
In addition to tying in the description, and ensuring the application loads the content item when tapped, please ensure a minimum size of 44pt for each item, and add a light gray dividing line between cells.
General Guideline
- 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.
- For all service calls, if an error occurs dispatch a “ServiceErrorOccurred” event through NSNotificationCenter.defaultCenter() with relevant text about the error.
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.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/workstream6-integration1
- Write and submit your code as a zip file
Please note the credentials to log into the Compass application are in the forums.
Final Submission Guidelines
Submission Guidelines
- Cocoa Touch framework Xcode 6.1.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.