Salesforce1 Mobile Device Testing

Being in the middle of the Salesforce1 Developer Week, lots of Salesforce professionals will be tackling the Salesforce1 Mobile Workbook and begin customizing their own Salesforce.com orgs soon after.

If you've worked with Salesforce1 before, you're probably already familiar with this URL:

<yourInstance>.salesforce.com/one/one.app

If you're not, try it out in your browser window.  Replace <yourInstance> with your instance (IE: na4.salesforce.com/one/one.app).  You'll see the equivalent of the Salesforce1 mobile app within your window.  This makes testing slightly easier as you begin the early stages of a Salesforce1 related project.

As you begin to fine-tune though, you'll need to begin doing some mobile testing as users will use different sized mobile phone and tablet screens.  As seen above, using the one/one.app link, you get a nice preview, but the preview is sized to your screen's resolution.  You're screen's resolution may not always be the best representation of what your users are seeing.

Wouldn't it be nice if you could simulate the actual devices' resolutions?

Using Google Chrome's Developer Tools, you can!

Once the Developer Tools are open, within the bottom panel, click on the "Emulation" tab.  Choose a device to test with from the "Device" drop-down and then click on the "Emulate" button.

If you see something like the image on the left, you'll want to manually refresh your page.  When you do, you'll see a resized version of the Salesforce1 app/page as your users on that device would see it on their device.

 It's worth noting that if you don't see your user's device in the list, you can set your own custom resolution by clicking on the "Emulation" tab at the top, then "Screen" link on the left.  This is also where if you need to test portrait vs landscape screen modes, you can inverse the X and X resolutions (even if SF1 doesn't support it).

Read More

CTI 2.0 or Higher Settings Missing?

Usually while configuring Salesforce, you'll be logged in with a User that has been assigned the "System Administrator" Standard User Profile.  When you're using this type of account, you typically think you have access to and will see every configurable part of Salesforce.com that your Org has.

This isn't always the case - take for example the "CTI 2.0 or Higher Settings" section under Setup --> Customize --> Call Center --> SoftPhone Layouts --> Edit --> Inbound Calls.

This is what I was seeing:

This is what I was missing:

According to the documentation, "This section only displays if your CTI adapter was built using the CTI Developer's Toolkit 2.0 or higher."  While working in a client's Org, a 2.0+ CTI adapter was being utilized in both their sandbox and production Orgs.  Within their sandbox, I was able to see this section, whereas in production, the setting was missing.

Naturally, I wondered if it had to do with release differences, but the sandbox was Spring '14 and production Winter '14.

Setup-wise, they were identical with one small difference - my user account was no longer listed as a User under the Call Center's settings (Setup --> Customize --> Call Center --> Call Centers --> Click on the Name --> Click on the "Manage Call Center Users" button).  

Once it was added back, voilà!  The "CTI 2.0 or Higher Settings" section was back.

Read More

Second Post to see stacking and also incorporation of images

Read More

Sample Post

This is where my blog will post on the template

Read More

Calling Out to a Google API with an Access Token

One of the best things about Google is that they have APIs for all their services. These APIs come handy when you are trying to integrate with Google from within Salesforce. I recently had to do just that, and thought I'd share some of what I've learned...

First of all, I quickly realized that I couldn't use the Force.com Google Data API Toolkit because Google Data APIs are part of an older generation of Google APIs that have authentication methods that are deprecated. Also the Google Data APIs don’t include some of the more interesting enterprise applications that Google has to offer. The newer Google APIs are SOAP based and you need to go through an OAuth 2.0 handshake to authenticate. I used the OAuth 2.0 for Web Server Applications flow, and didn't have too much issues with it (look for a future post on that).

Since Apex does not have a client library for the newer Google APIs, I had to download the WSDL for the resource I wanted to access. I had a couple of issues with wsdl2apex, but was able to get around them. However, after some poking around, I realized that the wsdl conversion didn't work too well after all and had to abandon that path (I think it is related to how wsdl2apex translates attributes and gets around reserved words).

My next move was to make the SOAP call with a normal http callout, which meant that I had to create the XML body to add to the callout. Most of the transaction was a no brainer, but I had a hell of a time figuring out how to include the access token in the SOAP XML. I found the documentation to be either confusing, old, or plain wrong (I did complain about it in one of the boards, and they made some changes since). After quite a bit of trials and errors, I finally got it right though.

So to spare you the extra time it took me to put this together, the following is a very quick sample method that shows you how to set the SOAP headers, including the access token. Please note that this code sample is very simplified - I jammed everything into one method and did not include coverage. Also, in my implementation I am using the XML stream writer to create the body, but in this case included the XML as a sting so it is easier to read.

Read More