Duration

20 minutes

Goals

Working with SObject directly is tedious and error prone. Here you will code a custom derived class to simplify your client code.

Required assets

The provided Resources folder for this exercise contains a subfolder named Completed with a solution you can use to check your work. This lab is a continuation of the previous one. If you did not complete the previous exercise, you can use the Completed solution from the previous part as starter code for this part.

Exercise overview

This exercise is a continuation of the previous one. Here you will:

Create a derived class of SObject named Campaign.
Provide a property for each field you will use in your client app.
Override ResourceName.
Handle the PreparingUpdateRequest event.

Steps

Below are the step-by-step instructions to implement the exercise.

Create a custom SObject

Add a new class named Campaign to the MyCampaigns project.
Derive Campaign from the SObject base class.
Add a read/write property of type string for Name. Remember to use the Options dictionary that you inherited from SObject as the backing store for the property value. The completed code is given below (but hidden so you can try it first without seeing the solution).

Show Code

public string Name
{
  get { return this.Options["Name"]; }
  set { this.Options["Name"] = value; }
}

Add a read-only property for CreatedDate. To keep things simple, use string for the property type.
Override the ResourceName property. Your getter should return the hardcoded string "Campaign" which is the name of the Salesforce Object this class represents (i.e. the table name). Leave the setter empty, this value isn't something the client code will need to change.
Add a default constructor to your Campaign class. Inside the constructor, subscribe to the PreparingUpdateRequest event that you inherit from SObject. In your handler, remove the CreatedDate field from the UpdateData in the event args (this is a read-only field inside Salesforce and you would not want to send a value to Salesforce in an update operation).

Override ToString. A sample implementation is give below to save time.

public override string ToString()
{
  return string.Format("[Campaign: Name={0}, CreatedDate={1}]", Name, CreatedDate);
}

Use your custom SObject

Open CampaignsPage.cs.
Add the method shown below to the CampaignsPage class and complete the implementation. Your goal is to use the As type-conversion method to convert each of the SObjects returned from into a Campaign objects. You can do this one-at-a-time using a loop or all-at-once using LINQ.
```
async Task<List<Campaign>> GetCampaignCustomObjectsAsync()
{
  var sobjects = await GetCampaignSObjectsAsync();

  // convert the SObjects into Campaign objects and return the resulting list
  // ...
}
```
For convenience, the LINQ version of the solution is provided here:

Show Code

var sobjects = await GetCampaignSObjectsAsync();
var campaigns = sobjects.Select(c => c.As<Campaign>());

Call your new GetCampaignCustomObjectsAsync method from the provided Run method. Load the results into the ItemsSource property of the ListView that is declared inside the CampaignsPage class.
Run the app on at least one platform to test your work.

Summary

A custom SObject-derived class makes your client code much easier to use (e.g. named properties) and less error prone (e.g. you cannot forget to set the ResourceName). You should consider this technique for each Salesforce Object you work with: the code is not very long and there's not a significant performance penalty since the type conversion method does not need to copy the property values.

Go Back