One Year Notes for iOS Programmers - Learning

[[140168]]

Text/Some Bird

Preface

Before I knew it, it has been almost a year since I decided to learn iOS development. Although I always feel like I am still a newbie, I do have some development experience. It would be a bit shameless to pretend to be a newbie every day. So I decided to put on the hat of "iOS development experience for one year", summarize the scattered experiences and insights of this year, and share some of my own experiences and opinions, so as to make a definition and continue on a road of no return.

Self-study and training

The first choice for learning iOS development is often self-study and training. Self-study is usually either unbelievable or poor, which is self-evident. In the early stages of learning, the novice friends I met had different experiences, including fresh graduates, old programmers who had worked on other platforms for several years and wanted to change careers, and young people who changed careers with completely unrelated interests.

Relatively speaking, there are still many people who choose to study on their own. One reason is that the average education level is generally high now, and everyone has rich experience in self-study. They are probably experts who are preparing for the final exam. On the other hand, financial resources are limited, and the current training fees are generally inflated. Although major training institutions often advertise "employment first, payment later", the actual investment is another level that is self-evident.

I am also a self-taught person. It was not until I met some friends who were currently or had just finished training that I had a general understanding of training.

This is something I heard from someone else, so my understanding is still very limited, but why not bring it up and talk about the differences together?

Self-study begins with all kinds of ignorance. Swift, Objective-C, C, where should I start from scratch? Should I buy a Mac? What kind of book should I buy, which website has good resources, which version of teaching video is more reliable? Occasionally, there will be unfounded questions such as "Can I find a job after studying for 3 months?" If there is no reliable guidance, there are always surprisingly many pitfalls in self-study. Some friends are studying while working, and they have less time to begin with, and they need to spend a lot of energy to open up new areas.

When I meet friends who ask me such questions, I will first ask them if they have any relevant experience. If they have no experience at all, I will recommend them to learn C language first, because C language is relatively easy to get started with and can help them get a general understanding of development quickly.

On the other hand, you can also test your understanding of programming so as to estimate your future learning efficiency. Finally, because Objective-C itself is a superset of C, you will not take detours if you focus on C.

For those who have relevant experience, it depends on the situation. Find a direction to expand based on what you already know, such as object-oriented programming and the syntax characteristics of Objective-C. Expanding based on the existing foundation will save a little effort. On the one hand, you will have a deeper impression by comparing the similarities and differences; on the other hand, after learning the first language, writing Hello world! for the second time will always have less things to explore.

Self-study is a process from scratch, you have to proceed step by step, and don't be greedy. Especially when the direction is not clear, on the one hand, you don't want to take a detour for no reason, and on the other hand, it will undermine your confidence in learning. When you are in a bottleneck period, you should sort out the current learning focus, and then do some more in-depth thinking on the things you have learned before, which will make it easier to get out of it. Especially after practicing, you will think more deeply, even if you understand one point more thoroughly, and you will immediately have a sense of mastery. This level of improvement will broaden your horizons, allowing you to look at development from a different perspective, and the sense of accomplishment will soar~

Another self-study experience is that getting started with development is always a struggle. I finally wrote my first class with my own name in Objective-C, but I still don’t know how to manage memory or construct interfaces. I’ve put in a lot of effort, but it seems like I still don’t know anything. This kind of experience can easily make people panic. You need to learn to grasp the learning stage, know what you have learned, and what knowledge points you need to learn to achieve your goal, and then break them down one by one.

In the process of self-study, it is very important to have a good attitude and a good grasp of the learning process. And a piece of advice: because it is self-study, be prepared to find yourself an idiot in any situation. The author just lost a person on GitHub two days ago, and then he realized that in the class method, self refers to the class rather than the instance. I am ashamed.

In contrast, during the training process, on the one hand, there is someone to supervise, and on the other hand, the segmented goals and progress are relatively clear, so the pits mentioned above are basically leveled without filling them. Moreover, when a group of people sit together, it is easy to know their strengths and weaknesses, and it is also easy to find out the gaps. Furthermore, in an environment of mutual discussion, it is always easier to discover the blind spots that you subconsciously avoid alone, which is also a good method.

