Wireless Development Miscellaneous

Miscellaneous
Suddenly I want to write something, not so formal. Let's talk about objc client development from some perspectives. (Objc cool people directly point out what is wrong and give them a learning opportunity)
Crash:
Empty objects are stored in dictionary. objects are recycled and accessed. Target does not have the corresponding Sel, and mainthread is not used for interface operations ......, The intuitive embodiment of the customer is the crash. Some people mentioned that the client's crash was a face of contempt, and they felt that programmers did not handle the exception very well, in fact, the client has more uncontrollable factors than the server. Therefore, it is basically unreliable to evaluate the client from the server side or try catch to handle all exceptions at the client's branch boundary, also, I remember the common sense of writing to the server: do not let the system run with illness. The same is true for clients. Branch exception crash is sometimes a protection because the client affects a customer and the restart cost is much lower than that of killing problematic processes. (Of course, the above-mentioned flashback occurs frequently in the conventional process, so it is directly uninstalled. Therefore, the bottom-layer objc users should use the server to protect the client experience carefully)

Null Pointer:
When Java first came out, the biggest selling point was: no pointer complexity. Indeed, GC is a great progress of the language, looking at today's Java virtual machine that has exceeded the Java language itself, we can see its value. objc, from the early autorelease, to the 5 arc, is actually helping developers to ignore the pointer issue, in fact, the key lies in object transfer. When the system grows and becomes more complex, it is more difficult for developers to control the lifecycle of objects in the system. The NULL pointer in objc brings two kinds of harm: 1. Dirty object. (It is equivalent to discovering a cliff behind the door after opening the door and going out ). 2. There is no reaction to bring about a variety of strange. (In java, if a null object is operated, a null pointer error occurs immediately, and any method call is made to a null object in objc, nothing happens, at the same time, if you still prepare to return the result after the operation, the result will be normal to get nil, this kind of pitfall will make many Programmers think that the static Code does not leak, but the result is still found to vomit blood)

Thread:
Those who are familiar with Java, the most common is to control their own threads. Of course, after 1.6, there will be mature thread pools available for use. The original method of doing it all by themselves is greatly reduced, however, you need to care about the number of threads and queue. In most cases, the objc does not need to start the thread independently (and objc does not recommend controlling and managing the thread itself). The mainthread is driven by queue + event, backendthread can also be easily handed over to the system for creation and use based on the load. You can also simply create a daemon thread + block mode by using a thread, if you really need to have a lot of interactions and scheduled customization, run loop is used, which is very simple for timer or source
Input event driver mode ). However, in one sentence: objc does not need to be directly provided by the system. runloop supports some processing that you think is high performance and high real-time (but remember that this is the client, and the CPU capability is limited, so sometimes the so-called high real-time performance is a meaningless assumption, which will be mentioned later)

Thread security:
Every user who writes to the server is used to programming on the client. The most difficult thing to adapt to is thread security. In particular, sometimes it saves some memory and initialization overhead to reuse stateful objects, it will begin to worry about various thread security. However, when writing a lot of code, you must carefully consider your assumptions, user Interface operations are a good barrier for ordered Operations. That is to say, the program you write may be logically parallel, but the added user interface may always be serialized, of course, the iPhone and iPad may be different. Some people think that many things at the bottom of the iPad and iPhone can be shared. In fact, many iPad users and parallel behavior operations will move closer to the server development. Therefore, thread security needs to be considered, but it is not always the best, because it is necessary to weigh the client's memory and CPU consumption, and it is necessary to do a little bit of tricks.

Relationship between remote data and local data:
As mentioned above, the uncertainty of the client itself is much higher than that of the server. The biggest problem is the network. The unstable network leads to Data Acquisition failure or even incomplete data, at this time, client compatibility is basically impossible to achieve the ultimate, and network problems also bring a great challenge to the user experience, what we have to say at this time is the relationship between local data and remote data. In many cases, apart from the initialization process, the "final consistency" will be used in the client implementation mode. The final consistency on the server is used for behavior operations at different stages and is finally corrected, consistent results are generated, and the final consistency of the client means that when local data is available, local data is the only standard, and any operation takes local acquisition and update as the first action, user experience is an immediate acceptance of behaviors (money-related). The backend can perform real consistency updates asynchronously, and finally correct local "dirty data" based on the feedback from the server ". At the same time, you can add a version concept during the design, so there may be a certain degree of data update consistency guarantee for users to update multiple terminals.

