I’m writing this article to clear my head, to sort out what I’ve seen and what I’ve crossed. This cannot represent the amount of coverage of official documents. It is strongly recommended to read this article after reading the official documents, at least to clear up some unclear points. I hope this set of steps can increase the success rate of novice access, hope you learn from it, benefit. That was my original intention.

The UNI developer asked me for SDK files. Since I had written an SDK before, I left the SDK to the UNI developer for him to configure, but it failed anyway. I thought, isn’t UNI supposed to replace the native development? Why can’t I even use the framework? I found out later that I was careless. After perusing the document, I began my climb into a pit harder than giving birth.

Preparation stage

  • Xcode
  • HBuilderX
  • Uni – SDK package

First, develop plug-ins

Plug-in development includes three aspects: making. Framework or. A project, importing and making, and packaging UNI functions.

Make a native framework or Library

In UNI development, iOS native plug-ins represent framework or.a files. So first create a project that looks like this, see the Framework Project Guide (Swift).

Framework files are not available in UNI, refer to the instructions above (steps 1-6) and import them into the HBuilder-UniPlugindemo project

2. Import the plug-in

1. Drag the newly created project file to the hBuilder-uniplugindemo subdirectory and open the hBuilder-uniplugin. xcodeProj project in the same directory

2. Right-click the main Project and choose Add Files to “Project… , select the XcodeProj file in the plug-in directory, divided into the following two steps

3. Import the framework

Select the main engineer-target-Build Phases

4. Import the header file path

Select project – targets – Build Settings for plug-in

DCUni header files and Weex header files are stored in INS, so you must specify the import path

5. Create an OC file inherited from DCUniModule and DCUniComponent as required

All the import steps have been completed, but if you want to run them fully, you need to:

Check plug-in associated items

Configure the interface code for the specification

3. Code specification

Native plug-in is based on DCUniPlugin specification to realize the extension of native functions, its features include:

  • Module: Does not need to be involved in page layout, just to enable UNI to call native.
  • Component: Requires direct involvement in UNI page layout.
  • You can have multiple files in a plug-in at the same time to increase its different capabilities and functionality divisions.

(1) the uni – app

Module const swiftSdk = uni. RequireNativePlugin (" swiftobject-swiftModule "); Let bl = swiftsdk. swiftLogFunc({log: "Ok"}, (function (e) {/ / callback number results on the console. The log (e)})) # call synchronization method var. Ret = swiftSdk swiftLogWithBoolFunc ({' ok ':' uni - app '})Copy the code

(2) Native Module

Module, for example, can be divided into synchronous and asynchronous methods:

Asynchronous method (no return value, callback)

UNI_EXPORT_METHOD(@selector(swiftLogFunc:callback)); -(void)swiftLogFunc:(NSDictionary *)options callback:(UniModuleKeepAliveCallback)callback { NSString *log = options[@"log"]; callback(@{@"success": log},NO); }Copy the code

Synchronous method (with return value)

UNI_EXPORT_METHOD(@selector(swiftLogWithBoolFunc:))
-(BOOL)swiftLogWithBoolFunc:(NSDictionary *)options {
    NSString *log = options[@"log"];
    return  YES;
}
Copy the code

Module is in the main thread by default. You can control the thread with uniExecuteThread (DCUniModule)

The input parameter can only be passed as key-value pairs, which should be defined at the UNI side during development. Note the key string check and value type check

UniModuleKeepAliveCallback first parameter correction parameter After the completion of the second parameter bool to no method will automatically be released

Second, operation mode

understand

There are two running modes, namely HBuilderX running and Xcode running.

In HbuilderX, you rely on the base, and by installing the base, you can choose to run it on either a real machine or an emulator

In Xcode, local packaged resource files are generated through HBuilderX and run on xcode-compiled real machine emulators

What’s the difference between these two approaches? The differences between these two parts are described below.

The first is packaging.

Choosing HBuilderX to run requires us to generate a. Framework or.A plug-in package (i.e. make a native SDK package available with UNI) and place the package in the specified file of the UNI project by making a custom base and choosing a custom base to run

To run with Xcode, we don’t need to make the plug-in package. Instead, we need to generate a local package with HBuilderX, put it in the specified file of the native project, configure the UNI information and run it

The second is the configuration of associated items.

To run with HBuilderX, you need to configure package.json to ensure native resources are found at package compile time

By choosing Xcode to run, we don’t need to configure package.json, but do configure hBuild-uniplugin-inf.info to ensure native plug-ins are found in the UNI base compiled on Xcode

