Use multiple target to build a large number of similar apps

Transfer from Come from:http://devtang.com/blog/2013/10/17/the-tech-detail-of-ape-client-1/

Ape Question Bank technical details of the iOS client (i): Using multiple target to build a large number of similar apps

OCT 17th, 2013

Objective

I am mainly responsible for the development of the ape Question Bank iOS client this year, this article aims to summarize and communicate by sharing the technical details of the development process of the iOS client in the ape question bank.

This is the first article in this technology sharing series. The technical details covered in this article are: Multi-target compilation scheme for the development of multiple similar apps to ensure that we can quickly launch multiple clients with similar courses.

Problem description

After this year's Spring festival, we released the application of the "Ape Question Bank-examination of the civil service test", then we began to publish a series of questions on the question of apes. By now more than half a year later, we have released 8 applications (as shown).

These courses, along with the "Ape Question bank-the Civil service examination theory" and other courses are different, 7 other courses have similar, but not exactly the same function and interface.

The same points for these apps include:

1. Basically the same registration and login as well as the homepage logic and interface (just the background picture is not the same).
2. The same problem-solving logic and interface.
3. The basic same answer report displays the interface.
4. Basically the same competency assessment report interface.

Different points include:

1. Application icon, Start screen, the application starts after the first page is different.
2. Some courses (such as the Civil Service exam and the college entrance examination) are subject to the concept of an objective test, and the syllabus for different goals is not the same. Take the college entrance examination for example, Beijing's college entrance examination and Shanghai's college entrance examination, there is a completely different syllabus. The Liberal arts and Sciences of the college entrance examination have completely different subjects.
3. Some courses will have some custom interface, such as the application of the college entrance examination can set a nickname, some of the course's real topic practice is the recommended Real topic module, and some courses are not.
4. Some courses have a scan answer card function, some courses have the pre-test sprint function, some courses have a big problem special view function, and some courses do not have the above functions. There are some minor details, but the solution is similar, so don't start with a description.

Technical Solutions

Our technology solutions are mainly divided into 4 steps:

1. Build reusable large modules by extracting sub-projects.
2. With multi-target compiling, different resource files and source files are used at compile time of various courses.
3. On the basis of the 2nd step, create a configuration config class in the project, and then set different config values in each of the different target's configuration files. Realize the differentiated interface of the course.
4. Load the interface from different xib.

Extracting sub-items

The first thing we do is to extract the sub-project, from the "Ape Test Bank Judicial Examination Client", we will be able to reuse the module one by one extracted, in the form of Git submodule to organize into the project. This extraction process after the development of the ape Question Bank Judicial examination client, basically formed. The submodule we extract are mainly divided into 4 parts:

1. UI Common, involving reusable login interface, registration interface, paid interface, NPS interface, feedback interface, about interface, scan answer card interface. In addition, we have also extracted some reusable UI style controls into the corresponding static factory methods for generating uniform style buttons, backgrounds, and status bars.
2. Core Common, which involves reusable underlying modules. including the network request module, its own encapsulated core text rendering engine, cache module, some static Util method, etc.
3. Lib Common, which is dependent on all third-party open source repositories, has some code modified and customized to meet our needs.
4. Scan Common, the answer card scanning recognition algorithm module, to achieve the core scanning algorithm.

These are only coarse-grained, and these modular sub-projects may be reused later, such as Core common, which is fully reusable in any other project.

Constructs multiple compiled target

After extracting the sub-items, we use the multi-target approach to package the same name resource files in different courses into their target, and finally all the courses in one project, as shown in:

Let's briefly introduce the concept of target in Xcode, which Apple wrote in the document:

Targets that define, the products to build. A target organizes the files and instructions needed to build a product into a sequence of build actions so can be taken .”

In a project in Xcode, you can allow the creation of multiple compiled target, each of which represents a final compiled app file, where you can add different compilation source files and resource files to each target. In the end, the differences between the courses are realized by modifying and configuring them between different target Copy Bundle Resources Compile Sources . Our specific configuration scenario is as follows:

1. Each of our course's resource files have the same file name, for example, the home page background is called Homebackgroundbg.png, because each course background is different, so we in the project, each curriculum target, through the modification Copy Bundle Resources , so that it is configured with a difference (but the same name) Homebackgroundbg.png. The benefit is that, at the logic level of the code, we don't have to deal with the differences in resource files between courses at all. The variance of the resource file is ensured by the configuration file.

2. In the case of a copy of the difference, we modify Compile Sources , so that different courses have different copy definition files. By doing so, we have different kinds of copywriting for different courses. In addition, including the background network interface differences, statistical items of the difference problem, are also handled.

Config class

Finally, we use the Config class to accomplish the differences between the interaction and the UI component of the page. On the Competency Assessment Report page, there are some differences in the pages for different courses. We implement all of these logic in the code in the public layer, and the specific UI is rendered by reading the relevant config class to determine how it will be presented. In this way, we only need to complete the configuration of the Config class in the different source files for each course provided in step 2nd.

Loading the interface from different xib

There are times when we just need the UI to be arranged differently, and the other interactive logic is exactly the same. For this requirement, we try to have multiple xib for the same view and then load the different xib interfaces with the information from the Config class in the previous step. So all the differences are resolved in different xib, and the controller layer can be completely transparent.

is the Xib interface of our report page, divided into: The college entrance Examination course, has the goal examination course, does not have the target examination the course three kinds. Because the background logic and the interaction logic of the 3 interfaces are the same, we implement the difference between them by 3 xib.

The following is the code logic for the view load corresponding Xib:

123456789-ten-19 the

+(Ipadabilityreportheaderview*)Loadfromnib:(Ipadabilityreportheaderviewtype)Type{ NSString*Nibfilename; Switch(Type){ CaseIpadabilityreportheaderviewtypewithquiz: Nibfilename=@ "Ipadabilityreportheaderviewwithquiz"; Break; CaseIpadabilityreportheaderviewtypewithoutquiz: Nibfilename=@ "Ipadabilityreportheaderviewwithoutquiz"; Break; CaseIpadabilityreportheaderviewtypegaokao: Nibfilename=@ "Ipadabilityreportheaderviewingaokao"; Break; Default: Break; } Nsarray*Nibarray=[[NSBundleMainbundle] loadnibnamed:nibfilename owner: nil options:nil]; if (nibarray. Count > 0) { return [nibarray lastobject];< Span class= "line" > else { return nil; }} /span>

Summarize

With the multi-target compilation scheme, we can easily implement multiple similar apps to ensure that we can quickly launch multiple clients with similar courses. Also, because in a project, we can easily test whether the new code logic is normal under each course.

This program can be used to solve the "maintenance of a large number of logical similar but slightly different applications" needs, I hope this article can give some help to the industry counterparts.

Use multiple target to build a large number of similar apps