function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
lwolfe1.3965639852902874E12lwolfe1.3965639852902874E12 

Salesforce1 and Spring 14 Features

Do the currently available native Salesforce1 apps contain all the Spring 14 Release features?

This URL indicates that they are:
http://help.salesforce.com/apex/HTViewSolution?id=000188534

I'm noticing discrepencies between the web site at /one/one.app and the native apps.  After going through the steps to make the canvas app available, and using the “Signed Request (POST)” for the “Access Method” here is what I am seeing:

• For mobile browsers (Safari on iOS or Chrome on Android), it is shown and does POST the signed request to our server
• The Salesforce1 native app on Android does not show the canvas app in the navigation menu
• The Salesforce1 native app on iOS shows the app in the navigation menu, but makes a GET request to our server without the signed request

pcifpcif
Were you able to figure out what was causing this issue? I'm seeing the same thing. Thanks!
levi wolfelevi wolfe
I gave up on using Canvas as a navigation menu item.  Unfortunately, there doesn't seem to be anywhere to get information on the feature release status of the Salesforce1 native mobile apps.

As a workaround, I embedded the canvas app on a Visual Force page.  This does appear correctly in all situations above, and always correctly POSTs the signed request.
http://www.salesforce.com/us/developer/docs/platform_connect/Content/canvas_framework_using_vf_intro.htm

I asked the same question here with no answers so far:
http://salesforce.stackexchange.com/questions/31954/salesforce1-and-spring-14-features
Jay HurstJay Hurst
Cross posting from the stackexchange issue.

I have confirmed the bugs for both the iOS and the Android native apps.  For iOS, the issue is that the app is incorrectly popping Canvas Apps out into a separate web container, which does a GET.  Instead, they should be opened inline which will do the correct signed request POST.  This issue should be fixed in the next release of the iOS app.

For Android, the feature is a bit behind in the dev and has not been implemented yet.  I am working with the Android team to get the Mobile Nav location implemented ASAP.

In the meantime, the easiest way will be to deploy using a VF page that uses the apex:canvasApp tag.

Again, sorry for the delay and the trouble.