Skip to main content

Installing Atomic SDKs

Overview

Atomic provides SDKs for client developers to integrate into their mobile and web apps. The SDKs provide the UI and functionality for displaying streams of cards, displaying response views, responding to cards, theming and analytics, all via the Atomic Platform.

SDKs are available for:

SDK Guiding Principles

All Atomic SDKs adhere to the following guiding principles. These principles inform the development of each SDK, making them performant, reliable and easy to integrate.

Lean

Atomic SDKs are designed to be as small as possible, generating a low space and memory footprint in your own app. For example, as of 26 April 2024 the sizes of our SDKs are:

SDKVersionSize
Android24.1.22.1MB (AAR only)
iOS24.1.24.2MB (arm64 including resources)
Web/Cordova24.1.0365KB (gzipped)
ReactNative23.3.111.8MB (Unpacked Size)
Flutter23.4.0119KB (Dart code)

We also build our SDKs with as few 3rd party dependencies as possible; this allows us to more readily update our SDKs for new versions of operating systems or browsers, reducing the risk of ensuring that 3rd party dependencies also work.

Native

Atomic SDKs are native, leveraging the performance and architectural patterns of each platform. Our native SDKs not only result in great performance, but also make integration easy, as they follow predictable patterns for instantiation and manipulation. We regularly review the performance of our SDKs across our supported devices, to ensure they continue to run smoothly.

Cross platform parity

Atomic's SDKs offer the same features and functionality across platforms, but aim to follow standard UI and behavioral conventions for each. This means there may be minor differences in how features appear on different platforms.

Our documentation highlights those instances where feature parity hasn't been achieved, e.g. in the Card element reference section. The workbench's Theme editor UI shows icons where certain settings are only available in a specific platform. The screenshot below shows the menu mask setting is only available in the Android and iOS SDKs.

Easy to integrate

Our developers leverage their experience integrating SDKs to understand the key points that make SDK integration difficult and easy. Those lessons have been applied to the Atomic SDKs, making them easy to integrate. The integration process is supported by code-level documentation and readmes.

Performant

We appreciate how important it is for you to have a fast app experience for your customers. We ensure our SDKs have a negligible impact on performance. We use WebSockets as the default approach to acquire the card feed, so the update speed is almost real-time. However, we still have HTTP polling as a fallback and in that case you can ensure your apps remain performant by setting the polling interval to be only as low as is required.

Well-tested

Atomic SDKs have extensive automated test suites that run as part of our build pipeline. Unit tests and snapshot tests help ensure that visuals and functionality do not change unexpectedly between releases, and also help us understand the impact of future changes, new operating system releases and browser versions.

Dependencies

Our Android SDK has some dependencies, which we list in the Dependency Graph section of our Android SDK article.

Changelogs

Changelogs are supplied with each new release of the SDKs, detailing the changes made and potential impact on existing integrations.

View the Changelog

Stream containers

Each Atomic SDK provides a stream container. A stream container provides UI to render a list of action cards, generated from a single stream. The stream rendered inside of a stream container is configurable via the Workbench. While each stream container displays cards from only one stream, a stream may display its cards in multiple stream containers.

A stream container is identified by a unique key - this key is displayed in the Workbench and is specified in code when configuring a stream container using the SDKs. By identifying a stream container by its key, a different stream can be displayed in a stream container (using the Workbench) without requiring a re-release of your app. Your app can contain multiple stream containers, or multiple instances of the same stream container if desired.

Stream containers have been built with isolation in mind - they are designed to exist on their own without impacting other stream containers in your app.

Stream containers can be rendered in a variety of modes - the modes differ for each platform. See the “Display modes” documentation of each platform for more on the available modes.

Logging

To support integration of the Atomic SDKs, verbose logging can be enabled, which logs detailed information on key events in the SDK lifecycle.