Issues in 1.0 iOS modularity

Having already introduced modularity processes and some of the common problems, we summarize them here.

At work, when we start a new project, the first thing we think about is modularity.

Modular work is a great idea, but there are a lot of problems with implementation that can make our work difficult.

  1. Tool usage problems. For iOS modularity, we use cocoapods, a powerful and rich tool that allows us to build private libraries, write Podspec files, work with resources, write Podfiles, create local dependencies, and more. It is not necessary for everyone on the team to master the tool. As a result, a lot of time is often wasted when you run into problems that are not easy to solve using the tool.

  2. Xcode setup problem. Xcode has a lot of Settings, many of which are not intuitive and require us to consult the official documentation. Moreover, the number of these Settings is large and the frequency of use is small, so it is inevitable that there will be such a situation: everyone has encountered problems, and then spend their time to solve them, and then after a period of time, they often forget the same problems, but also spend time to look up and solve them, resulting in repeated waste of resources.

  3. Inter-module dependencies. When you rely on other modules that are also private libraries (hereafter referred to as “own modules”), it is possible to change multiple modules at the same time during development, which can cause the problem of switching between multiple projects.

  4. Specification issues, everyone may build modules in a different way, including engineering structures, engineering Settings and so on. As a result, different modules can be very different, and when developing across modules or transferring code, problems can arise that are difficult to resolve.

  5. Settings are manually modified, sometimes due to negligence, which leads to errors that are hard to find. When there are too many modules and dependencies to deal with, the probability of errors will increase.

2.0 Write automation tools

To address these issues and allow the team to focus exclusively on business development, the special envoy developed a build tool with bash shell to automate the setup and tool usage issues encountered during modularization.

The tool address is as follows: github.com/hardman/AWM…

Using this automated tool you will gain the following abilities:

  1. A single command to create a module project, create. Podspec and Podfile files, automatically install dependencies, project default use static library, support Swift and OC
  2. A single command pulls the previously developed module and installs all dependencies
  3. A single command automatically tags, automatically updates the. Podspec file, and pushes the project to the POD server
  4. The list of your own modules will be stored in a separate Git library so that they can be loaded dynamically when there are dependencies
  5. Podspec files are installed using the local path, so you don’t have to open multiple projects when the dependent module also needs to be modified

So with this automation tool, you don’t need to know cocoapods tools or deal with any engineering or tool setup and can focus on business development.

The tool uses a static library as the output file of the module.

3.0 Tool usage

3.1 Basic Steps

  1. Clone the project to a local directory
  2. Open thetools/configModifying a Configuration File
    • Modulelistgitaddress.txt: Create a new Git library and store the address in this filegit@At the beginning. This Git repository is used to store all of its own module names and addresses.
    • Podspecsaddr.txt: Create a new Git library and store the address in this filegit@At the beginning. This Git repository is your private repository address.
    • Podspecsname.txt: Give your Git library a name and save it in this file
    • The above three files are all one line long
    • Dependencypodrepos. TXT: This file saves the rest of your app’s dependenciespod reposGenerally, keep the default value. Multiple lines are supported, and each line saves one address
    • Since these configurations rarely change, consider committing these files to your own Git repository
  3. perform. / create. Sh - n = [module name] - t = b = [bundle id] - [s] | | f rCreate project
    • Note During script execution, you are required to enter basic project information and dependent modules
    • The created project opens automatically and can be executed directly
    • The created module file is in:Project root directory /modules.
    • Ex. :./create.sh -n=HelloWorld -b=com.helloworld -t=s
  4. Once the module is developed, you need to commit the code to the Develop branch and execute it./push.sh [module name] [tag]
    • When push.sh is executed, the module must be on the Develop branch
    • Once executed successfully, your module has been committed and can be referenced in your Podfile
    • Ex. :. / push. Sh HelloWorld 0.0.1
  5. use./pull.sh [module name]You can download other own modules that are not synchronized locally
    • After the command is executed successfully, all dependent modules are automatically downloaded and added to module dependencies using the local path
    • Ex. :./pull.sh HelloWorld

3.2 How can I upgrade the version numbers of other modules on which a module depends

Sometimes, the version of the module on which the current module depends is upgraded, and the dependency file of the current module needs to be modified. There are two methods:

  1. Modify files directly
    • Two files need to be modified. One is in the root directory of the filedependency.txtFile that records the dependencies of the current moduleHas its own module.
    • dependency.txtThe format of the file record module version is: one module per line; Format for:Module name @@ Version number, version number support~ >The prefix cannot contain Spaces
    • The other file isThe module name. Podspecfile
    • In accordance with thepodspecFile required format to modify version number
  2. Script Modification
    • Execute command:./utils.sh [module name] upgradeDependency [Module name] [version number]
    • The version number can be empty
    • Example:./utils.sh LoginModule upgradedependency AFNetworking 3.5.0
    • Example:./utils.sh LoginModule upgradedependency AFNetworking
  3. The version number can be A.B.C

3.3 How to use Swift&OC in module engineering

  1. OC and SWIFT files are created in the Module project. TestSwift and OC are testc
  2. Enable the OC to access the Swift class
    • Testtest. m Is displayed. Add import to testtest. m. Ex. :#import "module name/module name -swift.h".
    • Also note that the TestSwift class must be public and inherit from NSObject.
  3. Enable Swift to access the OC class
    • Import your header file in the [module name].h file. Ex. :#import "TestOC.h".
    • inXcode -build Phases -.hThe file must be in the public area

3.4 Obtaining module resource files

  1. Since modules are static libraries, the resource files of each module will be provided after they are finally run in app(.xcassets,.xib,.png,.jpg,.jpeg,.gif,.txt,.plist,.bundle,.zip,.car)Are put into:"Module name.bundle"File, and this bundle is inmain bundle(This is one of the reasons why module names are required to prevent duplication)
  2. So get pictures can be usedUIImage.init(named: name, in: bundle, compatibleWith: nil)methods
  3. You also need to specify the bundle to obtain other files
  4. During development, a bundle is required to obtain any resources, and cannot be used directlyUIImage.init(named:String)This approach does not work even for code inside a module project
  5. It is important to note that static library unit test targets do not get resources

3.5 Precautions

  1. Module names are to be prevented from duplicating, not only with the same private library, but also with other modules in the POD REPO
  2. Dependency libraries cannot generate cyclic dependencies, such as A dependent on B, B dependent on C, and C dependent on A
  3. Each module has a Develop branch, and the develop branch’s code always keeps up with the latest tag. When you execute push, the code is always on the Develop branch
  4. Local modules are always relied on during development (before integration testing), and the push.sh script is always executed before integration testing
  5. If the current development module is modified and the dependent module is also modified, you need to push the module that the current module depends on first and then push the current module. This may be necessary./utils.sh [module name] upgradeDependency [Module name] [version number]Command to change the version number of the module on which the module depends

– the –

  1. IOS application modularization thinking and landing scheme (A) module division and modular workflow
  2. IOS application modularization thinking and landing scheme (2) the use of modular automatic construction tools