Swift Access example – Suitable for multi-party collaboration

Swift Access Example describes how to access SOT for the Swift project. However, it requires the SDK to be decompressed to a specific directory, and the path of compilation and configuration is also an absolute path, which is not suitable for multiple collaboration. The text describes access methods suitable for multi-party development collaboration.

Or to open source “SwiftMessages” Demo as an example, the project is all developed in Swift language. You can upload the modified version to git for “SotCollaboration”, SotDebug access to the free version, and SotRelease access to the web version. Configure the build environment to test directly with this branch.

Now start from scratch, git clone originally after engineering (my path/Applications/SwiftMessages), the command linecd /Applications/SwiftMessagesGo to the root directory and use the version switch command:git checkout 1e49de7b3780b699(Since this document was produced on October 21, 21, the current version shall prevail.) Xcodeproj = demo.xcodeProj = demo.xcodeProj = demo.xcodeProj = demo.xcodeProj = demo.xcodeProj = demo.xcodeProj

I used Xcode12.4, which can directly compile successfully, and you can see the picture (simulator) after starting the APP:

Click on the top oneMESSAGE VIEWControl, will pop up an error message window, today we will use the SOT heat more way to modify the error message copywriting:

Step1: configure the compilation environment

“Download the SDK for SOT”Unzip to the project directory/Applications/SwiftMessages/Demo/sotsdk

Run in a terminal: sh/Applications/SwiftMessages/Demo/sotsdk/compile – script/install. Sh installation SOT compiler tool chain, need password.

Open it with a text editor/Applications/SwiftMessages/Demo/sotsdk/project-script/sotconfig.sh, modifyEnableSot=1:The new SDK hasDon’tThe sdkdir, sotBuilder, and objBuilder paths in sotconfig.sh are no longer used, so there is no need to modify these configurations.

Step2: increases the Configuration

Add two configurations, and use SOT compilation mode only when switching to these two configurations. Normally, the original Configuration is used for development, and the steps are as follows:

  1. Click on the Demo Project, then select the Info pane, and click the plus sign below Configurations to copy the Debug compilation configuration and name it SotDebug to access the free VERSION of SOT. Select copy Release config and name it SotRelease to configure the SOT of the website version without leaving Spaces:Add:
  2. toSwiftMessagesAlso add these two configurations:

Note: readers need to add these two configurations to all projects when applying them to their own projects, otherwise the compiler will report errors such as missing files. Therefore, after adding these two configurations, we should immediately switch to them to Build and Run to see if there is any compilation error. If the following operations are not carried out, if so, please check whether there are any missing projects not added.

Step3: modify compilation options

Add more needed compilation options, add SOT virtual machine static library, etc., as follows:

  1. Select the Demo project, then select the Demo Target, and then select Build Settings:

  2. Add -sotModule $(PRODUCT_NAME) sotsdk/libs/libsot_free.a -sotsaved to SotDebug of Other Linker Flags $(SRCROOT)/sotsaved/$(CONFIGURATION)/$(CURRENT_ARCH) -sotconfig $(SRCROOT)/sotsdk/project-script/sotconfig.sh

    Add -sotModule $(PRODUCT_NAME) sotsdk/libs/libsot_web.a -sotsaved to SotRelease $(SRCROOT)/sotsaved / $(CONFIGURATION) / $(CURRENT_ARCH) – sotconfig $(SRCROOT)/sotsdk/project – the script/sotconfig. Sh.

    The meaning of each option is as follows:

    • -sotmodule is the module name. You can use $(PRODUCT_NAME) or customize the module name without Spaces
    • -sotsaved Is the directory for saving the compiled intermediate products. The automatic generation of patches requires comparison of the compiled products before and after the automatic generation of patches
    • -sotconfig Specifies the path of the project sotconfig.sh. This script controls the work of the SOT compiler
    • sotsdk/libs/libsot_free.aIs the path to the SOT static library, which is linked to the free VERSION of the VM
    • sotsdk/libs/libsot_web.aIs the path of the SOT vm static library, which is linked to the virtual machine of the website version

  3. inOther C FlagsAs well asOther Swift FlagsAdd under SotDebug and SotRelease-sotmodule $(PRODUCT_NAME) -sotconfig $(SRCROOT)/sotsdk/project-script/sotconfig.sh, meaning is the same as the previous step, need to keep consistent. After the above two steps, the relevant compilation and configuration results are shown as follows:

  4. inPreprocessor MacrosaddUSE_SOT=1, which controls whether to compile the code that calls the SDK

  5. Since the SOT SDK library file is compiled without Bitcode, it also needs to be addedEnable BitcodeSet toNo.

  6. In order not to compile ARM64 for emulator architecture, add the following configuration to SotReleaseOr theBuild Active Architecture OnlySet toYes

