Internal platform changes that are not visible to capsule developers will be communicated via internal status updates.
Starting with 18M, you can no longer load release submissions in Bixby Developer Studio (Bixby Studio). Overall, we think this is a healthy change, though this might require you to adjust your workflow.
If you leave the CAN revision override empty on a non-Bixby Studio client (such as a mobile device), you will access the CAN release submission currently deployed to the environment.
Initially, we will only deploy CAN release submissions from the Bixby 2.0 release-manifest. A new end-user environment will be available soon that will allow you to test your capsule on a real device (such as mobile). It will also allow favoriting so that users have personalized CANs, each trained with different subsets of capsules.
You can continue to load private and public submissions. To test your capsules, please create private submissions (containing a single capsule) and load those submissions in the Simulator or non-Bixby Studio clients. It should be fast and reliable.
If you have previously loaded a release submission in the Simulator, you will need to clear it. Otherwise, you will receive errors.
With this release, you can once again trigger a result-view
with a halt
effect.
You now have the ability to localize storage prompts, which are generated when Bixby asks for permission to store a preference in the user's profile.
Example:
profile-support {
match: FlightPreferences
storage-prompt {
confirmation-type (PreferenceConfirmation)
message (Store your flight preferences?)
confirm-label (Yes)
deny-label (No)
}
}
Learn more about localizing storage prompts in the Developers' Guide.
You can now use the HTTP Post request method to deliver SPS payments using http.spsProxyPost.
Read more about Supporting Payments in the Developers' Guide.
Both client-app-support
and the requires
key within app-launch
now support the app-name
sub-key. This sub-key allows you to specify a human-readable name for display purposes. This is in addition to the package name specified in app-id
.
client-app-support {
app-id (samsung.ugly.package.id)
app-name(Nice App Name)
app-min-version (123)
app-store-url(...)
}
app-launch {
payload-mapper (...)
requires {
app-id (samsung.ugly.package.id)
app-name(Nice App Name)
app-min-version (123)
app-store-url(...)
}
}
If you are using SPS payments, you can now add a new $paymentCard
input to access non-sensitive information about the card confirmed by the user.
The $paymentCard
object looks like this:
{
last4: "9999",
address1: "1445 Norwood Ave",
address2: "Building 5",
city: "Itasca",
state: "IL",
zip: "60143",
country: "US",
phone: "18885551212"
}
For more information, learn about Passing a User's Non-Sensitive Card Information in the Developers' Guide.
We've added confirmation-drivers
to the confirmed-by
key.
Learn more about Conversation Drivers in the Developers' Guide.
Updated: June 11, 2018
If you implement a result-view
block within your capsule, you should ensure that you properly guard against empty results. Because an available result-view
is now also used in the absence of results, you might have else
blocks triggering unintentionally. For example, in a hotel booking capsule, the following conversation-driver
is insufficient because it doesn't guard against a case where there are no results.
Incorrect:
conversation-drivers {
if (size(this) > 1) {
conversation-driver (Free parking)
conversation-driver (Pool)
conversation-driver (3 Stars)
} else {
conversation-driver (Book hotel)
}
}
The result of this is that users will see "Book hotel" even if there are no hotel results.
Similar issues can occur when the result-view
block contains app-launch
. For example, in this code sample, the result-view
does not check the results:
Old Incorrect Way
result-view{
match: MediaActionResult(this) {
from-output : TurnUpVolume(action)
}
message ()
app-launch {
payload-uri ("bixby://com.android.systemui/ExampleSystem/punchOut")
}
}
New Correct Way
If you don't want the result-view
to match at all and influence the output message, we recommend adding the min (Required)
constraint to the match pattern for result-view
:
result-view {
match: MediaActionResult(this) {
min (Required) from-output : TurnUpVolume(action)
}
message ()
app-launch {
payload-uri ("bixby://com.android.systemui/ExampleSystem/punchOut")
}
}
Otherwise, you should account for a no-results case with appropriate conditional logic:
result-view{
match: MediaActionResult(this) {
from-output : TurnUpVolume(action)
}
message ()
app-launch {
payload-uri {
if (exists(this)) {
template ("bixby://com.android.systemui/ExampleSystem/punchOut")
}
}
}
}
For activity
, we've renamed two child keys within summary-view
:
primary
is now title
secondary
is now details
Additionally, the time
key is now required.
Learn more about activities within Transactional Workflows.
With local endpoints, you must now ensure that names between accepted-inputs
and the JavaScript function parameters match.
Learn more about Local Endpoints.
The following input components now offer a submit-button
key that allows you to customize the button text:
date-picker
calendar
form
image-picker
(only used for multi-select)selection-of
(only used for multi-select)time-picker
You can now add a header to your list of results using the title
key.
For each image that is in image-list-of
, you can now pass the title
, subtitle
, and caption
.
Updated: May 24, 2018
As part of Preference Learning, once you mark a field as preferable
, you can now sort results based on whether the related fields are marked as preferences.
Example:
action (Action) {
...
output (Struct) {
sort {
each (r) {
sorting (r) {
by-preferences
}
}
}
}
}
Learn more about sorting by preferences in the Developers' Guide.
Because the background-image-url
key is used for images that are not background images, it has been renamed to image-url
.
When using result-view
, you can now specify a payload-mapper
within app-launch
. This lets you send a more complex payload by invoking a local JavaScript function that maps the result-view
bindings and a context object into an opaque JSON string that satisfies the client's payload format requirements.
Example:
result-view {
match: MyBool (this) {
from-output: MyAction (action)
}
app-launch {
payload-mapper (lib/payload-mappers.js::myMapper)
requires { // optional
app-id (MY_APP_ID) // optional
app-min-version (12345) // optional
app-store-url (...) // optional
}
}
}
For more information, refer to app-launch in the Reference Guide.
When using local endpoints, we now enforce JavaScript execution resource limits:
CPU running time: 25 seconds for each JavaScript action. This includes any aspect of the full JavaScript execution including JavaScript code bootstrap, interpretation, and function result or failure handling.
Memory allocation limit: 65 MB
Bixby will block violations of these limits, and they are subject to change in the future.
Selection prompts now behave modally, which means that when a user is at a selection prompt, all of their utterances will be locked to the type being prompted for. Developers can now add prompt training for user responses at selection prompts.
There are two ways in which a user utterance at a selection prompt can be interpreted normally (in a non-modal way). First, the capsule provides no training where the goal is set to the prompt type. Second, an action evaluated during execution of a prompt response triggers a flag-as-off-topic
effect. If either of the two conditions are met, Bixby re-interprets the user utterance in a non-modal context, which means that all outer queries and relevant continuations are considered.
The following reports related to CAN submissions have been renamed:
NL Interpreter Training
is now called Capsule Interpreter Training
NL Classifier Training
is now called Capsule Classifier Training
The new report names are present in all new submissions starting with the 18J release, while submissions made before 18J continue to show the older report names.
Updated: May 17, 2018
You can now highlight specific results on the first page of a rendered list in the result-view
and input-view
of a selection list.
You can learn more about highlights
(formerly smart-picks
) in the Reference Guide:
Within result-view
, we've deprecated app-punch-out
and replaced it with app-launch
. You can now send users to a specified URI or add a more complex app-launch
payload by invoking a local JavaScript function. This JS function maps the result-view
bindings and a context object into an opaque JSON string that satisfies the client's payload format requirements.
Examples:
result-view {
match: MyBool (this) {
from-output: MyAction (action)
}
app-launch {
payload-mapper (lib/payload-mappers.js::myMapper)
requires { // optional
app-id (MY_APP_ID) // optional
app-min-version (12345) // optional
app-store-url (...) // optional
}
}
}
result-view {
match: MyBool (this)
app-launch {
payload-uri ("some/simple/uri?#{value(this)}")
requires { // optional
app-id (MY_APP_ID) // optional
app-min-version (12345) // optional
app-store-url (...) // optional
}
}
}
You can read more about app-launch in the Reference Guide and Bixby Views.
You can now sort results based on whether the related fields are marked as preferences. This can be done in action concepts, collections, views, and highlights.
Example
collection {
match: Struct
default-sort-order {
sorting (type) {
by-preferences
}
}
}
You can earn more about Sorting by Preferences.
Because we have enabled personalized NLU classifiers, if you do not use Revision Override, users will only be able to speak naturally to capsules that are favorites. If users have never used Bixby Main to favorite anything before, they can expect all utterances that don't use named dispatch to receive low confidence ("I didn't understand that"). This affects the end-user flow and not when using Bixby Developer Studio or Simulator.
Updated: May 4, 2018
With this release, Bixby rejects non-standard capsule versioning that doesn't follow a subset of the SemVer format. The capsule version must be a string with three numeric parts: "X.Y.Z". Each part must be an integer with no leading zeroes.
Correct:
1.3.24
Incorrect:
1.2.3.4
1.2
1.2.3+beta
1.2.3-beta
0.0020.001