Ninjutsu Xcode
If you spend a lot of time in the same environment - sooner or later there is a desire to start somehow save your time and optimize your actions. This article will discuss some of the working tools and approaches that I have accumulated during the time of programming under iOS in IDE Xcode from the obvious and often applicable to the rare and rather heavy.
Perhaps I'll start with my favorite XCode shortcut. Its capabilities are wide enough so that it can be considered quite an independent feature. After pressing it, a window will open in front of you:
In my opinion, this is the fastest way to navigate an application, because
About it already wrote on Habré here , for example, but if we are to put it together, then this can not be circumvented.
Snippets are pieces of reusable code that can be inserted into a project just by typing the key of this piece.
Basically, there is enough written there, so I would like to add only two points: a link to a nice selection of snippets and a response from stackOverflow, which answers us - how to transfer our library of snippets from one computer to another.
')
Plugin Manager for ikskod. Embedded in ikskod itself, available in the menu Window-> Package manager
There is a whole plug-in of plug-ins - from color themes to fairly significant projects offering live coding, almost like on a swift (although you can install them at your own risk, most of them are not well supported, and therefore bear certain risks).
Very convenient installation and shutdown in 1 click. Each plugin has a link to its website or github, for many of the same manager pictures or gif-previews are available.
Using the manager, I use a number of tools, in particular:
From the title it is clear that this tool offers to quickly clean the folder with the data remaining from previous compilations - sometimes it takes a lot of space, especially if you work with several projects at the same time.
Autocomplete significantly expands - it starts to work approximately as a combination of Cmd + Shift + O - that is, it is no longer necessary to remember the first letters of each method or class.
People perceive it quite differently - now, infrequently, autocomplete is reduced to one option and one gets the impression of a large pile of information garbage, but without it I feel much worse now.
A few small but nice devices for autocomplex, such as
-QuickLocalization (translates @ "content" to NSLocalizedString (@ "content", @ "content"))
-OMColorSense (in autocomplete it shows color when you fill in the UIColor initialization fields)
-XToDo (gives a window in which you can view in TODO, FIXME and other tags for the entire project)
-KSImageNamed (in autokomplite it adds files of graphic assets and displays them - making imageNamed: much more convenient to use)
This concludes with Alcatraz - everyone has the opportunity to choose from the list something to their liking.
In general, IB is such a thing that it is better not to overdo it — for large projects, IB files start to slow down even on strong machines, and working with version control systems, again, is not very pleasant. However, this does not mean that this tool should be discarded, it is able to offer some rather pleasant things.
This tool for KVC, available in IB, allows you to set the value of some properties when instantiating an object at the stage of calling the InitWithCoder method. In fact, its action is similar to calling the method [self setValue: @ “value” forKey: @ “key”] during object initialization. Thus, this allows you to put into the IB file a fairly wide range of application settings that can be handled, including by a non-programmer.
IB allows you to control the creation of not only the objects that inherit from UIKit elements, but also any arbitrary objects. (Using the previous item, you can control some properties of created objects) They, like the heirs of UIKit, will call the initWithCoder constructor: and they will also be destroyed when the controller leaves the visibility zone and the Navigation Controllera steak, unless otherwise provided by the developer.
I, for example, use this tool in order to quickly change the property of many UI elements when UIAppearance and inheritance for one reason or another are not suitable. For example, when the customer wanted to add a gradient to each button in the project, and for some more shadows, this was decided by creating two decoration classes and hanging them in IB.
Details can be read here .
In fact, it is a convenient wrapper over User defined runtime attributes - allowing you to make some properties of classes accessible for modification by IB. This, of course, still does not give the opportunity to write full-fledged custom UI-components, but it brings them closer to this.
Each project must have a .pch file (usually in the Supporting Files folder), which is a header file that is connected to each header.
That is actually a good place to connect commonly used on the project macros and headers (such as CoreData headers or, for example, Cocos2d for game projects)
In general, Xcode is not just an Objective-C environment. And not even for Swift. This is a large and adult IDE that can be developed in other languages.
It was a pleasant revelation to me that XCode has YACC and LEX language support out of the box. It’s enough to add .y and .l (or .ym, .lm or .ymm, .lmm to the project depending on the features you want to be able to compile - the first two, for example, will not be able to compile with Objective-C code, but in last you can use C ++ - stl)
They have their own settings section in the project file.
Pay attention - because these languages ​​are supported out of the box, the lines for compilation are also generated from the box, which at some point was an unpleasant surprise - for example, XCode long ignored my attempt to separate the two YACC files generated by different namespaces, because the corresponding The directive was interrupted automatically by the Xcode (the option Generated file stem, if you are interested)
Do not forget that for some tasks, Objective-C is not the most suitable language. But I still didn’t want to part with XCode, so here you can find a description of how to tie to XCode, for example, Perl.
If someone is looking for inspiration about the application: on the pearl, you can organize a script that, using the example of JSON request and response, generates the .h and .m code of the hierarchy of data objects under which this data fits.
For many languages, Xcode has a built-in backlight.
One of the amazing features of macOS as a system is a pleasant and fairly comfortable environment for automating everything your heart desires.
Get the first glimpse of this here.
Practical applications tutorial - highly recommended.
If this topic is really fascinating - there is a remarkable suggestion that you can create your own subroutines for the automator.
I recently started using it, but I see quite a few interesting applications: From the simplest multi-line comments, to the search for a dedicated line of code in the commit commits — and what the imagination is for.
By the way, in the System Settings (Keyboard program) you can assign shortcuts to the created services and make life even easier.
This tool allows you to bring the project in the file system to the form in which it is present in the project. Runs through the command line. Reliable - operations in which he is not sure - he simply does not do what he warns in advance.
And in the morning a couple more things came to my mind that I forgot. Although they are also almost obvious, but nevertheless it answers one of the most frequent questions in ObjC groups:
Everybody has to debug the application. And sometimes for a long time. And I began to use these things not immediately. And in vain!
One of the key tips is to always keep this or that Exception Breakpoint enabled. Exception breakpoint is triggered when an exception is triggered. In case this exception is unprocessed with the breakpoint turned off, the stack that led to the error will not be shown. Surely everyone somehow faced the problem of finding errors like [array addObject: nil] or out of range. So, such breakpoints are a way to catch such problems exactly at the place of their origin.
The second thing about breakpoints that I would like to point out is the ability to set conditional breakpoints.
If you have a piece of code that is highly used in a project (for example, CCNode in cocos2d), then without any conditions it is very difficult to catch a specific problem. They support the usual objective-C syntax, that is, there you can verify that the object being passed is of a particular class, that it has a specific value of some property, and so on. Very comfortably!
Well, yes, the work of conditional breakpoints slows down the application very much - so it’s better not to overdo it.
And I would like to add about the search for memory leaks in the code. As a rule, Instruments with the Leaks preset are used for this, but the main problem of this tool is that there are leaks that are not considered as leaks for this tool and I had to deal with the code where several megabytes flow away for the user’s case and Leaks doesn’t show nothing - it is connected exactly with what is actually considered a leak. So lately, I’m using the Allocations tool to look for significant memory problems.
Important. This tool is separate, but it’s better to run it in a preset with Leaks - because being launched separately it is not always correctly able to paint the Retain / Release history for a specific object - I don’t know if it’s a bug or a feature.
So here. Pressing the mark generation button essentially marks each non-tagged object created by this point (in a broad sense, the memory allocated for the structure is also marked). Further, as the application lives, only those objects remain in the generation that have not been released to date.
Having deployed a specific generation, it is easy enough to find the classes used in your project, and also to see why they are still alive (for each object you can see the history - where and when it received the message retain and where release).
I recommend reading here about the specific aspects of using this tool.
Thank you for reading!
and I will be very grateful for some of your tricks and practices.
1.Command + Shift + O
Perhaps I'll start with my favorite XCode shortcut. Its capabilities are wide enough so that it can be considered quite an independent feature. After pressing it, a window will open in front of you:
In my opinion, this is the fastest way to navigate an application, because
- As can be seen from the screenshot - does not require that you remember the exact name. It is enough for him if you enter several letters from the name in the order in which they appear. For example, a word from the middle. Or the first two letters of the naming elements
- In addition to navigating through files, it also provides navigation through classes, methods, class properties, and structures.
2. Snipes
About it already wrote on Habré here , for example, but if we are to put it together, then this can not be circumvented.
Snippets are pieces of reusable code that can be inserted into a project just by typing the key of this piece.
Basically, there is enough written there, so I would like to add only two points: a link to a nice selection of snippets and a response from stackOverflow, which answers us - how to transfer our library of snippets from one computer to another.
')
Alcatraz
3. Project Alcatraz
Plugin Manager for ikskod. Embedded in ikskod itself, available in the menu Window-> Package manager
There is a whole plug-in of plug-ins - from color themes to fairly significant projects offering live coding, almost like on a swift (although you can install them at your own risk, most of them are not well supported, and therefore bear certain risks).
Very convenient installation and shutdown in 1 click. Each plugin has a link to its website or github, for many of the same manager pictures or gif-previews are available.
Using the manager, I use a number of tools, in particular:
4.Derived data Exterminator
From the title it is clear that this tool offers to quickly clean the folder with the data remaining from previous compilations - sometimes it takes a lot of space, especially if you work with several projects at the same time.
5.FuzzyAutocomplete
Autocomplete significantly expands - it starts to work approximately as a combination of Cmd + Shift + O - that is, it is no longer necessary to remember the first letters of each method or class.
People perceive it quite differently - now, infrequently, autocomplete is reduced to one option and one gets the impression of a large pile of information garbage, but without it I feel much worse now.
6. Useful small things
A few small but nice devices for autocomplex, such as
-QuickLocalization (translates @ "content" to NSLocalizedString (@ "content", @ "content"))
-OMColorSense (in autocomplete it shows color when you fill in the UIColor initialization fields)
-XToDo (gives a window in which you can view in TODO, FIXME and other tags for the entire project)
-KSImageNamed (in autokomplite it adds files of graphic assets and displays them - making imageNamed: much more convenient to use)
This concludes with Alcatraz - everyone has the opportunity to choose from the list something to their liking.
Interface builder
In general, IB is such a thing that it is better not to overdo it — for large projects, IB files start to slow down even on strong machines, and working with version control systems, again, is not very pleasant. However, this does not mean that this tool should be discarded, it is able to offer some rather pleasant things.
7.User defined runtime attributes
This tool for KVC, available in IB, allows you to set the value of some properties when instantiating an object at the stage of calling the InitWithCoder method. In fact, its action is similar to calling the method [self setValue: @ “value” forKey: @ “key”] during object initialization. Thus, this allows you to put into the IB file a fairly wide range of application settings that can be handled, including by a non-programmer.
8. Instantiation of objects
IB allows you to control the creation of not only the objects that inherit from UIKit elements, but also any arbitrary objects. (Using the previous item, you can control some properties of created objects) They, like the heirs of UIKit, will call the initWithCoder constructor: and they will also be destroyed when the controller leaves the visibility zone and the Navigation Controllera steak, unless otherwise provided by the developer.
I, for example, use this tool in order to quickly change the property of many UI elements when UIAppearance and inheritance for one reason or another are not suitable. For example, when the customer wanted to add a gradient to each button in the project, and for some more shadows, this was decided by creating two decoration classes and hanging them in IB.
9.IBDesignable (Xcode 6)
Details can be read here .
In fact, it is a convenient wrapper over User defined runtime attributes - allowing you to make some properties of classes accessible for modification by IB. This, of course, still does not give the opportunity to write full-fledged custom UI-components, but it brings them closer to this.
Project structure
10. .pch file (Xcode 5-, manually added to Xcode 6)
Each project must have a .pch file (usually in the Supporting Files folder), which is a header file that is connected to each header.
That is actually a good place to connect commonly used on the project macros and headers (such as CoreData headers or, for example, Cocos2d for game projects)
Multilingual
In general, Xcode is not just an Objective-C environment. And not even for Swift. This is a large and adult IDE that can be developed in other languages.
11.1. Integrated languages
It was a pleasant revelation to me that XCode has YACC and LEX language support out of the box. It’s enough to add .y and .l (or .ym, .lm or .ymm, .lmm to the project depending on the features you want to be able to compile - the first two, for example, will not be able to compile with Objective-C code, but in last you can use C ++ - stl)
They have their own settings section in the project file.
Pay attention - because these languages ​​are supported out of the box, the lines for compilation are also generated from the box, which at some point was an unpleasant surprise - for example, XCode long ignored my attempt to separate the two YACC files generated by different namespaces, because the corresponding The directive was interrupted automatically by the Xcode (the option Generated file stem, if you are interested)
11.2.Integrated languages
Do not forget that for some tasks, Objective-C is not the most suitable language. But I still didn’t want to part with XCode, so here you can find a description of how to tie to XCode, for example, Perl.
If someone is looking for inspiration about the application: on the pearl, you can organize a script that, using the example of JSON request and response, generates the .h and .m code of the hierarchy of data objects under which this data fits.
For many languages, Xcode has a built-in backlight.
External tools
12. Automator
One of the amazing features of macOS as a system is a pleasant and fairly comfortable environment for automating everything your heart desires.
Get the first glimpse of this here.
Practical applications tutorial - highly recommended.
If this topic is really fascinating - there is a remarkable suggestion that you can create your own subroutines for the automator.
I recently started using it, but I see quite a few interesting applications: From the simplest multi-line comments, to the search for a dedicated line of code in the commit commits — and what the imagination is for.
By the way, in the System Settings (Keyboard program) you can assign shortcuts to the created services and make life even easier.
13. Synx
This tool allows you to bring the project in the file system to the form in which it is present in the project. Runs through the command line. Reliable - operations in which he is not sure - he simply does not do what he warns in advance.
And in the morning a couple more things came to my mind that I forgot. Although they are also almost obvious, but nevertheless it answers one of the most frequent questions in ObjC groups:
Debugging
14. Breakpoints.
Everybody has to debug the application. And sometimes for a long time. And I began to use these things not immediately. And in vain!
One of the key tips is to always keep this or that Exception Breakpoint enabled. Exception breakpoint is triggered when an exception is triggered. In case this exception is unprocessed with the breakpoint turned off, the stack that led to the error will not be shown. Surely everyone somehow faced the problem of finding errors like [array addObject: nil] or out of range. So, such breakpoints are a way to catch such problems exactly at the place of their origin.
The second thing about breakpoints that I would like to point out is the ability to set conditional breakpoints.
If you have a piece of code that is highly used in a project (for example, CCNode in cocos2d), then without any conditions it is very difficult to catch a specific problem. They support the usual objective-C syntax, that is, there you can verify that the object being passed is of a particular class, that it has a specific value of some property, and so on. Very comfortably!
Well, yes, the work of conditional breakpoints slows down the application very much - so it’s better not to overdo it.
15. Generations
And I would like to add about the search for memory leaks in the code. As a rule, Instruments with the Leaks preset are used for this, but the main problem of this tool is that there are leaks that are not considered as leaks for this tool and I had to deal with the code where several megabytes flow away for the user’s case and Leaks doesn’t show nothing - it is connected exactly with what is actually considered a leak. So lately, I’m using the Allocations tool to look for significant memory problems.
Important. This tool is separate, but it’s better to run it in a preset with Leaks - because being launched separately it is not always correctly able to paint the Retain / Release history for a specific object - I don’t know if it’s a bug or a feature.
So here. Pressing the mark generation button essentially marks each non-tagged object created by this point (in a broad sense, the memory allocated for the structure is also marked). Further, as the application lives, only those objects remain in the generation that have not been released to date.
Having deployed a specific generation, it is easy enough to find the classes used in your project, and also to see why they are still alive (for each object you can see the history - where and when it received the message retain and where release).
I recommend reading here about the specific aspects of using this tool.
Thank you for reading!
and I will be very grateful for some of your tricks and practices.
Source: https://habr.com/ru/post/232049/
All Articles