Check the configuration items associated with plug-ins

To get the plug-ins contained in the custom pedestal running, you need to configure the correct and complete information content. It’s easy to remember:

The package.json association corresponds to HBuilderX debugging

The hBuilder-uniplugin-info. Info item corresponds to xcode debugging

steps

1. Run debugging

HBuilderX
1.1 Configuring package.json For reference
{" name ":" Swift Log ", "id" : "SwiftObject", "version" : "1.0.0", "description" : "uni example plug-in", "_dp_type" : "nativeplugin", "_dp_nativeplugin": { "ios": { "plugins": [{ "type": "module", "name": "Swiftobject-swiftmodule ", "class": "SwiftModule"}], "embedSwift": true, // Enable Swift support for "integrateType": "Framework ", "deploymentTarget": "9.0"}}}Copy the code
1.2 Integrating the plug-in package directory format

In the nativePlugins file, create a folder with the same name as the plug-in. This folder can contain at most three contents: ios, Android, and package.json

(1) ios folder: used to store. Framework or. A plug-ins, or BundleResources folder (manage bundle resources)

(2) Android folder: used to store aar plug-ins

(3) Package. json: used to configure associated items

1.3 Selecting native Plug-ins

1.4 Start making custom pedestals

BundleID: AppID, corresponding to a profile

Profile file:. Mobileprovision description file

Certificate file: a. P12 file generated through key string export

Certificate key: specifies the key used to set the P12 file

1.5 Making a Custom Base (Succeeded)

1.6 Select base operation

1.7 Run on the real machine or emulator

1.8 Installation (Successful)

Xcode
1.1 Configuring Xcode hBuilder-uniplugin-info. Info Reference for associated items
<dict>
  <key>plugins</key>
    <array>
      <dict>
        <key>class</key>
        <string>SwiftModule</string>
        <key>name</key>
        <string>SwiftObject-SwiftModule</string>
        <key>type</key>
        <string>module</string>
      </dict>
    </array>
</dict>
Copy the code
1.2 Open project hBuilder-uniplugin.xcodeProj
1.3 Replace the dcloud_appkey field in hBuilder-uniplugin-info. Info to applyappkey
1.4 Replacing local UNI Resources

(1) Generate local packages using HBuilderX

(2) Export the local package

(3) Replace resources to make sure all three are consistent

1.5 Switch Targets to HBuilder Schemes

1.6 run

Debug differences

You can debug uni-ios projects in either of two ways, but be aware of this.

Add a custom base to run with HBuilderX, which needs to be repackaged each time the plug-in is modified

Using Xcode, you can modify the content of the plug-in arbitrarily. When modifying uni content, you only need to generate the local package file (the only thing is that when we switch functions in the plug-in, the original APP needs to be deleted to take effect).

2. Pack the IPA file

Xcode packaging: xcode-product-archive (suitable for publishing packaging)

HBuilderX custom base package generates IPA files in unpackage/debug (for debugging only)

Three, possible problems

The cloud pull plug-in could not import HBuilderX

If the cloud plug-in cannot be imported, decompress it and import it manually

1. Go to hbuilderx. app and right-click “Show package contents”

2. Import the decompressed files to the hbuilderx-plugins directory

3. Run the command in the path

../npm/npm install --save
Copy the code

4. Restart HBuilderX

You need to use iOS third-party libraries

In the process of making native plugins, we may use many third party libraries and the official UNI documentation tells us that it can be used, but it is not clear how to use the documentation

(1) Download the third-party library you need to use from Github and formulate the corresponding version

(2) Open the third-party library project, select Build Phases and import the Run script.

(3) Select Build Settings and search for the ios target version

(4) Build Code in simulator and real machine environment respectively

(5) Put the completed. Framework file into the uni-Demo SDK/Libs directory

(6) Select the plugin project that requires the third-party library, Build Settings-Framework Search Paths, and drag it into the file path

(7) Import the main project

(8) import and compile

Custom base packaging failed

**<Weex>[warn]WXBridgeContext.m:1310, jsLog: [JS Framework] The current running base does not contain the native plugin [swiftobject-SwiftModule]. Please configure the plugin in the manifest and re-create the custom running base __WARN** that includes the native plugin

  • Check whether associated items are correctly matched
  • If the associated item is correct, check the output in the log. If it contains # Symbol(s) not found for ARM64 and contains errors related to third-party libraries, it may be that the third-party libraries created in the cloud or manually are incorrectly configured

Code word is not easy, a lot of support. Wish you all better and better.