Memory Management:
In Java, objects are reused a long time ago. the Java language improves the reuse Management of objects, so the cost of object creation becomes very small, the complexity of cleaning old data brought by reusable objects gradually frees developers from reusing (except for some resources not controlled by the Java language: file handles, sockets, and database connections ). In objc, the reuse of components such as ui or obj is usually not reused by individuals. If heavy objects are stateless or few States, reuse them as much as possible, when there are multiple object states, you can consider not to reuse them.

Collection of errors and behaviors:
In fact, the client needs to collect behavior data and error data. The former is a necessary guide for productization, and the latter is the best support for flexibility events. However, due to network problems, this data requires business-based rule compression and batch compression and uploading on demand. In fact, I personally think this is a very valuable Design for wireless clients and servers. (Of course, it's easy to do. It's nothing more than power consumption and traffic consumption)

Server support:
IOS is better than Android in pushing, and it is easy to use. At the same time, the OS layer of the client is also in place for application support, however, Android push requires a lot of effort (I remember that I used to publish Weibo directly to a push company). On the other hand, the design of server-side API is still very exquisite, in many cases, many business systems usually encapsulate the business requirements and interfaces in order to have enough responses for a request, the result is that the external interface is poorly reused (but wireless connection is required to save the number of network connections), but there are still many practices. In the top year, I encapsulated rest and tql, however, I didn't push out rest at the end, while tql was strongly pushed, and tql was positioned on wireless, in fact, if the top tql is used by wireless students, they will know its value. When the tree was planted in the past, it is now cool, and if necessary, they will continue to make the program stronger next year.

Open source Library:
Currently, our wireless platform applications are divided into two layers: the official and third-party SDK base libraries and the upper-layer application libraries. The SDK base libraries basically do not rely on any open-source libraries, the upper layer depends a lot. How does one determine the Open Source dependency of objc? First, objc is a mature language. It can be seen from its interface support and discarded changes, so the most important choice for open source is whether you can control it (if you want to modify it). Most objc open source files, unlike Java, are relatively simple, if the class library used is very large and complex, consider it. Because the language changes rapidly, many early writing methods are only suitable for the current language support, the language optimization itself will greatly improve and change the programming mode, so you can write at the underlying level and follow up the language optimization at the underlying level (thread, file, network, event-driven, etc.), some tool libraries can directly use open-source files (check if there are any obsolete methods in time ). So what matches the objc open-source situation is that most of the files are relatively simple and open-source files. If you can control them, reuse them. Otherwise, you can view the developer and stack files.
Overflow.

Compatibility:
I think every person who learns objc will seldom read books in China (books in foreign countries are similar), because when you read, you find that the examples and procedures in the book are hard to find in the xcode you downloaded today, and many functions used in the book are marked as obsolete. Therefore, you should read the document, just go to mongo.apple.com (Chinese characters are also supported recently). It is better to download PDF files directly. Let's talk about compatibility again. I just commented that most applications require ios4.3 and later. I am very grateful to Apple for not repeating the IE history, directly from the IDE, it kills the sprout of backward compatibility. Different macx operating systems, xcode4.5 and above, have abandoned ios4, which is actually normal. You can see the ones in IOS that are about to be discarded, and the language features that are supported in a specific version. If you don't do this, the programmers and Apple reviewers will be killed. So, with a sigh, if you want to play with the I series, you can upgrade it to experience the joy of change. (You won't be able to go back after the upgrade. At this time, it will be very precious for developers to retain several antique OS versions :). Looking at the changes in the background IOS version upgrade, there is an inexplicable kind of refreshing ~~~)

Client development and server development:
Writing so much is nothing more than looking at some objc development feelings from the perspective of a newbie, but for programmers, if they can, you need to first try more server development experience and years, and then go to the client for development. At this time, your experience will allow you to master the client development with more certainty, at the same time, like eating food, both sides should work together. Otherwise, to some extent, technology will still reach a bottleneck, because we will not use more innovative ways to think about the global problem, it is only limited to one side of the scenario. For example, if tql is just mentioned, if the client developers say that you have blocked all of them for me, you can fix it once and add another fields option to return, the service end will be exhausted.

The above are only technical content, but it is said that the thinking requirements for developing products in the wireless field are much higher than those of the technology itself (technology is the Foundation ), therefore, a reliable development team should be able to quickly implement the product (it is best to be deeply immersed in it), and a product team should have a sense to understand the real value of the product in the wireless field. It is not convenient for products to be pasted on the outside. Therefore, if you are interested in joining us, you will gain more than technology. Remember that we are not making an app. When we come, you will know what we are doing ~~~

Trademanager contact: Fang Weng
Email: fangweng@taobao.com