However, one thing that needs to be emphasized is that you should not have too high expectations for training. Although the employment environment for iOS development in China is good, it is not as exaggerated as advertised. In actual recruitment, there will be no special preferential treatment for those who have received training, and sometimes they will be looked down upon, so remember to impress the interviewer with your actual development ability?_?

Recently, I occasionally hear friends talk about their training experiences. In fact, the focus of the training is quite good. Because most of the teachers are former and current practitioners, the learning focus is closely related to the actual development work. In addition, some trainings will provide some warm-up of C language and basic object-oriented development for those with no basic knowledge. The transition is relatively smooth, which is relatively friendly for those who are new to development. Although as a self-taught programmer, I always intentionally or unintentionally criticize training, but in fact, I have to admit that the training of work skills has always been pragmatic, but the fee is = =

So in summary, it is recommended that if you have a weak foundation and have adequate financial resources, you may consider a reliable training institution. Only those who have some development experience or are confident in their self-study ability can try self-study. As I said before, there are always many pitfalls in self-study, so you must be mentally prepared.

Research, Question and Discuss

About a month after I found the job, I felt that I could solve some simple problems, so I occasionally went to the CocoaChina forum to reply to posts. I also joined a group of novice developers, where we often discussed related issues.

But I soon got tired of replying to posts. Simple questions were often surprisingly similar, and I couldn't help but want to copy and paste. On the other hand, due to the limited information provided in the questions, the solution process was partly based on inference and partly on guesswork. Although I gave a reliable suggestion based on my extensive experience of self-study and not falling into any pitfalls, I was powerless and the last sentence was still "Take another look..."

When problems keep coming up, the ability to do independent research is more important. In the initial stage, the most difficult part is that there is not enough theory as a basis for making reasonable assumptions. I really don’t know why I am so imaginative and presumptuous. Maybe it’s because the weather is bad today, so it reports an error? In addition to reiterating the importance of the basics, we also have to use a magic weapon: try it bit by bit.

Few students who are not good at writing grammar can learn to use breakpoints and debug tools, so the dumb way is to comment and frequently test sentence by sentence. To verify the correctness of each sentence, on the other hand, strengthen your basics and start to dabble in debug tools. Then I found that I could add "abnormal breakpoints" to view the values ​​of variables within the scope in the case of interruption, and run sentence by sentence. On the one hand, independent research is equivalent to practical experience, and on the other hand, it will also improve my debugging skills.

If you really can't figure it out, you still have to ask. But since we're asking questions, we should do it in a way that can get the answer. I really hate screenshots. They take screenshots of a large section of code without any context, and then follow it up with a sentence, "What's wrong?" They don't even give me a chance to paste it and reproduce it myself (ˉ﹃ˉ). Then I can only ask a long series of questions, paste the error report, paste the context, and so on... In the end, I found out, damn, your attribute is nil! ?_?

Therefore, the reasonable way to ask questions is: if you can locate the problem, then locate it. If you can make reasonable inferences, attach your inferences as well. More importantly, remember to attach screenshots of errors or warnings. In short, the more evidence you can use to infer the problem, the better. Generally, when you have collected so many things, you will probably find the problem yourself. So, in other words, check yourself more often, and make sure that you really can't find the reason (mostly because of carelessness, I say = =), then ask questions. If the final conclusion is due to your own blind spots in knowledge, limited understanding, or unknown knowledge points, then congratulations, you have asked a question that is very valuable to you. But if it is because of carelessness = = I don't blame you, just go and face the wall yourself.

