I85PREP
⌘ K
OutSystems Mobile Developer Specialist study materials
OutSystems Mobile Developer Specialist study resources

OutSystems Mobile Developer Specialist practice questions

One question at a time. Build your OutSystems Mobile Developer Specialist understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1OutSystems mobile development-specific topics

In an OutSystems mobile app, which element is the entry point that the app launches when it starts and that can receive input parameters?

  1. The MainFlow's default screen Correct answer.
  2. A Client Action in the Common module
  3. A Block placed on the layout
  4. A Server Action exposed as a REST API

Explanation

A mobile app boots into the default screen of its MainFlow, which acts as the entry point and can declare input parameters passed at launch. Blocks and actions are reusable pieces, not launch targets. Server actions run on the server and are not app entry points.

Question 2OutSystems mobile development-specific topics

You need a screen to react to the device's network status changing while the user is on it. Which OutSystems mechanism is designed for this?

  1. A Client Variable refreshed by a timer
  2. A System Event such as NetworkStatusChanged handled in the module Correct answer.
  3. The OnApplicationResume event only
  4. A Client Action bound to a screen event

Explanation

OutSystems exposes system events like NetworkStatusChanged that modules can handle to react to device connectivity changes. Timers and resume events do not track live network transitions, and plain screen events are user-triggered.

Question 3OutSystems mobile development-specific topics

Which statement about Local Storage in OutSystems mobile apps is accurate?

  1. It is cleared every time a screen is closed
  2. It persists data on the device between app sessions Correct answer.
  3. It is a synonym for the server-side database
  4. It is shared across all users of the same device automatically

Explanation

Local Storage keeps entities and structures on the device so data survives app restarts and offline periods. It is scoped to the app installation, not shared among users, and is not wiped when a screen closes. It is distinct from the server database.

Question 4OutSystems mobile development-specific topics

A developer wants data captured offline to be sent to the server once connectivity returns. Which OutSystems feature best supports this synchronization pattern?

  1. Screens with the Cache property enabled
  2. Client Variables with the Auto-refresh property
  3. Offline Data Sync with synchronization logic Correct answer.
  4. Server Actions called directly from the layout

Explanation

Offline Data Sync is the OutSystems capability for storing records locally and pushing them to the server when the network is available. Screen caching and client variables only affect UI state, and server actions cannot run while offline.

Question 5OutSystems mobile development-specific topics

Which OutSystems construct lets a mobile developer call a native device plugin capability such as the camera from client logic?

  1. A Timer in the module
  2. A Server Action in a Library module
  3. A Site Property
  4. A Client Action using a plugin action from Forge Correct answer.

Explanation

Native capabilities are exposed through plugin actions that run in Client Actions on the device. Server Actions and Timers execute on the server, and Site Properties are configuration values, not device APIs.

Question 6OutSystems mobile development-specific topics

When building a mobile screen, which layout is recommended so the app follows platform conventions and provides native navigation behavior?

  1. A desktop Side Menu layout
  2. The built-in mobile layout with header and bottom navigation Correct answer.
  3. A layout with no placeholders
  4. A blank web-style layout with custom CSS

Explanation

OutSystems mobile apps use the built-in mobile layouts that provide native-style headers, titles, and bottom navigation. Desktop layouts and blank web layouts do not deliver platform-consistent mobile behavior.

Question 7OutSystems mobile development-specific topics

A list on a mobile screen must load many records efficiently as the user scrolls. Which approach is most appropriate?

  1. Disable pagination and load everything at once
  2. Use a List with the OnScrollEnding event to fetch the next page Correct answer.
  3. Fetch all records into a Client Variable at screen load
  4. Place every record in a single static expression

Explanation

Infinite scroll is implemented by handling the List's OnScrollEnding event to request the next page of data, keeping memory and load time reasonable. Loading everything up front degrades performance on mobile devices.

Question 8OutSystems mobile development-specific topics

Which OutSystems action type executes logic on the device without a round trip to the server?

  1. Service Action
  2. Client Action Correct answer.
  3. Timer
  4. Server Action

Explanation

Client Actions run in the app's JavaScript context on the device, so they avoid a server round trip. Server Actions, Service Actions, and Timers all execute server-side.

Question 9OutSystems mobile development-specific topics

A developer needs to store a small value on the device that persists across screens but is not a database entity. Which is the appropriate choice?

  1. An Input Parameter on the layout
  2. A Site Property
  3. A Local Variable on the screen
  4. A Client Variable Correct answer.