Step4: add patch copy scripts

The SDK provides a convenience script in the project-script/sot_package.sh directory of the SDK, which copies the generated patches to the Bundle folder and calls the script every time the project is successfully compiled. Add the following steps:

The script content is as follows:

if [[ "$CONFIGURATION" == "SotDebug" || "$CONFIGURATION" == "SotRelease" ]]; then sh "$SOURCE_ROOT/sotsdk/project-script/sot_package.sh" "$SOURCE_ROOT/sotsdk/project-script/sotconfig.sh" "$SOURCE_ROOT/sotsaved/$CONFIGURATION" Demo fiCopy the code

Uncheck the check box Based on Dependency Analysis.

Step5: link C++ library

SOT requires the support of the c++ standard library and the Link Binary With Libraries page

Hit the plus sign, add these two,libz.tbdandlibc++.tbd

Step6: call the SDK API

The OC code needs to be called from Swift code. A sample code is provided in the SWIFt-call-objc directory of SDK. First copy callsot.h and callsot.m to Demo directory

Add it to the Demo project. Click the File button of Xcode software, find callsot.h and callsot.m in the Demo directory, then click Add Files to “Demo”, as shown below:

Click the Add button and a question will pop up asking if you want to create a bridge file. Click on the buttonCreate Bridging Header:

H, callsot.m, and demo-bridge-header. h:

Open demo-bridge-header. h and add a line of code#import "callsot.h"

Open callsot.m and change the code to

#import <Foundation/Foundation.h> #import "callsot.h" #import ".. /sotsdk/libs/SotWebService.h" @implementation CallSot:NSObject -(void) InitSot { #ifdef USE_SOT #ifdef DEBUG [SotWebService ApplyBundleShip]; #else [SotWebService Sync:@"1234567" is_dev:false cb:^(SotDownloadScriptStatus status) { if(status == SotScriptStatusSuccess) { NSLog(@"SotScriptStatusSuccess"); } else { NSLog(@"SotScriptStatusFailure"); } }]; #endif #endif } @endCopy the code

Note that the sotWebService. h header path no longer depends on the absolute path and is used in the code#ifdef USE_SOTMacro to separate API calling code without affecting normal compilation:

Open Appdelegate.Swift and add two lines of codelet sot = CallSot()andsot.initSot()

Note: Readers should not follow these configuration paths mechanically when applying them to their own projects. For example, the sotWebService. h file or sotconfig.sh file cannot be found. Readers should know the relative relationship between the SDK directory and their own project directory and flexibly adjust the configuration path.

Beta Heat – Free version

After the above configuration, first test the free version hot switch function

Step1: heat injection

  1. willBuild ConfigurationSwitch to theSotDebug
  2. Make sure thatsotconfig.shThe configuration of,EnableSot=1As well asGenerateSotShip=0Clean Build Folder first and then Build:

Run sot Link, etc., will tell you which functions in each file can be hot changed, etc. :

The project is compiled successfully, and the APP can be started normally. It also has the capability to load patches to change the code logic of the program. Here is how to generate patches to test it.