A rather annoying problem I encountered before was NSLog(@"%@ %@",string1),string2;. They posted a piece of code saying that there was no problem checking the variables, but the printing crashed. Then a group of people searched the code for a long time and finally asked me to post the printing sentence. At first, everyone thought it was some weird syntax like "black magic", but when I typed in the code, I found that there was a missing print variable, which was fooled by the comma operator at the end. Then they complained in the group, "Do you really not read the warning?" Thinking about it afterwards, I still feel nervous.

In addition, try not to ask questions that can be used to be lazy. When I am in a good mood, I will always help Baidu give a link or document address, but later I will basically say "check the document" or "Baidu yourself". This situation is not so absolute. With a fixed discussion circle, I have some understanding of everyone's development experience. Sometimes when I encounter similar problems solved by friends before, I will occasionally be lazy and directly ask friends for a piece of code and leave. It is recommended to grasp two key points. One is not to make the other party very troublesome, and the other is to make sure that if you can't be lazy, you can solve the problem yourself. The second one is more important.

From my own experience, having a stable circle to discuss and ask questions is a good way to learn. Everyone has blind spots, and valuable topics can effectively help you avoid this problem. Different perspectives and different development experiences will bring a lot of inspiration and reliable experience, and will also tell you in a practical way what you don't know yet but must know.

I would like to add one more point. I do not recommend that you treat questions as if they are irrelevant to you, even when you know very little. It is not easy to ask a valuable question. You need to infer the key points of the question, the knowledge points involved, and then systematize the relevant knowledge points. Going through the whole process is an improvement in independent learning ability. And when you tell others, you will often find that you are vague about your questions, which are precisely your weak points. Don't miss such an opportunity, because once you miss it, the next time you encounter it, it may be a crash.

English

The first two sections are more for beginners. As the development time increases, some problems that are not noticeable at the beginning will be exposed.

English is a stumbling block on the road to development. The further you want to go, the more you have to face it.

I still remember the first month of my first job. According to incomplete statistics, I spent at least 3-4 hours a day looking at official documents. I was so exhausted that I couldn't describe it. Fortunately, the three-finger word search function of MAC is very convenient. It is equivalent to holding a dictionary in one hand and reading an article with the other hand. After reading for a while, I am no longer so averse to reading English literature.

The biggest difference between professional English and ordinary English lies in the use of specific vocabulary. For example, OOP stands for Object Oriented Programming. Such professional vocabulary and even abbreviations will not cause too much reading difficulties. Even if you don’t know what it is, you can get the answer by searching Baidu. However, some common words that are commonly used become pitfalls that are difficult to master during the reading period.

For example, declare and define are translated as "declare" and "define" respectively. If it is in the context of "declare first, call later", you will find that it is completely reasonable to explain it as "define first, call later". But in actual literature, the difference between the two words is far more than just a simple translation difference.

If you have come into contact with Python, it uses def (short for define) to define functions, while in the C language system, declare is used to declare functions and variables. We use the errors reported in the two languages ​​to demonstrate this small detail.

 #python
 print a

Traceback (most recent call last):

File ““, line 1, in

NameError: name 'a' is not defined

 //Objective-C  
 NSLog(@ "%d" , a);

Use of undeclared identifier 'a'

Of course, if this is the case, the obfuscation effect cannot be achieved. Unfortunately, in Objective-C, you can also see the appearance of define, but where is it? Macro definition #define:

 //Objective-C  
 #define a 1  
 #define a 2  

'a' macro redefined

In this way, if we do not distinguish between the above two words, but simply rely on looking up words, it is very likely that we will make mistakes in understanding in a specific environment. On the other hand, when we have a clear understanding of the meaning of these words in a professional environment, they can become a key to our understanding of the meaning of the article. Not only will we not miss the details, but it will be easier to infer other unfamiliar content based on these words.

Here is a typical example of the error "unrecognized selector sent to instance". It is easy for beginners to ignore it and not take it seriously. Then they scratch their heads and can't figure out what went wrong. However, the cause of this kind of error is often a very basic error: the method name in the .h file is inconsistent with the .m file. For example, the code we saw before:

 @interface Man:NSObject
 -( void )setID:( int )id
 age: (int )age
 sex:( int )sex;
 @end   
   
 @implementation Man
 -( void )setID:( int )id
 sex: (int )sex
 age: (int )age{
 //...  
 }
 @end  