Explanation

Client Variables hold values in the app's client memory and persist across screens within a session. Local Variables are scoped to a single screen, Site Properties are server configuration, and layout parameters pass data into the layout.

Question 10OutSystems mobile development-specific topics

Which statement correctly distinguishes a Screen from a Block in OutSystems mobile development?

  1. A Block can be reused across Screens, while a Screen is a navigable destination Correct answer.
  2. A Block cannot contain widgets
  3. Both can be navigated to by URL
  4. A Screen can be reused inside another Screen, while a Block cannot

Explanation

Screens are navigable destinations, whereas Blocks are reusable UI components embedded in screens or other blocks. Blocks cannot be navigation targets and can contain widgets.

Question 11OutSystems mobile development-specific topics

When passing data from one mobile screen to another during navigation, which mechanism does OutSystems use?

  1. Local Storage keys
  2. Screen Input Parameters set in the navigation action Correct answer.
  3. Global Client Variables only
  4. Server-side session variables

Explanation

Screen navigation actions accept Input Parameters that pass typed data to the destination screen. Client variables and local storage can hold shared state, but the direct, typed way to pass data on navigation is input parameters.

Question 12OutSystems mobile development-specific topics

A mobile app must show a confirmation dialog before deleting a record. Which OutSystems element is designed for this?

  1. A Message action with a Confirmation type Correct answer.
  2. A Web Block on the layout
  3. A Server Action returning a boolean
  4. A Client Variable toggle

Explanation

The Feedback Message action with a Confirmation type presents a native-style confirmation dialog and returns the user's choice. Client variables and server actions do not render dialogs, and web blocks are not dialogs.

Question 13OutSystems mobile development-specific topics

Which OutSystems feature allows a mobile app to use the device's GPS location?

  1. A Server Action calling a REST API
  2. A Timer reading coordinates
  3. A Site Property storing latitude
  4. The Location plugin action invoked from a Client Action Correct answer.

Explanation

Device GPS is accessed through the Location plugin, whose actions are called from Client Actions running on the device. Server-side constructs and configuration properties cannot read device sensors.

Question 14OutSystems mobile development-specific topics

A developer wants to ensure a mobile screen refreshes its data when the user returns to it from another screen. Which approach fits OutSystems mobile behavior?

  1. Assume the aggregate re-runs automatically on return
  2. Rely on the screen's Prepare action running on every back navigation Correct answer.
  3. Use the OnRender event to reload data
  4. Call a Client Action in the OnApplicationResume event only

Explanation

In OutSystems mobile apps, the screen's Prepare action runs when the screen is entered, including when navigating back to it, so it is the place to refresh data. OnRender fires on rendering and re-rendering, and aggregates do not automatically re-execute on return.

Question 15OutSystems mobile development-specific topics

Which statement about using JavaScript in OutSystems mobile apps is correct?

  1. JavaScript can be added through JavaScript elements in screens and blocks Correct answer.
  2. JavaScript replaces all Client Actions
  3. JavaScript cannot access the DOM
  4. JavaScript can only run inside Server Actions

Explanation

OutSystems allows custom JavaScript through JavaScript elements placed in screens and blocks, running on the device. It complements Client Actions rather than replacing them, and it can access the DOM. Server Actions execute server-side.

Question 16OutSystems mobile development-specific topics

A mobile app needs to display a native-style date picker. Which widget choice is most appropriate in OutSystems?

  1. A plain Input with a text mask
  2. A static Text widget
  3. An Expression showing a formatted string
  4. The Date Picker widget bound to a date variable Correct answer.

Explanation

The Date Picker widget provides a native-style date selection control bound to a date variable. Text inputs with masks, static text, and expressions do not offer picker interaction.

Question 17OutSystems mobile development-specific topics

Which OutSystems concept lets a developer reuse a set of client-side actions and variables across multiple screens without duplicating logic?

  1. Copying the action into each screen
  2. A Site Property holding the logic
  3. A Server Action called from each screen
  4. A Client Action in a shared module referenced by the screens Correct answer.

Explanation

Placing shared client logic in a Client Action within a reusable module lets multiple screens reference it without duplication. Copying duplicates maintenance, and server actions and site properties cannot hold client logic.

Question 18OutSystems mobile development-specific topics