Step2: generate patches

The previous step was to compile the heat injection code, which was saved to the Demo/ sotSaved folder to compare with the new code to generate a patch. The procedure for generating a patch is as follows:

  1. Start the SOT patch generation mode and change sotconfig.sh to EnableSot=1 and GenerateSotShip=1
  3. Next, I’m going to modify the source code directly in XcodeViewController.swiftThe document’s “Something is horribly wrong! “Changed to” SOT is great “, before modification:Revised:
  4. Swift project generates patches,Every time you need to Clean the project, then Build the project. Link Demo (x86_64) builds a patch and copies it to the Bundle directory.In the Link log, demoBasics has been modified:
  5. Generated patches of the original file to the Demo/sotsaved/SotDebug/x86_64 / ship/ship. The sot, remember before you add a script to Build Phase in? It copies the patch to the Bundle directory at the end of each build and adds the CPU architecture to the file name. You can see the patch in the Bundle, and that’s it.

Step3: load the patch

When the APP is started, the API will determine whether there is a patch in the Bundle, and if there is, the Bundle will be loaded. The successfully loaded log is similar to the following, indicating that a module has loaded a hot update patch:Then click on the top oneMESSAGE VIEWControl, find that the popup copy becomes SOT is great:

If you go to the Xcode breakpoint to debug demoBasics, you will find that it cannot be broken because it is the SOT virtual machine that actually performs the patch code.

By the way, when GenerateSotShip=1, you’re compiling your APP using code that’s stored in the SOtSaved directory, so no matter how much you change the code in Xcode, if you don’t copy the patch into the Bundle directory, So your APP is going to look like the last time you did the hot injection with GenerateSotShip=0.

If in doubt, remove the Script that copied the patch from Build Phases. GenerateSotShip=1 will not work.

Note: if the reader access their own very simple project for testing, such as setting a control color, hot before is red, after modification is green, found that does not work. That’s because such projects are too simple, with only a few lines of code. The global variable green has not been accessed before the heat change, nor can it be accessed during the heat change. SOT can only use the original ability, not out of nothing. So don’t test this way, and the more specific reason is explained in the “Hotabilities – Language features” section. There is usually more complete project code, so there is no such defect.

Access web site edition

According to the above tutorial, the free version and the website version of the APP have been achieved access. Other Linker Flags is configured according to the Configuration difference. SotRelease connects to the website version. However, in addition to the APP accessing the website version SDK, it also needs to manage the patch release with the website.

Step1: register a website

  1. The first step, of course, is to register and become a member. Click to jump to the registration page, free registration, registration requires email verification, and then login.
  2. Enter my APP from the navigation bar:
  3. Click Create APP and fill in the name of APP in the popup window:
  4. Enter the APP page, click the “Create new Version” button in the upper right corner, and a popup window will pop up. You need to select the website version, and select the SDK version 1.0, which is only available at present. Then enter the version number, which can be a random string for easy differentiation.
  5. After the version is created successfully, click the version to enter the version page, and the upper left corner is the unique identification of the versionVersionKeyThis Key is required by the later API interface.

Step2: VersionKey changes

Open callsot.m and modify the Sync interface for the site version. Enter the VersionKey of the version you created on the site as the first parameter.At this point, the website version of hot access even completed.