Although static compilation will give a warning that the previously declared method is not implemented, the Build Seuccess is certain. So the error will only be reported when the method is called. The usual practice is to start from the context of calling the method, and then if you can't find the error, look for it in the implementation of the method. The most frustrating thing is that I set a breakpoint for the first sentence of the implementation, but an error is reported before it comes in, but all the previous codes are fine. Depressed? Yes, how much time does it take to find out that the method name is wrong? After finding out, do you have the urge to slap yourself?

But if you know that the error "unrecognized selector sent to instance" means that the instance responded to the wrong method (you can also translate it into "unrecognized selector sent to instance", I have always wanted to complain about this error = =), then the first thing you should confirm is whether the selector is correct. And what is a selector? If you pay attention when writing the code, in the addTarget: action: method, the action parameter has a @selector tag. Of course, there are also "rogue" statements such as respondsToSelector, which are all telling you the same information, selector, which is actually the method name. The method name is based on the method declaration in the .h file, so why not check the method name in the .m file?

#p#

When I was learning English, my teacher always told me that I should learn to express the same meaning in different ways. However, in professional literature, the reference of words is often accurate and single. Even a colloquial word like push has a very specific meaning in iOS development. Accumulating these words will be very helpful for reading. Even if you don't go to Google, StackOverFlow, or read English literature or official documents, it is still necessary just to understand warnings and errors.

At the beginning of Objective-C design, in order to make the whole language easier to read, multi-segment method names were specially designed to explain each parameter. Thanks to the powerful auto-completion ability of Xcode, its names are often long and complete, and some keywords are used to express its functions. This allows us to effectively accumulate corresponding expressions while reading the code. So don't ignore the accumulation of class and method names because of the convenience of auto-completion. If you remember more, on the one hand, you don't need to frequently query documents when reading source code. On the other hand, you will find that people use these words intentionally or unintentionally in English literature. In the brief description, you have actually been given code-level steps, which is an unexpected gain.

In addition to reading and accumulating knowledge, another effective method is translation. Translation is something that forces you to dwell on the details of the meaning of each word. Once the translation is inaccurate, the context will immediately appear incoherent. The translation process will subtly speed up your reading ability.

For example, when I translated a document for the first time, I was still at the stage of translating each word at the first time, spelling it into a whole sentence at the second time, and polishing the text at the third time. Simply put, I didn’t know a lot of words, so I couldn’t focus on the meaning of the whole sentence. And the process of spelling it into a whole sentence couldn’t connect the context well. So it was basically only by the third time that the translated text could basically present the meaning of the article itself. It’s a pity that I was at this stage when I translated objccn’s article for the first time.

Later, I tried to translate some other articles, and gradually I was able to get the word order and meaning of the whole sentence in the first time, and in the second time, I made some judgments about the context by reading the whole article for the first time. By the third time, the article had a certain readability. I was very pleased with this seemingly insignificant progress. I remember that I didn't know when it started, but I suddenly found that an English article was full of seemingly obscure professional vocabulary, but I just knew their meanings. Compared with the sense of accomplishment, I felt more of a sense of disbelief. As a poor student, I should always scratch my head and resist sleepiness when I see a screen full of letters. I can't imagine that I can understand the general meaning after reading it once.

In addition, I also signed up for an English training class, where I could communicate with foreign teachers face to face, which made up for my lack of English skills to a large extent. Although I have limited time to attend classes due to work, after nearly half a year of accumulation, my listening and comprehension skills have improved a little. Just like the code that was like a divine book at the beginning can now be repeated in my mind and typed out subconsciously, the proficiency of skills always makes people happy and satisfied, and I also know that there is still a lot to learn and a long way to go.

