Avoid using Pagereference methods in salesforce1 and usually i would prefer using @Remote action method to implement logic
Lets take a quick look with sample code below on how to achieve this
function actioninvoke(){
if( (typeof sforce != 'undefined') && (sforce != null) ) {
// Salesforce1 Remote Action method built in controller
}
else {
//Action Function of normal App
}
}
Visualforce Code
<apex:CommandButton value="Next" onclick="actioninvoke();" id="cmdNext" />
The advantages of remote action will be ability to callback and in callback we can use navigation specific function of salesforce1 like sforce.one
navigateToSObject(recordId,view) //Navigates to an sObject record, specified by recordId.view is optional, and specifies the view within record home to select—chatter, related, or detail.
This is one of the limitations of overriding buttons. Currently, the button override feature only works in the Salesforce desktop browser UI.
Basically, Visualforce is only surface through the Salesforce1 mobile app in the following ways:
- A tab (the left hand nav bar navigations)
- Publisher actions
- Mobile cards (a custom piece of UI in the related records part of record home)
- probably a few others I can't remember off hand...
But for the purposes of creating a new record, I think the best possible work around is using a publisher action instead. In this case, your publisher action can launch a Visualforce page. The important things here though, are to give your users the ability to interact with the Cancel/Submit buttons surfaced for publisher actions.
I built a page last year to focus on just this problem. If you take a look at it, the important bits are:
- Attaching an event handler to the submit event
- Activating the submit button (default it is deactivated but visible)
- Managing the publisher lifecycle stuff that closes the publisher and returns you to where you were
Attaching the event handler looks like this, and is on line 155 of my example:
Sfdc.canvas.publisher.subscribe({name: "publisher.post", onData:function(e) {
postToFeed();
}});
Then, at some point, you'll have a callback that, when successful, you'll want to make the publisher button active. This bit of code, on line 122 of my example, is well documented:
Sfdc.canvas.publisher.publish({
name: "publisher.setValidForSubmit",
payload: true
});
Finally, the lifecycle handling of the publisher UI. You have to fire the event that says, "go away, I'm done with you." In my case, I do it in the callback for a JS remoting call that is invoked by the function I attached to the submit event handler above in the first step. This is on line 134 of the example and looks like this:
//****the postToFeed function fired from the Submit button****
function postToFeed(){
$('#test-display').text('Posting To Feed: ' + contentId + '&' + merchId);
Visualforce.remoting.Manager.invokeAction(
'{!$RemoteAction.IncidentReport.postToChatter}',
contentId,
merchId,
//****callback from VF remoting call....
function(result, event) {
$('#test-display').text('Back from posting: ' +result + JSON.stringify(event));
//****this is the bit that fires the publisher close action****
Sfdc.canvas.publisher.publish({
name: "publisher.close",
payload:{ refresh:"true"}
});
});
}
I confess this example has a bit of a cobbled-together feel to it. And there are certain use cases I didn't handle, for instance, this publisher VF page saves at three different times and doesn't handle the potential need to roll-back if one of the later actions goes wrong! But my point in building it was just to focus and study the interaction with the publisher UI from the VF context. At the time I built if I found that the ingredients were kind of all over the place.
None of this should matter for your simple use case: Create Event.
There may also be some downsides to this approach. So you add a publisher action...what do you do with the New Event button everywhere else? There's no perfect solution there. Get rid of the button entirely for all users and push everything through publisher? I'm not certain how possible that is. But at least there is an option for S1 mobile.
Best Answer
Plain and simple, you can use it like this one-liner:
From the Summer '17 Release Notes - Prepopulate Fields on a Record Create Panel
Caution 1:
The this feature from Summer'17 works only if you put your Visualforce Page to API v40.0 or higher.
Caution 2:
Objectnames and Fieldnames are CASE-SENSITiVE! So
lastname
is notLastName
and onlyLastName
is correctSee also:
https://developer.salesforce.com/docs/atlas.en-us.salesforce1.meta/salesforce1/salesforce1_dev_jsapi_sforce_one.htm
https://developer.salesforce.com/docs/atlas.en-us.208.0.lightning.meta/lightning/ref_force_createRecord.htm