A developer needs to display a list where each row shows a different visual template depending on the record type. Which OutSystems approach is best?

  1. A single Expression with conditional text
  2. A Server Action returning HTML
  3. An If widget inside the List Item to switch templates Correct answer.
  4. Multiple Lists stacked vertically

Explanation

The If widget inside the List Item can conditionally render different templates per row based on record data. Expressions only output values, stacked lists duplicate the data source, and server actions returning HTML bypass the UI framework.

Question 19OutSystems mobile development-specific topics

Which statement about the OutSystems mobile app lifecycle event OnApplicationResume is accurate?

  1. It fires when the app is sent to the background
  2. It fires when the app returns to the foreground after being backgrounded Correct answer.
  3. It fires on every screen navigation
  4. It fires only during the first app launch

Explanation

OnApplicationResume is raised when the app comes back to the foreground, making it suitable for refreshing or revalidating data. It does not fire on backgrounding, navigation, or only at first launch.

Question 20OutSystems mobile development-specific topics

A team wants to protect a mobile screen so only authenticated users can open it. Which OutSystems mechanism enforces this?

  1. An Input Parameter named IsAuthenticated
  2. A JavaScript redirect on load
  3. A Client Variable flag checked in the screen's OnRender
  4. The screen's Roles property with role-based access Correct answer.

Explanation

Screens expose a Roles property that restricts access based on the authenticated user's roles, enforced by the platform. Client variables, JavaScript redirects, and parameters are developer-defined and bypassable.

Question 21OutSystems mobile development-specific topics

Which OutSystems feature is used to define a custom native plugin capability when a Forge plugin does not exist?

  1. A Server Action with a REST call
  2. A Timer
  3. A custom plugin built with the OutSystems Plugin API Correct answer.
  4. A Site Property

Explanation

When no Forge plugin covers a native capability, developers build a custom plugin using the OutSystems Plugin API to bridge native code. Server actions, site properties, and timers cannot wrap native device APIs.

Question 22OutSystems mobile development-specific topics

A developer notices a mobile screen's aggregate returns data slowly on first load. Which optimization is most appropriate?

  1. Move the aggregate to a Client Action
  2. Enable the aggregate's Cache in the Screen or use a cached aggregate where appropriate Correct answer.
  3. Remove all input parameters from the aggregate
  4. Convert the aggregate to a static expression

Explanation

Caching aggregates or enabling screen caching avoids repeated server round trips for data that changes infrequently. Client actions cannot run server aggregates, static expressions cannot query data, and removing parameters breaks filtering.

Question 23OutSystems mobile development-specific topics

Which OutSystems construct should be used to store a value that must persist across app restarts on the device as part of the app's local model?

  1. A Session Variable
  2. A Client Variable
  3. A Local Storage entity Correct answer.
  4. A Local Variable

Explanation

Local Storage entities persist on the device across app restarts and sessions. Local and client variables live in memory, and session variables are server-side.

Question 24OutSystems mobile development-specific topics

When should a developer prefer a Server Action over a Client Action in a mobile app?

  1. When the logic must run without network connectivity
  2. When the logic must access the server database or enforce server-side security Correct answer.
  3. When the logic only manipulates screen widgets
  4. When the logic must read the device camera

Explanation

Server Actions are required for database access, server-side validation, and security enforcement that must not be trusted to the client. Offline logic, widget manipulation, and device sensors belong in client actions.

Question 25OutSystems mobile development-specific topics

Which statement about using the OutSystems Debugger with mobile apps is correct?

  1. It requires the app to be offline
  2. It can only debug server-side logic
  3. It only works with desktop layouts
  4. It can debug client-side logic running in the app Correct answer.

Explanation

The OutSystems Debugger can attach to mobile apps and step through client-side logic in addition to server-side execution. It does not require offline mode or desktop layouts.

Question 26OutSystems mobile development-specific topics

In an OutSystems mobile app, which lifecycle event runs on the device when the app is launched and is the recommended place to check for a logged-in user before showing the main screen?

  1. OnApplicationReady Correct answer.
  2. OnApplicationSuspend
  3. OnApplicationError
  4. OnApplicationResume

Explanation

OnApplicationReady fires once when the application starts on the device and is the standard place to run startup checks such as session validation and routing to login. The other events fire on resume from background, on suspension, or on an unhandled error, so they are not the startup hook.

Question 27OutSystems mobile development-specific topics