Of course, even so, my English is still very poor. A very realistic example is that if I ask questions on StackOverFlow, I will probably spend most of the day trying to come up with nothing. When listening and speaking are no longer obstacles, it is urgent to improve speaking and writing. If one day I can communicate with the masters or go to WWDC, at least English will not stand in my way.

The code belongs to the world, and the code is also in English. Reality has always been so cruel.

How to improve

The bottleneck period is always confusing. Long-term confusion may lead to a lack of enthusiasm at work, inaction all day, constipation, disharmonious life and other adverse effects. How to improve has gradually become the second biggest problem for novice iOS programmers since they started working. The first one is of course finding a partner. Don't ask me why.

Generally speaking, most of the strategies provided on the Internet can be summarized into three points:

• Read more websites and blogs
• Write more code, think more
• Learn English well

Because it is short and not very step-by-step, the actual operability depends mostly on personal luck. In addition, this kind of advice does not teach students in accordance with their aptitude, it is too general, and students who really encounter problems still have to solve them by themselves. As a long paragraph of pseudo-dry goods, the following are some of my personal suggestions. Don't plan to copy and paste them. Combine them with your actual situation. After reading it, you will know that I am advising you.

There are two main principles that I believe in when developing self-study:

• Everything you see now was written by our predecessors. The main reason why they can do things that you can’t do is because they know things that you can’t.
• Time and energy are always the only way to progress.

There is a classic term in data structure called "traversal", and there is a classic method in cracking technology called "exhaustive enumeration". To put it bluntly, there is only one thing, try one by one. No matter how complex the topological model is, and no matter how terrible the order of magnitude is, try it first. Not to mention the childish behavior of dragging out all the controls on the right side and fiddling with them when I first came into contact with Interface Builder. At least when reading an article, if you see a new author, click on his blog to see what else he has written, and then don't ask to read it one by one, at least if you see something that you happen to have heard of and are not familiar with, don't miss it. If you can summarize the technical directions that the author is good at and the technical directions that he mainly talks about, and then fill in a collection and add a TAG, and leave it for later when you encounter related problems, you will read it again, which can be regarded as an effort.

The formation of reading habits needs to be gradual. When you first start, you can't understand most of the articles. At this time, reading too much will only undermine your confidence and make you recognize a few names. So at the beginning, it is recommended to find some articles that introduce iOS development knowledge points. There are several detailed knowledge point divisions circulating on the Internet, which can be used as a reference. At this stage, we only need to roughly understand that these concepts belong to the category of iOS. It is enough to have a superficial understanding of what they are. Even if there is a deviation in the understanding of the definition, it is allowed.

When you have learned most of the names, there will always be knowledge points that are close to where you are studying now, and you can only reach them by tiptoeing. Yes, start with it, expand and improve the existing knowledge points, and then correct the existing knowledge in reverse. It works every time. At this time, you can start your own reading journey. Start reading when you encounter articles that are close to you. Don't rush to skip when you encounter articles that are far away. Remember to collect and tag them. You can consider using Evernote's Chrome Clipping Plug-in and Pocket as a backup tool.

In fact, it is most enjoyable to learn something when you know nothing. Because you don’t know anything, you don’t have to be picky, you have to learn it anyway = =

When you gradually begin to have a grasp of the overall framework, that is, when there will no longer be a particularly large definition deviation, you should start to make breakthroughs one by one. What should I do if I have difficulty making choices? What should I do if I don’t know which knowledge point is more important? Here, my suggestion is to start with small knowledge points, such as block syntax, proxy/protocol code implementation, these small pitfalls that are easy to encounter in the early stages of development, they do not involve particularly complex underlying principles, and do not require too many additional knowledge points as support. The main reason for choosing small knowledge points is to go through the process of thoroughly understanding a certain knowledge point first, to experience the process from qualitative to quantitative.