Step3: test website heat more

  • The website version of the patch generation steps are the same as the free version, need to go through the heat injection -> package -> modify code -> generation of patches, not described here.

    The only difference is that the generated patches are uploaded to a website and then synced over the network to the phone for heating. From the free tutorial, you know that the generated patch will be copied to the Bundle directory, so go to the Bundle directory and find it. Right-click demo. app under Products in the Xcode navigation bar and select Show in Finder:

  • Right-click the Demo file and select Show Package Contents:

  • Find the directory sotship_arm64 sot, cell phone test here, the CPU is arm64 type, the patch name suffix with CPU, this is where a patch:

  • Go back to the version page of the website and click the upload patch button on the right:

  • In the popup screen, select arm64 as the architecture of the real machine, unless it is an old ARMV7 machine, drag the patch file into the box and click Upload:

  • If the upload is successful and the patch file is normal (the patch supports a maximum of 5MB), the patch will be added successfully. The patch is disabled by default, and you need to click Edit to enable it:

  • Select Full Enable here, click the submit button below, and the patch will be successfully enabled:

  • The patch status was updated in the previous step and usually takes effect quickly, but CDN can sometimes take 1 to 2 minutes to take effect. If the patch is downloaded and loaded successfully, you can see the following log:The md5 output here is the same as the patch MD5 on the website.

  • Once you open the APP, click on the topMESSAGE VIEWControl, find that the popup copy becomes SOT is great:

Note: With the web version, you need to take into account the network transfer latency, and the function will only use the hotfix function after seeing the log of the patch download and successful patch loading. For example, some developers ask me, why doesn’t the first screen code work better? That’s because the first screen code is called too early, SOT goes to the site to get a patch, is asynchronous, doesn’t get stuck, and waits for results in an asynchronous thread. The code on the first screen has already been called before the patch is sent back, in which case the old code is still called. The free version doesn’t have this problem, because the free version loads patches synchronously, directly into the Bundle, not asynchronously.

Build hot update injection versions and build patches must be on the same machine, with the same Xcode version. For example, if the APP uses Xcode12 for heat injection before launching, and Xcode13 is used to build patches later, invalid or even wrong patches will be obtained. Use the same version of Xcode.

Step4: a few hints

  • The website version and the free version of the main access process is similar, you can use the free version of the test, after the function through the test and then access the website version.
  • The website version can only take effect if the phone has an Internet connection. If the phone does not have an Internet connection, even if the patch has been downloaded before, it cannot be loaded.
  • Website version cost is very low, daily live 100,000 APP, a few hundred yuan a month is enough.
  • The patch and configuration of the web edition are placed on the CDN, supporting high concurrency.

Non-primary Target access hot timer

The above tutorials are for the main Target, the Demo. The project also has a Framework called SwiftMessages, which can also be configured.

You can see that the Mach-o Type for SwiftMessages isDynamic Library, can be viewed as follows:

With this type, the configuration is more cumbersome. There is also Static Library, which is much simpler to configure. In this example, the Static Library will crash when started.

Step1: modify compilation options

  1. Selected SwiftMessages xcodeproject project, and then select SwiftMessages the Target, then select Build Settings:
  2. inOther Linker FlagstheSotDebugadd-sotmodule $(PRODUCT_NAME) $(SRCROOT)/Demo/sotsdk/libs/libsot_free.a -sotsaved $(SRCROOT)/Demo/sotsaved/$(CONFIGURATION)/$(CURRENT_ARCH) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.sh
  3. inOther Linker FlagstheSotReleaseadd-sotmodule $(PRODUCT_NAME) $(SRCROOT)/Demo/sotsdk/libs/libsot_web.a -sotsaved $(SRCROOT)/Demo/sotsaved/$(CONFIGURATION)/$(CURRENT_ARCH) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.sh
  4. inOther C FlagsAs well asOther Swift FlagstheSotDebugandSotRelease, add-sotmodule $(PRODUCT_NAME) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.sh, meaning is the same as the previous step, need to keep consistent. After the above two steps, the relevant compilation and configuration results are shown as follows:This step is similar to the Demo configuration,The difference is that some paths are written differentlyIn order to reuse the Demo configuration, the reader can carefully compare.
  5. inPreprocessor MacrosaddUSE_SOT=1, which controls whether to compile the code that calls the SDK
  6. You need to set Target’s Enable Bitcode toNo.
  7. In order not to compile ARM64 for emulator architecture, add the following configuration to SotRelease

Step2: link the C++ library

