OutSystems Mobile Developer Specialist key terms

Ordered client-side events on a mobile Screen: OnInitialize sets up local variables before widgets render, OnReady runs after rendering for UI logic, OnRender fires on each re-render, and OnDestroy cleans up when the screen is discarded.

A server-side action bound to a Screen that fetches and shapes data before the screen is delivered to the device. It runs on the server, so it cannot access client-only resources or device APIs.

A visual query that combines entities and static records with filters, sorting, and calculated attributes. On mobile, aggregates in Screen Preparation execute on the server, while aggregates in client actions run against local storage.

Server actions run in the platform backend and can query the database and use server-only extensions. Client actions run on the device, can call device plugins and local storage, and cannot access the server database directly.

A configuration pattern where data is downloaded to the device so the app works without connectivity, and local changes are queued and uploaded when the network returns. Requires conflict-handling rules and clear sync triggers.

On-device persistence used by mobile apps to cache entities and store data while offline. Data survives app restarts but is scoped to the device, so it must be refreshed and cleared through explicit logic.

Situations where the same record was modified on the device and on the server before synchronization. The developer must choose a resolution policy such as last-write-wins, server-wins, or manual merge, and surface it to users.

An interaction pattern that updates the interface immediately as if an action succeeded, then reconciles with the server response. It improves perceived speed but requires rollback handling when the request fails.

A property of an operation that can be retried without changing the outcome beyond the first successful execution. It matters for mobile submissions that may be resent after timeouts or dropped connections.

The generation model chosen when creating a mobile app. Native builds compile to device code, Reactive uses a server-rendered web shell for faster delivery, and PWA installs through the browser with limited device access.

The cloud build service that compiles OutSystems mobile apps into installable native packages. Builds are triggered from Service Studio or the portal, and signing certificates and provisioning profiles must be configured for distribution.

The process of signing a mobile build with a certificate and provisioning profile so devices and stores trust it. Mismatched or expired signing assets are a common cause of failed installs and rejected builds.

An Apple-issued file that binds an app identifier, signing certificate, and allowed devices or distribution method. It must match the bundle identifier and certificate used by the build or installation fails.

A file holding the private key and certificate used to sign Android applications. Losing it prevents publishing updates to the same app listing, so it must be backed up securely.

Publishing a signed mobile build to the Apple App Store or Google Play, including store listing metadata, review compliance, and versioning. Updates require incrementing build versions and re-signing.

A packaged native capability, such as camera, geolocation, or push notifications, exposed to mobile apps through a JavaScript API. Plugins are added as dependencies and versioned with the app.

A build failure caused by two dependencies requiring incompatible versions of the same plugin or its native libraries. Resolving it usually means aligning plugin versions or removing the redundant dependency.

The native runtime layer that hosts the web view and bridges JavaScript calls to device APIs in modern mobile builds. Plugin compatibility and native project configuration depend on its version.

The embedded browser component that renders the app's HTML and JavaScript on the device. Its version and configuration affect rendering, performance, and access to certain browser APIs.

A URL that opens a specific screen inside the app rather than the home screen. It requires a registered URL scheme or universal link plus a handler that maps the incoming path to navigation.

The patterns used to move between screens on mobile. Stack pushes and pops screens, tabs switch top-level sections, and drawers hide secondary destinations behind a menu, each with different back-behavior implications.

Logic that intercepts the Android hardware or gesture back action so it closes modals, confirms unsaved changes, or exits predictably. Unhandled back actions can drop users out of the app unexpectedly.

Designing screens with flexible containers, grids, and breakpoints so content adapts to varied phone and tablet sizes. Fixed widths and absolute positioning commonly cause overflow and unreadable text on small devices.

Interaction conventions suited to touch devices, such as large tap targets, bottom navigation, pull-to-refresh, and minimal typing. Following them reduces friction and aligns the app with platform expectations.

Designing and building so users with disabilities can operate the app, including labels for screen readers, sufficient contrast, and focus order. Mobile platforms expose these through semantic properties on widgets.

Adapting text, formats, and layouts to different languages and regions through resource files and locale settings. Mobile apps must also handle right-to-left layouts and locale-specific date and number formats.

Blocking feedback prevents interaction, such as a modal spinner, while non-blocking feedback lets users continue, such as a toast. Choosing correctly affects perceived performance and prevents duplicate submissions.

A client-side action element that runs custom JavaScript in the app's web context. It can manipulate the DOM or call browser APIs but cannot access server data or native device features without a plugin.

Messages delivered to the device through platform services even when the app is closed, requiring permission prompts, device token registration, and server-side sending. Delivery is best-effort and not guaranteed.

The operating system dialog asking the user to grant access to camera, location, notifications, or other capabilities. Denial must be handled gracefully, and repeated prompting is often restricted by the platform.

A development feature that renders the screen at phone or tablet dimensions so layout issues are visible early. It approximates but does not replace testing on real hardware and operating system versions.

Diagnosing issues through device logs, remote inspection of the web view, and error logging sent to the server. Native crashes require platform tooling, while UI bugs are usually inspectable in the browser context.

A setting that keeps a screen instance alive when navigating away, preserving its state and avoiding re-initialization. It speeds up back navigation but can show stale data if not refreshed deliberately.

A mobile-optimized widget that renders a scrollable collection from a data source with efficient recycling of rows. It supports on-scroll loading and empty states, unlike a plain table on large datasets.

Fetching data in pages as the user scrolls rather than all at once, reducing memory use and initial load time. It requires stable sort orders and careful handling of the end-of-list state.

Checking whether the device currently has connectivity so the app can switch between online and offline behavior. Detection is unreliable at the edges, so actions should still handle failed requests gracefully.

Managing version numbers for app builds and store releases so updates install cleanly and users can be prompted to upgrade. Server-side compatibility checks help retire outdated client versions safely.