Neuxnet Mini Apps can run in various types of mobile applications (such as desktop applications and mobile applications), and when the Mini App is launched, the required running environment and capabilities need to be provided to the Mini App by the client application. We refer to this environment as the "hosting environment (host application)", and through the hosting environment, the Mini App can achieve many functions that native applications and H5 applications cannot achieve.

1. Logical layer vs. view layer

The runtime environment of the MiniApp can be divided into 2 parts, namely the Logical Layer and the View Layer.

The logic layer is used to load the JS script in the MiniApp that handles the business logic, while the view layer is used to render the FXML template and FTSS style to display the final page. In the MiniApp, the logical layer and the view layer are managed by 2 separate threads:

• The logic layer uses the JS Core engine to run JS scripts to process business logic;
• The render layer interface renders using WebView (multiple WebView threads exist in a miniprogram if there are multiple pages).

Therefore, there is only one JS Core thread and multiple WebView threads in a Mini App application.

The overall runtime environment and communication model of the Mini App are shown in the following figure:

As a hosting environment, mobile or desktop applications need to interact with the logical layer and the view layer respectively, and there can be no direct communication between the two, only through the hosting environment.

2. Programs and pages

When you open the Mini App in the host application, the code package of the Mini App is downloaded locally, and then by parsing the pages field in the app.json, you can know all the page paths of the Mini App:

{
  "pages":[
    "pages/index/index",
    "pages/logs/logs"
  ]
}

The first value in the pages array is the first page that the MiniApp sees when it opens. The path of each page can be found in the code package corresponding to the file path.

For example pages/index/index, under this path, there are FXML, FTSS and JS files corresponding to this page. After the Mini App is started, the code file in the corresponding page will be found according to this path, and then handed over to the logic layer and the view layer for execution, so that we can see the page of the Mini App on the host App.

When the MiniApp starts, it triggers the onLaunch method defined in the app .js

App({
  onLaunch: function () {
    Execute after the Mini App starts
  }
})

Let's take a closer look at the page structure and specific composition of the Mini App, taking pages/index/index as an example, there are index.js, index.fxml and index.ftss in the file directory.

The content of the index .js
Get the application instance
const app = getApp()

Page({
  data: {
    motto: '',
  },
  Event handlers
  bindViewTap() {
    ft.navigateTo({
      url: '.. /logs/logs'
    })
  },
  onLoad() {
    this.setData({
      motto: 'hello world'
    })
  }
})

In the index.js file 'Page({...}) ' constructs an index page instance, and 'data' represents the rendering data that the page needs to use. When the page is generated, the Mini App engine combines the 'data' data with the 'index.fxml' and renders it to display to the user.

The 'onLoad()' method is the life cycle method of the page, which is called back when the page is created, and developers can define their own logic in it.

More information about code structure can be found in Neuxnet Development Documentation - Code Structure

3. Component

Components are MiniApps that developers provide to create page UI and customize FXML. Developers can freely combine various components in a flexible way to build their own page UI.

What are components:

• The use of components in FXML is the basic building block of the view layer.
• A component usually consists of a start tag and an end tag, and attributes are used to decorate the component, with the content within two tags.

Note: All components and attributes are lowercase, hyphen-concatenated

Just like HTML tags, in the Mini App, developers can write the tags of the corresponding components in FXML to display them. For example:

index.fxml content
<view class="intro">Welcome to Neuxnet</view>

The page displays a line of copy: 'Welcome to Neuxnet'. Developers can control the style of the component through style and class, specifying width, height, color, and so on.

More content about components can be found in Neuxnet Development Documentation

4. API

In order to make it easier for developers to use the capabilities provided by the Mini App, Neuxnet provides a variety of APIs for developers to use, developers can use these APIs to modify the Mini App interface, obtain the current location of the device, play video, audio, etc.

THE API is divided into synchronous and asynchronous, the synchronous API will return the result directly, and the asynchronous API will return the result through the callback. Developers need to process the logic according to the CALLback method of the API, and pass in the correct parameters to process the business.

For example, 'setStorageSync' is a synchronous API and 'setStorage' is an asynchronous API:

ft.setStorage({
  key: 'key',
  data: 'value'
})

try {
  ft.setStorageSync('key', 'value')
} catch (e) { }

More content about components can be found in Neuxnet Development Documentation-API