Click on the Build Phases page, open the Link Binary With Libraries page, click on the plus sign to add the two Phases.libz.tbdandlibc++.tbd

Step3: call the SDK API

Because SwiftMessages is a dynamic library, you need to invoke the SDK’s hotfix initialization interface in its compile file. Just like Demo, add OC file. Copy the callsot.h and callsot.m files from the Demo folder to the SwiftMessages folder

Selected SwiftMessages project, click the File button Xcode software, and then click Add Files to “SwiftMessages. Xcodeproject”, as shown in the figure below:

Select SwiftMessages directory, select callsot.h and callsot.m at the same time, check Copy items if needed below, check SwiftMessages target in Add to Targets:, as shown below:

Callsot. H, callsot.m, CallSotMessage:

Go to the right panel and change the file property to public:

Open callsot.m and modify the path and class name accordingly:

Open demo-bridge-header. h and add a line of code#import "SwiftMessages/callsot.h":

Open Appdelegate.Swift and add two lines of codelet sot1 = CallSotMessage()andsot1.initSot()

Because there are two targets that can generate patches, Demo and SwiftMessages, you need to modify the script to copy the patch and add SwiftMessages:

Step4: Test heat

  1. The process of testing heat change is the same as before, but the output log may be different, we go over it. EnableSot=1 and GenerateSotShip=0 for hot change injection, Clean before Build. If you look at Link SwiftMessages for Build logs, you can also see hot change injection information.

  2. Then modify messageView. swift to add “SOT is great” to the error message:

  3. GenerateSotShip=1 Start the patch generation mode, Clean the Build, check the Link SwiftMessages log, there is a message that this function is hot:

  4. The patch copy script logs show that two targets have generated patch files and will copy them to the Bundle directory:

  5. The Demo Target and SwiftMessages Target call the API interface:

  6. Click the MESSAGE VIEW control, you can see the error MESSAGE text after the “SOT is great”, hot more successful:

    The website version of the test is the same as before, not repeated here.

Step5: a few hints

  1. The Dynamic Library’s hotchange change is the same as the main Target, the Mach -o Type Executable change, except that some of the main Target’s configuration is reused, such as the sotsaved directory and the path to sotconfig.sh. Adding more targets can change them in the same way.
  2. The patch copy script only needs to be available from the main Target. Add the name of the sotModule to the patch copy script, as long as the sotSaved directory is the same.
  3. If you need to access the web version, each Target that needs to be updated will need to call the API to synchronize with the web site, and their consumption will be billed independently.

Static Library

If the Framework’s Mach-O Type is Static, it is best to change it to a Static Library. Since this example cannot be modified, here are the steps:

  1. inOther Libraian Flagsadd-sotmodule $(PRODUCT_NAME) -sotsaved $(SRCROOT)/Demo/sotsaved/$(CONFIGURATION)/$(CURRENT_ARCH) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.sh, pay attention to isOther Libraian FlagsRather thanOther Linker Flags. There is also one less configuration than the Dynamic Library, that is, there is no.A Library file linked to the SDK.
  2. inOther C FlagsAs well asOther Swift Flagsadd-sotmodule $(PRODUCT_NAME) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.shThis step is exactly the same as before.
  3. You need to set Target’s Enable Bitcode to No.
  4. Modify the script to copy the patch and add the name of the Target, such as SwiftMessages in this example, as before:

Then the configuration is complete. If you are using the website version, you can synchronize the consumption once, and achieve all the Target heat, easy to modify, minimal impact on the package body.

conclusion

This article describes how to access the free version and the website version of the Swift project.

The method in this paper is to copy the SDK to the project folder, so that it can follow the project for version management, and the path is configured as a relative path, which is more flexible.

By adding Configuration, the original development is not affected. Debug and Release are equivalent to not having ACCESS to SOT, which is suitable for most development. Just change the package to SotRelease before going online, so that the APP can get more heat capacity.