Improving skills cannot rely on long-term repetitive work. Just like you can't catch a fly flying in the air even if you use chopsticks to eat. Improvement requires short-term, targeted, and high-intensity training. Specifically for development, it is a process of learning from one example and then summarizing and generalizing. The level you reach is that you already have a scale in your mind, understand all the rules and boundaries, and "writing like this must be correct." As for how to learn? Please learn to be more violent, try out all the possibilities of errors, know all the wrong methods, and then you will know what is correct. As for why only these are correct, please refer to the blogs you have read in those years.

I personally don't believe in quick success or shortcuts. Reduction means trade-offs, and the reduction of knowledge points means there will be blind spots. Instead of learning one trick and relying on it forever, it is better to go through all possibilities honestly and steadily. After experiencing it in practice, you will naturally come to a conclusion.

In addition, with continuous trial and error, you will clearly feel the most real rules. You will know what is completely infeasible, what is not officially recommended, and what is feasible although funny. You will also know that "build success" actually does not explain the problem at all, and you will know that except for the compiler, everything else has no final interpretation.

When you have this kind of trial and error experience, the question in your mind gradually changes from "what is what" to "why is it like this". At this time, it is the beginning of extensive reading, because you have mastered the actual verification ability, and have a basis for distinguishing articles, knowing which parts are useful and which parts are just the author's pretense and fantasy (ok, my writing style has been exposed = =).

I don't mean to disrespect the authors of technical articles. In any case, it is a commendable thing to spend time and energy to share knowledge, but the fact is that there are different levels of authors, and there are occasional flaws in the articles. We can't force every author to write an article with both good color and good art, so you should understand that when reading, don't rush to believe it easily.

After going through the above process, you can actually become an entry-level iOS developer. After all, you can solve problems by copying others. When you learn [] and :, you can write the first method call; when you learn @interface and @implementation, you can write your first class; when you learn how to drag in Interface Builder, you can construct your first interface, and then writing a calculator is no longer a problem.

Therefore, as development becomes more proficient, it will become a process of selecting corresponding solutions based on needs, and improvement is the accumulation of solutions and the improvement of the maturity of these solutions from development to use.

The subsequent learning progress should be based on your own needs and interests. Once you master the methods, acquiring knowledge will mostly be a natural thing. Generally speaking, ARC/MRC (memory management related), runtime (runtime related), and GCD (multithreading related) are the three major killers in iOS interviews. Since the concepts involved are relatively low-level and complex, and the details are relatively trivial in the specific code environment, it is already a bargain for you to repeat the principles. In addition, the overall structure of UIKit is not as simple as the two base classes of UIView and UIViewController. Mastering deep-level triggering, response, and drawing are all required courses. And with the upgrade of SDK, many convenient methods are actually provided. Remember to look for clues in many articles.

A better way to learn is probably to study videos and articles of the same level as WWDC. I am relatively new to this field and this level is beyond my reach, so please refer to the sharing of various great masters. If you can write a few pioneering articles and send me a link, I would be very grateful.

The above are some of my self-study experiences along the way. If you look carefully, it is not difficult to see that they are actually some stupid methods. Constant trial and error, constant reading to find useful parts, and the biggest limitation may be your own perseverance and imagination. If you think that knowing these is enough, or you are unable to be serious and profound when trying and erroring, then the results you get are not only unsatisfactory, but also a waste of time. This is why I said in the previous article that it is for reference only.

However, if there is no better way, you might as well give it a try. Once you learn to ride a bicycle, it will be difficult to fall again. Trouble is better than no learning.

postscript

Unconsciously, I haven't updated my blog for two months, and my new job has entered its fourth month. The new job is a rare opportunity, and I have gained a lot from the experience over the past few months. However, the time and energy I have invested in my work are not the same as before. Not only has the blog update slowed down, but many things that I used to have time to do have also been stopped intermittently.

Although this blog is part of a new series, it is still unknown when the next one will be written and whether there will be a next one. I sometimes feel hopeless when I want to go back and fill in the two big holes in the previous blog.

I can't guarantee anything, I just hope this article can help some iOS developers who are about to or are getting started.