Welcome!
This is where we announce new releases on JourneyApps.
You can subscribe for updates by clicking the button on the top right.
For older release notes, please go here.
Backend API rate limits for all apps
We have implemented request rate limits to our backend APIs to further improve our backend performance, and protect against malicious actors from denying backend service to our customers. This notice describes our implementation of rate limiting, and describes when rate limits will be enabled for your app.
What are request rate limits?
Rate limits restrict the number of successful requests against an API endpoint when the endpoint is abused or unintentionally hit unusually hard by an API client.
We are implementing rate limits with the following characteristics:
- A token bucket algorithm is used. You can read more about token bucket algorithms here.
- API rate limits are enabled per backend deployment, as well as per app user in that deployment for syncing data or making API requests from the JourneyApps Container.
- There is a predetermined maximum sustained rate of requests per second that the API can accept.
- There is a provision for burst capacity above the sustained rate. The burst capacity is the total number of requests allowed once the sustained rate has been exceeded. The burst rate is replenished when the number of requests made is less than the sustained rate.
- When a request exceeds the request rate limit, the API will return a 429 HTTP response.
What do you need to do?
If the failure of any single request in an API broker or CloudCode task may break data integrity, you will need to update the broker to handle the 429 error response. We recommend that you see whether your API broker or CloudCode tasks could be impacted.
To handle the 429 response, you can implement the following logic where response errors are handled:
“If the response is 429, wait for at 1 second before retrying.”
Here is an example of the JSON response when an endpoint is rate-limited:
{
"type": "TOO_MANY_REQUESTS",
"title": "Too Many Requests.",
"detail": "Request rate limit exceeded for this account. Try again later.",
"retry_after": 60 // in seconds, a friendly suggestion
}
How do I check whether I am hitting the API near the rate limit?
There is no API endpoint that provides this information, so you will have to review your logs to track your usage. Our request limits are based on a one-second rolling window, so a pause of 1 second in the event of a 429 response should suffice in most cases.
As of January 2020, we have started returning a warning to API requests that exceed the rate limit.
When are we enabling rate limits?
- All apps created since January 2020 already have rate limiting enabled by default.
- All older apps will also have rate limiting enabled by 1 February 2021.
Where can I see what the specific rate limits are?
You can see the API rate limits applied to a deployment on the Manage API page on the backend Data Browser.
Please take note:
- Extensions to the above dates may be granted under extraordinary circumstances.
- Rate limits may be increased upon application.
Please contact JourneyApps Support for questions, raising limits, or extensions.
Updates to Mapbox APIs that affect apps on older runtime versions
The capture-coordinates UI component (as well as the gps component in v3 syntax apps) uses a Mapbox static tiles API that has been deprecated and stopped working recently. Customers running v3 and v4 apps prior to v4.74 will be impacted as detailed below. Runtime versions newer than v4.74 use the new supported API.
Please update any apps relying on rendering the maps with a newer Runtime version.
There are some small visual changes:
Before:
Now:
Common questions:
What if I don’t update my app?
The behavior will be similar to when the user is offline, but blank white squares will be rendered instead of the map:
GPS coordinate capturing itself is unaffected; only the map rendering is affected.
My application is on an old runtime version, and I cannot update it to the latest runtime at this time. What do I do?
One option is to just hide the map, using: hide-if = "true"
What about apps that don't have a set runtime version?
It's best to upgrade now to a managed runtime version. Alternatively, use the hide-if workaround above.
What about v3 containers?
V3 containers are affected in the same way, and no update will be released. See the hide-if workaround above.
Runtime v4.76
We're happy to announce that v4.76 of the JourneyApps Runtime has been released. You can use this version of the runtime by selecting it from the list of stable runtime versions under App Settings/Version Management.
v4.76.3
Fixed:
- An issue where using the back button on a mouse, or the back button in the web browser (for web only) would cause the app to show a blank screen.
- text-input now correctly suggests capitalized words on mobile keyboards when it is bound to a field with the specification of text:name.
v4.76.2
Fixed:
- A visual bug with the single-choice-radio component.
v4.76.1
Fixed:
- An issue with uploading diagnostics reports.
v4.76.0
This release includes all the fixes for v4.75 and the following:
Added:
- The ability to open a container using a deep link and without an enrollment. See Opening External Links for more details on how to use this.
- A unique identifier a user's device, which can be access in JS on the global journey object. See journey.device.id for more details.
- Support DB images in the display-image component using bind. See Configuration
Fixed:
- Fixed handling of 404 errors and timeouts when using OnlineDB.
- Fixed a memory leak that caused the container to crash on older devices and with large apps.
- Fixed navigation drawer not correctly evaluating $: functions, which caused labels and icons to break.
- Fixed ActionSheet positioning issues and updated to be more visually consistent across platforms.
Improved:
- Improved navigation, using native maps on Android and iOS devices.
- Visual and functional improvements to the sync indicator. Adding a dropdown to show more detail on the current sync progress.
- Visual updates to the context-menu (i.e. kebab menu), replacing the old right hand side menu.
Container v20.10.2
We're happy to announce that v20.10.2 of the JourneyApps Container has been released.
This release increases the Android API level to meet Google Play Store minimum version requirements.
We've made no changes to functionality.
Runtime v4.75
This is a release which contains the following fixes:
v4.75.9
Fixed:
- An issue where using the back button on a mouse, or the back button in the web browser (for web only) would cause the app to show a blank screen.
v4.75.8
Fixed:
An issue where a radio button's circle shrinks when it the option has a lot of text.
v4.75.7
Fixed:
- A regression where navigate.x functions in a view's resume() function would cause an Unknown error and not navigate as expected.
v4.75.6
Fixed:
- A regression with multiple-choice-checklist, where the component did not recognize options described inside the component node in XML has been fixed.
Example:
<var name="contact_methods" type="multiple-choice"/>
<multiple-choice-checklist label="Alt syntax" bind="contact_methods3" on-change="$:optionChange($value)">
<option key="email">Email</option>
<option key="sms">SMS</option>
<option key="post">Post</option>
</multiple-choice-checklist>v4.75.5
Fixed:
- Regression with visibility of primary buttons and button-groups.
v4.75.4
Fixed:
- Regression where long dialog titles did not display correctly.
v4.75.3
Fixed:
- Regression with navigation component which caused empty items to be displayed in the navigation drawer.
v4.75.2
Fixed:
- An issue with component display-photo and capture-photo where tooltips inside the fullscreen preview would break.
- Support for component single-choice-radio syntax, allowing options to be described inside the component XML, for example:
<var name="contact_method" type="text"/>
<single-choice-radio bind="contact_method" label="Select you preferred contact method">
<option key="email">Email</option>
<option key="phone">Phone</option>
<option key="mail">Mail</option>
</single-choice-radio>v4.75.1
Fixed:
- Regression where empty columns did not hide.
v4.75.0
This release includes all the fixes for v4.74.x and the following:
Added:
- Added journey.leaveApp() function to programmatically leave the app.
- Introduced journey.runtime.version in order to get the current runtime information, see journey.runtime for more information.
- Support for dark theme date- and time pickers on Android and iOS.
- Added keyboard shortcuts to the date-picker component.
- Added the ability to clear the date in object-table V3, by hitting the delete or backspace key when the date-picker is open.
- Added experimental support for Bluetooth (BLE).
- Added ability to query by id.
Improved:
- The single-choice-radio component has been improved and visually updated, adding support for the disabled attribute. See Syntax reference for more detail.
- The multi-choice-checklist component now supports the disabled attribute and has been visually updated.
- Loading of translations in the sidebar are now more consistent.
- Improved consistency when evaluating show-if and hide-if attributes for all components.
- Improved mouse interactions on buttons, on-press and on-long-press now only trigger when using the left mouse button.
- Added a label attribute to the info-table component and visually improved how it is displayed in dark theme and in dialogs.
- Improved dialog component scrolling when it has a lot of content. Also, added support for align="fullwidth" on the <body/> tag, allowing the dialog to go full width.
- Improved developer console tooling:
- Access view variables directly from the console.
- Call view functions directly from the console.
- Click on console stack traces to view source.
- Use Promise/await in the console for any asynchronous functions.
- Show view XML name in stack trace of errors in $: functions.
Fixed:
- Fixed detection of users logged out via the backend API.
- Fixed an issue with background location tracking.
- Fixed an issue where an update will be blocked by a view's on-back function.
- Fixed icon colors in the navigation component when using custom image icons.
- Fixed an issue where the view history dropdown (long-press on the back button) would not close.
- Fixed object-table V3's default text sorting on text cells, and improved UX for clickable elements such as cell- and row-actions, editable cells, sorting, filters, etc.
- Fixed an issue that caused the navigation drawer to incorrectly evaluate expressions when using $: functions for labels and icons.
- Fixed text-input placeholders not always displaying special characters correctly.
Container v20.10.1
We're happy to announce that v20.10.1 of the JourneyApps Container has been released.
Added:
- It introduces the ability to generate a PDF from HTML on desktop containers. Learn more
Fixes:
- an issue on newer macOS versions where camera wasn't working correctly due to macOS permissions.