Divide the application into several applications that have a different user interface design and common logic code

Question

I have an application that I will call it the “base application”. The application works with many brands. Now I need to separate these brands and make a separate application for each brand. Each application will have a slightly different design (including different images), but here and there may be some specific code. All applications must also use the same base code from the "base application" that deals with logic.

I have some options that I thought of, but I'm not sure if any of my needs satisfy. We will be happy to clarify the difference between the options.

Possible options:

1) Create an application for each of the brands and simply copy the class files from the "base application" as a link, except for the .xib files that will be copied as a copy. The problem is that then I do not know how and where to write brand-specific code (because it will be distributed among others).

2) Creating a workspace that will include projects for each of the brands. You do not know how this works, and if it is correct, we will be happy to help you clarify the situation.

3) Set up a “basic application” project within each brand project. Any help explaining what she is doing will be appreciated.

3) Using the base application as a static library that will be linked in each brand project. Not sure what will happen to the user interface (generic, not generic). We will be happy to help you with clarification.

4) Using a simple way to maintain each of the brand’s projects, including a common code (which, I think, will be a disaster).

Answer 1

A simple solution in iOS is to use targets.

For resources, you can use different goals for each brand, and then choose different resources (images, xibs, etc.) for each goal.

Also, if the changes in the code are minimal, you can reorganize a part of the code and create different classes for each goal with different implementations (you can use some template, for example, Factory). You can also just use preprocessor macros.

This is not better, but it is the easiest and fastest approach, but if your code changes a lot, it is better to create the main library, as others say.

Answer 2

A good approach would be to split your application into the following components:

• Base model library
• Reusable views and view controllers. Views can be designed to support skinning and customization.
• Any other reusable code that can be encapsulated as its own "identity".

These core projects should ideally have their own continuous integration (quality control) assemblies and tests.

And then use CoocaPods

Instead of manually performing all this complex integration, use CocoaPods . CocoaPods will create an Xcode workspace, build libraries, and link them to your project. Then you create a custom assembly by simply gluing the pieces together.

In addition to this, CocoaPods also performs tasks such as:

• Resolving transitive dependencies is simply creating and fetching any libraries that use your libraries.
• Version control of integrated libraries.

Private spec repo is possible, or just use github

The main CocoaPods repository, of course, is open and contains open source libraries and / or freely available libraries.

You can host your own CocoaPods specification repository or just set up a private GitHub account and include PodSpec in each project, and then solve the following:

pod 'MyLibraryName', :git => 'https://github.com/myOrgName/MyLibrary.git' 

this will install all your libraries in the workspace. To update a project to include any changes to the core libraries, simply:

 pod update 

The advantages of this approach

• You will have a separate set of quality control elements that will be applied to each major project.
• There will be much less reputation.
• You can use more automation. More automation equals less waste equals more value to customers.
• As your team grows, you can separate product integration and solution integration with individual roles / teams. The team working on the integration assembly should not pull out the latest library functions if this violates them.
• You can have two different clients in different assemblies of the main library. CocoaPods will manage this without a problem. Therefore, you do not need to update the assembly until you receive a request for an upgrade or scheduled maintenance. (Again, waste reduction, which adds value to customers).

Inspired by Piggly Wiggly (but leaned over and missed)

This approach is modeled after the production line style approach, which was popularized in Japan after World War II. It is called Lean Methodology , and all this is associated with fast, small stockpile and waste reduction. (Delivering more with less.), Japanese executives got inspiration for this when they went to America and visited the Piggly Wiggly supermarket stores.

Answer 3

It is often that you are faced with creating cheap flash games or applications.

They have a very general framework, such as: kicking the ball, shooting on the screen or creating a list with some data downloaded from a specific server, etc.

Every time they want to create a new shootergame, they just upload their shooting frames, add tons of graphics and can release a shitty game during the day.

How do they do it?

They often create a structure that contains common models, handlers, interfaces, etc. Put many common features in the library, such as uploading files, etc. And you can also create some default views and controller views.

If you want to create such an application, just import the library and reuse the underlying infrastructure. Contains basic views, basic models, etc.

You can find a good example in the demos that come with the Android SDK or SDK.

Good luck.