DOCSEARCHbyAlgolia
Submit Docs

BuildFire SDK Documentation

website·Indexed 41 days ago

https://sdk.buildfire.com/docs

Developer documentation for building plugins using the BuildFire.js framework. Includes guides on plugin development, environment setup, and the BuildFire CLI, as well as API references for components and services such as buildfire.userData, buildfire.searchEngine, buildfire.services.stripe, and buildfire.services.commerce.inAppPurchase.

Tokens
107.8K
Snippets
592
Records
741
Agent score
58%

What's inside BuildFire

  1. Overview of buildfire.publicData

    buildfire.publicData is a framework in buildfire.js that allows app users and owners to perform CRUD operations on JSON data. It manages server-side infrastructure and caching automatically. Data saved via publicData is accessible to all users on the current plugin. For data that needs to be shared across different plugins, use appData instead.

  2. Overview of buildfire.appData

    buildfire.appData is a framework in buildfire.js that allows app users and owners to perform CRUD operations on JSON data. Unlike publicData or userData, appData is specifically designed to let different plugins within the same app share data in a consistent way. It is accessible to all users across all plugins and handles all server-side infrastructure and caching automatically.

  3. Overview of the BuildFire Credit System API

    The buildfire.services.credits API allows plugin developers to manage and consume user credits.

    Key Constraints:

    • Users must be logged in and authenticated for API calls to succeed.
    • Credit bundles are configured via the BuildFire Control Panel and cannot be created or modified through the SDK API.

  4. Overview of buildfire.pluginInstance

    The buildfire.pluginInstance object allows developers to interact with plugin instances added to the current app context. A plugin instance is a specific occurrence of a plugin type; for example, an app can have one Text Plugin installed but multiple instances of that plugin. This is commonly used in launcher or folder-type plugins to help users navigate to other plugins.

    Caveat: Avoid saving plugin instance data to a local datastore, as instances may be deleted or modified. Use Dynamic Data Injection to ensure the latest data is retrieved.

  5. Overview of buildfire.services.keyStore

    The Key Store service provides a secure flow for creating, recovering, and changing user PIN codes and managing encrypted key pairs. It is designed for implementing end-to-end encrypted user data and PIN-protected flows.

    Key Architectural Principles:

    • Private Key: Generated on the user's device and never stored on Buildfire servers. Developers must store this locally on the device.
    • Encrypted Private Key: The private key is encrypted using a key derived from the user's PIN and stored on the Buildfire server. It can only be decrypted with the correct PIN.
    • Public Key: Stored on the server and accessible at any time.
    • PIN Recovery: Buildfire does not know the user's PIN. If a user resets their PIN, a brand new key pair is generated, and any data encrypted with the previous key becomes permanently unreadable.

    Constraint: This service is not available on HTTP domains. You must use HTTPS, the Buildfire Previewer, or production app builds.

  6. Overview of buildfire.components.carousel

    The buildfire.components.carousel namespace provides two primary classes for managing image carousels: editor for the control side (adding, editing, and deleting images) and view for the widget side (displaying images and handling user interactions).

    Note: This component is deprecated. It is recommended to use the Light Carousel instead.

  7. Overview of buildfire.components.carousel

    The buildfire.components.carousel namespace provides two primary classes for creating carousel functionality: the editor class, used on the control side to manage images and items, and the view class, used on the widget side to display the carousel and handle user interactions.

  8. Overview of Buildfire Deep Links

    A deep link in Buildfire is a custom protocol/schema (different from http/https) that allows a user to open the app and navigate directly to a specific plugin or a specific state within a plugin. Deep links can be registered to be used with action items, enabling users to navigate to a plugin while passing specific identifying data.

  9. Overview of buildfire.datastore

    The buildfire.datastore framework allows plugin developers to save and retrieve simple and complex JSON data without managing server-side infrastructure.

    Key Constraints:

    • Purpose: Intended for CMS Data.
    • Permissions: Read/Write permissions on the control side; Read-only permissions on the widget side.
    • Limitations: Does not support indexes and is not intended for large amounts of data.
    • Synchronization: Automatically handles synchronization and notifications between the control and widget sides.

  10. Overview of BuildfireJS for plugin development

    BuildfireJS (buildfire.js) is a framework that enables JavaScript developers to build and extend plugins for the Buildfire Mobile App Building Platform. It allows developers to use their existing JavaScript technology stack to create mobile app functionality.

  11. Overview of buildfire.userData

    buildfire.userData is a framework in buildfire.js used to save and retrieve simple and complex data. It provides built-in server-side infrastructure, caching, and performance enhancements.

    Key Constraints:

    • Permissions: Data is saved from the widget side and is only accessible to the user who initiated the request and only within the current plugin.
    • Scope: For data accessible to other users, use publicData. For data accessible by other plugins, use appData.

  12. Overview of buildfire.analytics

    The buildfire.analytics module allows developers to track plugin views and user actions. Events are sent to Buildfire's analytics server and forwarded to the developer's configured segment.io account.

    Security Warning: Events are accessible to Buildfire, White Label owners, and app owners. Do not send sensitive information (e.g., passwords) or data that violates user privacy.