A developer needs a mobile screen to be reachable only after login, and unauthenticated users should be redirected instead of seeing the screen. Which OutSystems configuration enforces this per screen?

  1. Set the screen's Cache Level to Screen
  2. Set the screen's Roles property to the authenticated role Correct answer.
  3. Add a Client Action that hides the screen widgets
  4. Mark the screen as a Public screen

Explanation

Assigning roles to a screen makes the platform check the user's session before the screen is rendered and redirect unauthenticated users. Hiding widgets with client logic is cosmetic and can be bypassed, and cache level or public access do not restrict entry.

Question 28OutSystems mobile development-specific topics

Which OutSystems mobile widget is the correct choice to present a list of records where the user taps a row to open a detail screen?

  1. Table widget with editable cells
  2. List widget with a List Item containing the row content Correct answer.
  3. Web Block placed directly on the screen
  4. Form widget with a single input

Explanation

The List widget is the mobile-native pattern for record collections and supports row taps for navigation to detail screens. Tables, forms, and bare web blocks do not provide the same native list behavior or efficient row rendering.

Question 29OutSystems mobile development-specific topics

A developer wants to call a REST API that requires a secret API key that must never be visible to users of the mobile app. Where should the call be made?

  1. In a JavaScript snippet on the screen
  2. In the OnApplicationReady client event
  3. In a Client Action using the HTTPRequest handler
  4. In a Server Action that invokes the REST API Correct answer.

Explanation

Server Actions run on the OutSystems server, so credentials stored server-side are never shipped inside the app package. Client Actions, JavaScript, and client lifecycle events all execute on the device and would expose the secret.

Question 30OutSystems mobile development-specific topics

Which statement describes how OutSystems mobile apps obtain data for a screen by default?

  1. Aggregates and Data Actions fetch data from the server when the screen loads Correct answer.
  2. Data is fetched only when the user pulls to refresh
  3. All entity data is downloaded to the device at app install
  4. Screens read directly from a local SQLite database without server calls

Explanation

Mobile screens fetch their data through server-side aggregates and data actions when the screen is prepared or refreshed, then hold it in the screen's client state. The app does not preload the whole database at install, and reads are not limited to pull-to-refresh.

Question 31OutSystems mobile development-specific topics

A developer needs to show a brief non-blocking message at the bottom of a mobile screen after a save succeeds. Which OutSystems element is intended for this?

  1. Confirmation Dialog
  2. Modal Dialog
  3. Feedback Message widget Correct answer.
  4. Popup Editor

Explanation

The Feedback Message widget displays short transient notifications such as success or error toasts on mobile screens. Dialogs and popup editors are blocking UI meant for user decisions or forms, not brief status messages.

Question 32OutSystems mobile development-specific topics

Which OutSystems capability lets a mobile app store data on the device so it remains available when the device is offline?

  1. Site property
  2. Screen input parameter
  3. Local Storage entity with synchronization logic Correct answer.
  4. Session variable

Explanation

Local Storage entities are persisted on the device and can be synchronized with the server, which is how offline data is kept. Session variables, screen parameters, and site properties do not persist records on the device across restarts.

Question 33OutSystems mobile development-specific topics

A mobile screen must display a numeric rating from 1 to 5 where the user picks a value by tapping stars. Which OutSystems approach fits best?

  1. Use a Checkbox for each star
  2. Use a Dropdown with the values 1 to 5
  3. Place five tappable icons in a container and store the selected value in a local variable Correct answer.
  4. Use an Input widget with the Number data type

Explanation

Custom tappable icons bound to a local variable give the star-rating interaction the design requires. A numeric input, dropdown, or checkboxes change the interaction pattern and do not present tappable stars.

Question 34OutSystems mobile development-specific topics

A list on a mobile screen must keep working when the device has no connectivity, showing previously loaded records. Which OutSystems design achieves this?

  1. Convert the aggregate into a Data Action
  2. Increase the screen's cache level to Screen
  3. Store the records in a Local Storage entity and read the list from it Correct answer.
  4. Add a retry loop around the aggregate

Explanation

Local Storage entities persist records on the device, so the list can be populated from local data when the network is unavailable. Cache levels, retries, and data actions all still depend on a successful server call.

Question 35OutSystems mobile development-specific topics

A developer needs to call a device capability such as the camera from a mobile app. Which OutSystems building block provides this?

  1. A REST API consumed by an aggregate
  2. A Server Action in the app module
  3. A scheduled job in the module
  4. A mobile plugin action exposed through the Platform APIs Correct answer.

