Convenient structure of the iOS project
There are many tutorials on the net that teach how to work with embedded frameworks and third-party libraries for iOS. But rarely you can find articles that tell about common things. Such as, for example, creating a convenient project structure.
Most likely, experienced developers have long enjoyed these techniques. But I am constantly confronted with projects that were done without following these simple rules.
In small projects and different POCs, a competent structure may not make much sense. But every small project can become big and complex. Therefore, there are often situations when a developer with the experience of only small projects begins to make large ones by the same rules.
He throws files I twist controllers in one folder, in another puts all auxiliary classes. As a result, the project grows and it is already difficult to find something in a huge tree if you don’t have maps in your head. A new developer has to remember what is where, or restructure the entire project.
')
Purpose:
If you use the same structure in all projects, you can quickly find the required class by opening the old project even after a year.
For me, the main criterion for evaluating the structure is the frequency of use of ⇧⌘O (Open Quickly) and ⌥⌘J (Filter in Navigation). Even in well-structured projects I use these combinations, but only if I need to quickly jump to the file or open a folder containing it in the tree. It's just faster than opening arrows in the project tree.
The project tree must fully comply with the actual folder structure on the disk.
First, Xcode when creating a new file will suggest the correct folder to save and place the files in the right place in the structure:
Secondly, well being guided in the project tree, you can also quickly find a file in a folder on a disk. The structure is identical.
If this rule is not followed, Xcode will offer to save the files to the application root folder and can add them to the tree before the project. You have to manually select the folder for the file, then transfer the files in the tree and delete those that were added incorrectly. Unpleasant
In general, I am a supporter of the alphabetical order of files. I even have a special shortcut for sorting strings in alphabetical order. I use for #import, for example. But there are exceptions to any rule. At the top level of the tree, the order of the folders is special. This is a combination of sorting by frequency of use and subjective logic.
Controllers, Models, and Views store controllers, models, and views. Observe MVC.
For example, we have a view controller for displaying event data. Then the heir to the UIViewController will fall into Controllers / Event. The Event object obtained, for example, from the API, we put in Models / Event. In Views / Event we can put, for example, a view that displays the avatar of the author of the event, his name and karma. An EventAuthorView object in the folder Event author:
It would seem easier to name folders in the same way as classes: for example, the EventAuthorView class and the EventAuthorView folder. Then you can press Enter on the name, ⌘C, ⌘V and not correct the folder name. But personally, I take the text without spaces hard, so at the end of the day I start to blunt over the folder names. In addition, folders are named once, and working with them is still very long. So I will spend a little time on the naming and save a lot more in the future on finding the file.
You can also name folders for classes, for example, Event view controller. But practice has shown that when I go to the Controller folder in the EventViewController search, my brain does the substring and cuts off the ViewController from all the folders in search of the cherished Event. I already know that I went to the controllers and only here they are. There can be no twist or model. Empirically, it was determined: Event easier to read.
Avoid simultaneous naming of EventViewController, EventsViewController and Event, Events folders. Typos make stupid mistakes.
In Library all auxiliary classes lie
There are three folders:
The first is Base classes, it contains base classes that are used everywhere.
These are Model, Navigation controller and View controller. Maybe something else, such as the Collection controller. From these classes are inherited absolutely all relevant entities.
Make it your rule. Always inherit View controller from base.
Even if now there is no point in this, common methods will surely appear in the future.
The same rule applies to the Navigation controller, models and all other entities.
The second folder is Helpers. Here are all the other custom entities.
Usually in all projects I have an API where there is a wrapper for AFNetworking, Base objects categories - here categories for objects from the SDK, Constants - all constants in it, Message center in which the facade for UIAlertView and Singletone - here is the implementation of the singleton.
These files are designed to be as flexible as possible so that you can adapt to the requirements of any project.
For example, the wrapper for the API provides a black box to work with the server. We create a call to api like this: [FavoriteEventsAPI apiWithObject: completion:] And in the completion block we get the parsed objects, or an error.
If you need to move from parse.com to your server, from xml to json or from one ip to another, we will do it inside the black box, and there will be no changes for the client.
The message center is used for all messages to the user. It also determines which message for which object to display. For example, the user does not need to know what's wrong with 404. He needs to say: “I'm sorry, something went wrong ...” But the error “login is busy” needs to be output, and in different languages. And, if we move from UIAlertView to something more beautiful, we will do it in one place.
Vendors is a folder for classes of third parties that are not in CocoaPods. In Storyboards are .storyboard files.
In Application like this:
Warnings.xcconfig is taken here: github.com/boredzo/Warnings-xcconfig
I have included all the versions and they are interpreted as errors. Plus a static analyzer checks the build. I turn on this:
This approach may seem redundant to many, but it helps to avoid many silly mistakes. Everyone knows about the same static analyzer, but you need to remember to include it periodically. In addition, it can show a potential bug even before the first launch. And not after long hours of debugging.
Well, my rule is: 0 Vorningov, 0 errors, 0 errors Static analyzer.
With Resources, everything is simple:
I plan to make a template for a project with such a structure, but so far my hands have not reached.
An example of a template can be found here: github.com/reidmain/Xcode-6-Project-Templates
This approach helps me manage projects of any size and not get lost in the abundance of classes.
Suggestions and comments are welcome.
Most likely, experienced developers have long enjoyed these techniques. But I am constantly confronted with projects that were done without following these simple rules.
In small projects and different POCs, a competent structure may not make much sense. But every small project can become big and complex. Therefore, there are often situations when a developer with the experience of only small projects begins to make large ones by the same rules.
He throws files I twist controllers in one folder, in another puts all auxiliary classes. As a result, the project grows and it is already difficult to find something in a huge tree if you don’t have maps in your head. A new developer has to remember what is where, or restructure the entire project.
')
Purpose:
- Organize files so that frequently used ones are at hand, and rarely used in logical categories so that they can be easily found;
- Create the same file structure in all projects.
If you use the same structure in all projects, you can quickly find the required class by opening the old project even after a year.
For me, the main criterion for evaluating the structure is the frequency of use of ⇧⌘O (Open Quickly) and ⌥⌘J (Filter in Navigation). Even in well-structured projects I use these combinations, but only if I need to quickly jump to the file or open a folder containing it in the tree. It's just faster than opening arrows in the project tree.
Main ideas
The project tree must fully comply with the actual folder structure on the disk.
First, Xcode when creating a new file will suggest the correct folder to save and place the files in the right place in the structure:
Secondly, well being guided in the project tree, you can also quickly find a file in a folder on a disk. The structure is identical.
If this rule is not followed, Xcode will offer to save the files to the application root folder and can add them to the tree before the project. You have to manually select the folder for the file, then transfer the files in the tree and delete those that were added incorrectly. Unpleasant
Go through folders
In general, I am a supporter of the alphabetical order of files. I even have a special shortcut for sorting strings in alphabetical order. I use for #import, for example. But there are exceptions to any rule. At the top level of the tree, the order of the folders is special. This is a combination of sorting by frequency of use and subjective logic.
Controllers, Models, and Views store controllers, models, and views. Observe MVC.
For example, we have a view controller for displaying event data. Then the heir to the UIViewController will fall into Controllers / Event. The Event object obtained, for example, from the API, we put in Models / Event. In Views / Event we can put, for example, a view that displays the avatar of the author of the event, his name and karma. An EventAuthorView object in the folder Event author:
It would seem easier to name folders in the same way as classes: for example, the EventAuthorView class and the EventAuthorView folder. Then you can press Enter on the name, ⌘C, ⌘V and not correct the folder name. But personally, I take the text without spaces hard, so at the end of the day I start to blunt over the folder names. In addition, folders are named once, and working with them is still very long. So I will spend a little time on the naming and save a lot more in the future on finding the file.
You can also name folders for classes, for example, Event view controller. But practice has shown that when I go to the Controller folder in the EventViewController search, my brain does the substring and cuts off the ViewController from all the folders in search of the cherished Event. I already know that I went to the controllers and only here they are. There can be no twist or model. Empirically, it was determined: Event easier to read.
Avoid simultaneous naming of EventViewController, EventsViewController and Event, Events folders. Typos make stupid mistakes.
In Library all auxiliary classes lie
There are three folders:
The first is Base classes, it contains base classes that are used everywhere.
These are Model, Navigation controller and View controller. Maybe something else, such as the Collection controller. From these classes are inherited absolutely all relevant entities.
Make it your rule. Always inherit View controller from base.
Even if now there is no point in this, common methods will surely appear in the future.
The same rule applies to the Navigation controller, models and all other entities.
The second folder is Helpers. Here are all the other custom entities.
Usually in all projects I have an API where there is a wrapper for AFNetworking, Base objects categories - here categories for objects from the SDK, Constants - all constants in it, Message center in which the facade for UIAlertView and Singletone - here is the implementation of the singleton.
These files are designed to be as flexible as possible so that you can adapt to the requirements of any project.
For example, the wrapper for the API provides a black box to work with the server. We create a call to api like this: [FavoriteEventsAPI apiWithObject: completion:] And in the completion block we get the parsed objects, or an error.
If you need to move from parse.com to your server, from xml to json or from one ip to another, we will do it inside the black box, and there will be no changes for the client.
The message center is used for all messages to the user. It also determines which message for which object to display. For example, the user does not need to know what's wrong with 404. He needs to say: “I'm sorry, something went wrong ...” But the error “login is busy” needs to be output, and in different languages. And, if we move from UIAlertView to something more beautiful, we will do it in one place.
Vendors is a folder for classes of third parties that are not in CocoaPods. In Storyboards are .storyboard files.
In Application like this:
Warnings.xcconfig is taken here: github.com/boredzo/Warnings-xcconfig
I have included all the versions and they are interpreted as errors. Plus a static analyzer checks the build. I turn on this:
This approach may seem redundant to many, but it helps to avoid many silly mistakes. Everyone knows about the same static analyzer, but you need to remember to include it periodically. In addition, it can show a potential bug even before the first launch. And not after long hours of debugging.
Well, my rule is: 0 Vorningov, 0 errors, 0 errors Static analyzer.
With Resources, everything is simple:
I plan to make a template for a project with such a structure, but so far my hands have not reached.
An example of a template can be found here: github.com/reidmain/Xcode-6-Project-Templates
This approach helps me manage projects of any size and not get lost in the abundance of classes.
Suggestions and comments are welcome.
Source: https://habr.com/ru/post/261907/
All Articles