To effectively leverage io.Connect, it’s important to understand its main integration paradigms, particularly Contexts, Intents, and Interop APIs, and how they differ. Here we break down these concepts in business terms:
Data sharing
When we want to share data across applications, we use Shared Contexts & Channels
Shared Contexts (programmatic Data Sharing)
io.Connect enables a shared context model, which is essentially a way for apps to share data in real time. Think of a “shared context” as a shared document on the desktop that apps can read/write. For example, all apps dealing with “Customer X” can refer to a shared customer context – when one app updates it (say the customer ID changes to a new selection), all other apps see the change and update themselves. This is analogous to multiple departments referencing the same customer profile: if a sales representative updates the address, support and finance automatically get the updated info.
The API allows developers to set, get, update context; list (all contexts); and subscribe/unsubscribe to context updates.
Channels (empowering end users)
Channels are a user-friendly extension of shared contexts: they allow the user to decide which apps should sync with which by joining them to the same channel (often represented by a color or name). For instance, a user can link a chat app and a document editor on the “Project Alpha” channel so that selecting a project in one filters the other to that project’s content. The business value is less manual coordination – information flows to where it’s needed. Users experience a contextually aware desktop where, for instance, selecting a client in CRM instantly filters the billing system and support ticket system to that client. This reduces errors and time spent re-entering or cross- referencing data.
Users are offered a Channel Selector which allows for a) Standard Channels and b) Directional Channels
Workspace Context (multi-tasking without confusion)
A Workspace context is a variant of the above but scoped per workspace. If a user handles multiple clients or projects, each in a separate workspace (tab), io.Connect can maintain a distinct context for each. This means App A in Workspace 1 won’t accidentally sync data with App A in Workspace 2 because they are dealing with different contexts (Client A vs Client B). For decision makers, this translates to better multi-tasking support – your users can juggle multiple workflows in one application frame without data bleeding over incorrectly. It ensures accuracy and clarity when users handle concurrent tasks.
Window Context
For even finer control, each io.Connect Window has its dedicated context (key/value JSON) that you can set, read, update, and subscribe to changes for. Use it when a single window needs its own local state (e.g., which tab or record it shows) that shouldn’t leak to other windows/Workspaces.
How does Window context differ from Workspace context?
Workspace context is scoped to a Workspace and retrieved via the Workspaces API, so multiple windows in that Workspace share that Workspace-level state; a window’s own context is just for that instance.
Workflow Automation Across Apps
In addition to data, if io.Connect allows us to trigger actions building real workflows. This is done by interop methods and intents:
Interop Methods & Streams (Service Reuse and Data Feeds)
Interop Request/Response
This capability turns applications into services for each other. Any app can expose a function (method) or data feed, and others can consume it. In business terms, this encourages reuse of functionality: you might already have a risk calculation engine in one app; with io.Connect, another app can directly call that engine instead of re-implementing logic. It’s SOA (Service-Oriented Architecture) approach applied to the desktop. For example, if your analytics system can calculate a customer’s lifetime value, your customer service app could call that calculation via an interop method whenever needed, rather than maintaining its own calculator. This reduces duplication and ensures consistency (everyone uses the same underlying logic).
Interop Streaming
Streaming is particularly useful for scenarios like live data (market data, IoT feeds, etc.), one component can publish updates and many others can subscribe. The result is real-time situational awareness across your platform. For instance, a trading app could stream price updates that both the portfolio app and the alerting system subscribe to, so they all react to the same market changes in lockstep.
Intents (allow users to select actions)
Intents can be seen as verbs in the system – actions that a user might want to perform, which an appropriate application can fulfil. For example, ‘SendEmail’ might be an intent that various apps could handle (Outlook, Gmail client, CRM’s email module). With io.Connect’s Intents, your applications advertise what actions they can perform (and what data they need to do it), and other apps can call those actions without hardcoding a dependency. From a business perspective, this means you can design end-to-end workflows spanning multiple apps. If step 3 of a process is usually done in a certain application, an intent can launch that step directly. Users might click a button in App A and io.Connect will automatically launch App B at the correct screen with the relevant data.
The Intents Resolver UI ensures user control and transparency when needed – if multiple options exist to complete a task, the user is prompted to choose (thus encouraging an open ecosystem of tools). This fosters an environment where best-of-breed apps can be combined fluidly: e.g., one department’s tool can trigger another department’s tool in context, improving handoff efficiency. Essentially, Intents let software handle the “app switching” and data handoff that users would otherwise do manually.
Pub/Sub
Pub/Sub lets apps broadcast on a topic and any app subscribed to that topic receives the message.
Pub/Sub can be handy when you’re integrating with an existing pub/sub-style component. If you’re designing new cross-app flows, Interop methods Request/Response, Streaming, Discovery, or Shared Contexts will usually be more robust and save time. Pub/Sub lacks discoverability, persistence or user control.
The table below summarizes these integration mechanisms and their typical usage in business scenarios:
| Integration Feature | What it does | Business Use Case & Value |
|---|---|---|
| Shared Context (Global) | Shares state (data) globally among apps in real time. Raise events for context updates. Stateful. | Use Case: When applications should stay in sync on core data e.g., in a call centre, when an agent pulls up Customer #123 in the CRM, the billing system and support ticket system automatically jump to that customer’s records. Value: Reduces duplicate lookups and errors, speeds up service by having all relevant info update instantly across tools |
| Channels (User-Driven Context Linking) | Lets end-users group apps to share context. | Use Case: A financial analyst might group her charting app and trading app on a “Tech Stocks” channel and another set of apps on an “Energy Stocks” channel. Switching context in one group doesn’t affect the other. Value: Empowers end-users to configure their own linked workflows on the fly, increasing flexibility and personalization of the workspace |
| Workspace Context (Scope Isolation) | Keeps context sharing local to a workspace | Use Case: A sales manager handling multiple clients opens each client’s info in a separate workspace. Each workspace’s apps sync only with their Context sharing local to workspace’s client context. Value: Safer multi-tasking, no cross-talk between parallel tasks. Users can concentrate on one context at a time, and data from one client/project doesn’t overwrite or mix with another’s by accident. |
| Window Context (Per-Window State) | A JSON context attached to a single window | Use Case: keep a window’s local state (e.g., which client row is open, UI toggles) without leaking into other windows/workspaces. Value: predictable restore behavior and cleaner state management per instance. |
| Intents (End user Selectable) | Orchestrates actions across apps by intent name. Register, discover, raise intents, or discover apps that offer intents. | Use Case: “Analyse Trade” intent - from a trade blotter app, raising this intent could either open a risk analysis app or a compliance app, depending on user choice or config. Value: Streamlines complex processes that involve multiple systems. Users trigger the process and are seamlessly taken to the next step in the appropriate application with context carried over (no re-entry). This reduces training complexity (users follow a natural flow) and improves productivity by automating app switching. |
| Interop Methods Request/Response (Cross-App Workflows) | Allows an app to call functions of another (like an API call). Expose functionality. Discover methods and servers. | Use Case: A customer-facing app needs credit score calculation – instead of building it anew, it calls an existing “calculateCreditScore” method offered by the credit department’s service app (Application with existing functionalities which you want to offer to other apps). Value: Promotes reuse of business logic, ensuring all parts of the organization use consistent algorithms/rules. It also speeds up development (integrate rather than reinvent) and can extend the life of legacy systems by exposing their functions to new interfaces. |
| Interop Methods Streaming (Real-Time Feeds) | Publisher subscriber model for continuous updates , real-time data and events. Branching streams. | Use Case: A central market data feed app publishes stock-prices; multiple trader tools, dashboards, and alert systems all subscribe to this feed to get updates in real time. Value: Ensures timely propagation of critical data. Every system gets simultaneously, maintaining a single source of truth for live data. In finance, this can be the difference in responding to market changes coherently. |
| Pub/Sub (Topic Broadcast) | Publish on a topic and deliver to apps subscribed to that topic. Subscribe for messages on a specific topic. | Use case: broadcast lightweight events (e.g., ‘client:selected’, ‘ticker:update’) to multiple tools; optionally limit delivery to specific apps/roles. Value: quick fan-out without wiring RPC handlers or streams; handy for porting existing pub/sub integrations. |
By leveraging these mechanisms, architects can achieve an architecture of reusable components and interoperable services on the desktop. It moves your organization away from monolithic app silos to a more composable enterprise desktop. Each app can focus on its specialty, but is no longer an island; it becomes part of a mesh of capabilities.