Explanation

Device capabilities are accessed through mobile plugins and platform APIs that wrap native code and are called from client logic. Server Actions, REST aggregates, and scheduled jobs run on the server and cannot access the device hardware.

Question 36OutSystems mobile development-specific topics

When a mobile app is upgraded and a Local Storage entity gains a new attribute, what must the developer account for in the synchronization logic?

  1. Disable synchronization permanently
  2. Delete the entity and recreate it with a new name
  3. Handle the schema change so existing on-device records are migrated or refreshed Correct answer.
  4. Nothing, because local storage is recreated on every launch

Explanation

Local Storage entities persist on the device across app upgrades, so a schema change requires migration or refresh logic to avoid stale or incompatible local records. Local storage is not wiped on launch, and renaming or disabling sync are not valid migration strategies.

Question 37OutSystems mobile development-specific topics

A developer wants the same header with a menu and a logout action reused on many mobile screens. Which OutSystems element is appropriate?

  1. A Block placed on each screen Correct answer.
  2. A Site Property holding the header markup
  3. A Client Action called from each screen
  4. A Screen with the header layout

Explanation

Blocks encapsulate reusable UI plus their own logic and can be placed on multiple screens, which keeps the header consistent. Screens are navigable destinations, client actions hold logic only, and site properties store configuration values.

Question 38OutSystems mobile development-specific topics

A developer needs to run logic when the user navigates away from a mobile screen, for example to save draft input. Which screen event is designed for this?

  1. OnRender
  2. OnInitialize
  3. OnDestroy Correct answer.
  4. OnReady

Explanation

OnDestroy runs when the screen is being closed or replaced during navigation, making it the right place to persist draft state. OnInitialize and OnReady run during screen creation, and OnRender relates to rendering rather than leaving the screen.

Question 39OutSystems mobile development-specific topics

A mobile app must display a large catalog with images and smooth scrolling. Which design choice best supports performance?

  1. Load the full catalog into a local variable at startup
  2. Render all records in a single container at screen load
  3. Use a List widget bound to a paginated aggregate and load images lazily Correct answer.
  4. Use nested Tables for every record

Explanation

A List widget with pagination fetches records in pages and only renders visible rows, which keeps scrolling smooth. Rendering everything at once, nesting tables, or loading the whole catalog at startup all increase memory and load time.

Question 40OutSystems mobile development-specific topics

Which statement about mobile app navigation in OutSystems is correct?

  1. Navigation between screens is defined in the app's flow and executed with navigation actions Correct answer.
  2. Navigation requires a full server round trip for every screen
  3. Screens are opened by directly manipulating the browser URL
  4. Only modal dialogs can move between screens

Explanation

Mobile navigation is modeled in the app flow, and client-side navigation actions move between screens while passing inputs. It does not rely on editing URLs, does not require a server round trip per screen, and is not limited to dialogs.

Question 41OutSystems mobile development-specific topics

A developer needs to show a list of items where each item can be swiped to reveal a delete action. Which OutSystems approach is most appropriate?

  1. Use the List widget's swipe gesture support with a client action for delete Correct answer.
  2. Use a Checkbox per row and a global delete button
  3. Place a Button next to every row
  4. Open a Modal Dialog for each row automatically

Explanation

The List widget supports swipe gestures on mobile rows, which can trigger a client action such as delete. Buttons, checkboxes with a global action, or automatic dialogs change the interaction and do not provide swipe-to-delete.

Question 42OutSystems mobile development-specific topics

A client action needs to show a loading indicator while a server call completes. Which OutSystems mechanism handles this?

  1. Block the UI thread until the call returns
  2. Disable the screen's OnReady event
  3. Rely on the device to show a spinner automatically
  4. Use the built-in feedback from the screen's data fetching or a local variable that toggles a spinner Correct answer.

Explanation

OutSystems mobile screens show built-in loading feedback for data fetching, and a local variable can toggle a custom spinner around explicit calls. Blocking the UI thread, assuming automatic spinners for all calls, or disabling events are not valid techniques.

Question 43OutSystems mobile development-specific topics

Which OutSystems feature should be used when a mobile app must receive push notifications?

  1. A push notification plugin configured with the platform's notification service Correct answer.
  2. An aggregate refreshed every second
  3. A scheduled job that polls the server
  4. A screen timer that checks for messages

Explanation

Push notifications on mobile require a plugin that registers the device with the platform notification service and handles incoming messages. Polling jobs, screen timers, and rapid aggregates do not deliver push messages and waste battery.

Question 44OutSystems mobile development-specific topics

A developer must ensure a mobile app works correctly on both iOS and Android with platform-specific styling. Which OutSystems approach supports this?

  1. Force a single custom style on both platforms
  2. Build two separate apps with duplicated logic
  3. Use the platform's native UI patterns and apply platform-specific CSS classes where needed Correct answer.
  4. Use only web-style tables for all layouts

Explanation

OutSystems mobile apps can follow each platform's native patterns and apply platform-specific styling through CSS classes, keeping one codebase. Duplicating apps, forcing one custom style, or using web tables breaks platform conventions and maintainability.

Question 45OutSystems mobile development-specific topics

A developer needs to pass a record identifier from a list screen to a detail screen and also allow the detail screen to be opened directly from a deep link. Which design is best?

  1. Encode the identifier in a client action name
  2. Define an input parameter on the detail screen and supply it from both navigation paths Correct answer.
  3. Rely on the session variable from the list screen
  4. Store the identifier in a global variable set only by the list screen

Explanation

Screen input parameters make the dependency explicit and let both list navigation and deep links supply the identifier. A global variable or session value set only by the list screen would be empty on a direct deep link, and action names cannot carry data.

Question 46OutSystems mobile development-specific topics

A mobile app must synchronize offline changes with the server and resolve conflicts when the same record was edited on two devices. Which OutSystems design is most robust?

  1. Discard local changes whenever connectivity returns
  2. Overwrite server data with whatever the device sends
  3. Track a last-modified timestamp per record and apply a defined conflict rule during synchronization Correct answer.
  4. Synchronize only on app install

Explanation

Recording modification timestamps lets the synchronization logic detect stale writes and apply a clear conflict resolution rule such as last-write-wins or manual merge. Blind overwrite, discarding local edits, or syncing only at install lose data or hide conflicts.

Question 47OutSystems mobile development-specific topics

A developer observes that a mobile screen re-fetches data every time the user returns to it, causing slow navigation. Which OutSystems change best addresses this?

  1. Increase the number of screen parameters
  2. Disable the OnDestroy event
  3. Convert all aggregates into client actions
  4. Keep the needed data in the app's client state or a local variable and refresh only when necessary Correct answer.

Explanation

Caching fetched data in client state or a local variable avoids repeated server calls when returning to a screen, and refreshes can be triggered only when data may be stale. Converting aggregates to client actions does not remove the server call, extra parameters do not help, and disabling OnDestroy affects cleanup logic.

Question 48OutSystems mobile development-specific topics

A team needs a custom native capability that no existing Forge plugin provides. What is the correct OutSystems path?

  1. Use a REST API to call the device hardware
  2. Embed raw native code in a JavaScript snippet
  3. Build a custom plugin using the Mobile Plugins capability and expose its actions to the app Correct answer.
  4. Write server-side C# in a Server Action to call device APIs

Explanation

When no plugin exists, developers create a custom mobile plugin that wraps the native code and exposes actions callable from client logic. Server-side C# cannot reach the device, JavaScript cannot access arbitrary native APIs, and REST calls cannot invoke local hardware.

Question 49OutSystems mobile development-specific topics

A developer is debugging a client action in a mobile app running on a device. Which statement about the OutSystems debugger for mobile is accurate?

  1. The debugger can attach to the mobile app and step through client actions executed on the device Correct answer.
  2. Breakpoints are not supported in client actions
  3. Debugging mobile apps requires deploying a separate debug build to the store
  4. The debugger only works for server actions and ignores client logic

Explanation

The OutSystems debugger supports mobile apps by attaching to the running app so client actions can be stepped through on the device. It is not limited to server actions, does not require a store release, and does support breakpoints in client logic.

Question 50OutSystems mobile development-specific topics

A mobile app must enforce that a list only shows records the logged-in user is allowed to see, even if the client is tampered with. Where should the filtering be applied?

  1. In the screen's CSS rules
  2. In JavaScript that hides unauthorized rows
  3. In the server-side aggregate or data action using the user's session identity Correct answer.
  4. In a client action that filters the list after download

Explanation

Authorization filtering must happen on the server using the authenticated session so a tampered client cannot retrieve forbidden records. Client-side filtering, JavaScript hiding, and CSS only affect what is displayed after data has already been sent.