The history of the development of iOS-application. Basically about the rake
I understand that there are already a lot of such stories on Habré. But each story is unique and is a small drop in the cup of someone's inspiration. In this article I will tell you how I wrote my application for iOS, what rake I had stepped on and what I would have done differently in my future projects.
The basis of the basics is the idea. It is difficult to realize anything without a clear idea of what should be at the end. And I had such an idea. I have always been interested in quantitative indicators of my life. And it is precisely those criteria that the technique cannot be measured on. They are subjective and evaluated by our feelings. The idea was born to make an application that would allow to evaluate the past day precisely for such subjective ideas. In addition, it would be nice if it also helped mark the progress towards achieving the goal.
The idea itself is, of course, very good. But she is nothing until she finds material embodiment. And the first step on this path is its description. Drawing up the first descriptions of the future application, the outline of the first TZ, the first outline of the interface. This is where I made the biggest mistake myself. It is written about it in every such article, and still everyone is doing it. It would seem that the whole application is in my head, I can imagine every screen, every action, but, as it turned out later, this is not enough. In the process of work, there are many nuances, trifles, which for some reason have not been viewed in my head, and that's just what they take away the lion’s share of development time. I approached my next project more thoroughly and the TOR for it includes a description of transitions, pressure reactions, animations, etc. In short, it is necessary to eliminate as far as possible all white spots in the idea. Provide the maximum number of use cases. This will significantly speed up the work in the next stages of development.
You should not think that you can do everything. Unfortunately, this is not the case. I decided and paid for it with wasted time and nerves. It seemed to me that since I imagine the final product, I don’t need to draw it, but I will do everything in the course of programming. Great misconception. As a result, I got a terrible, not only UI, but also UX. Although a working prototype created.
')
True, its creation should have taken a week or two, but not as not 2.5 months. Here it should be noted that the presence of this prototype has greatly helped in the future. From now on, I will create prototypes, but do it with the help of specialized tools:
The first option was no good, and, moreover, I had full confidence that Apple should not let it in the AppStore. Therefore, it was decided to restart the development. The first thing I did was rewrite the TK. It was no longer just a description of the idea, although he was still far from ideal. The description of the application screens, transitions between them appeared in it.
I found a designer for the app. Pro searches for designers, and workers, written quite a lot. I searched through freelansim.ru, and, of course, I spoke with everyone. It should be noted that the choice of people for work is always a subjective and intractable to a logical explanation decision. It even seems to me that this is akin to a lottery.
I was lucky that I chose a person who not only perfectly coped with the task, but also greatly helped in the testing phase.
The design was created and slowly the application took on the appearance. In the meantime, I decided that once I reloaded the development, I would do everything as my mind as possible. Since from my own experience I had only one unsuccessful prototype, I set about studying someone else's experience. Here is what I learned from read articles and viewed reports:
These simple preparatory steps and a good project structure save a lot of time for changes, especially for project navigation.
This, I think, is the most interesting and useful part. Much of what I describe in it should be clear and obvious to an experienced developer, but when I first started, I lacked this knowledge.
At WWDC14, Apple introduced a new way to localize applications. You can export the entire project to an .xliff file and translate it. This is practically the standard in the world of translators. At least the presentation said exactly that. I was delighted: a good, easy way, and all in one place. In the place of the program where translation is needed, instead of the usual line, a macro is written:
NSLocalizedString (@ “string”, @ “comment”).
At the beginning is the line that requires translation, and then a comment, mainly for the translator. It does not affect the program in any way. But the trouble is, no one is immune from mistakes, and there are places that are repeated in the program. In general, if you make a mistake somewhere, then for correction you will have to look through the whole project. But that's not all. The fact is that the string for translation in the .xliff file becomes the key, and if you change it in the program, and the translator does not change the translation file, you will receive two lines with the same translation and different keys. Xcode will not find the translation and the place will not be localized.
The solution to this problem was the combination of the old and the new method of localization. All strings needed for translation are placed in the Localizable.strings file as key value. And we turn to the key. Now we have the opportunity to correct the source code, without fear of translation. And the translator, again, gets a familiar and convenient format for work.
Everything described in this section was solely due to my ignorance.
I tested everything I wrote on my iPhone 5. The program worked perfectly, I looked at it and could not get enough of it. There is a moment in the application when the user has to evaluate his day, and for this he is offered to use a slider, and the assessment can be carried out on three different scales: one hundred to ten and three points. For the one-point and ten-point system, sliders are used, and for the three-point emoticons. All this is displayed in a table in which each criterion is allocated its own cell. For convenience of choice, I wrote the following:
The values themselves are stored in CoreData and are presented as NSNumber. When choosing, I decided to do the following comparisons:
It seemed logical to me, especially since it worked on my phone. Although two different objects are compared here.
But on the iPhone 5S and newer it no longer worked and empty cells appeared. A strange story that I still do not understand. But it is solved simply:
The second error appeared only on the iPhone 6 Plus and it was in the broken layout of the application. In addition, not all of his screens, but only on the elect. The problem turned out to be presented in xcode 6 constraint to margin. And by default, this feature is enabled. Again, I can not say why exactly this happened, it seems to me that the problem is in the use of Containers. But after all the same mechanism is used by Apple, for example, in TabBarController. And the problem, again, did not always appear.
PS Despite all the oddities and a bunch of pitfalls, I still liked to develop for the iPhone. My application is only a couple of weeks away, so it’s too early to talk about any results. Later, I will publish an application promotion report.
Idea
The basis of the basics is the idea. It is difficult to realize anything without a clear idea of what should be at the end. And I had such an idea. I have always been interested in quantitative indicators of my life. And it is precisely those criteria that the technique cannot be measured on. They are subjective and evaluated by our feelings. The idea was born to make an application that would allow to evaluate the past day precisely for such subjective ideas. In addition, it would be nice if it also helped mark the progress towards achieving the goal.
Description of the idea
The idea itself is, of course, very good. But she is nothing until she finds material embodiment. And the first step on this path is its description. Drawing up the first descriptions of the future application, the outline of the first TZ, the first outline of the interface. This is where I made the biggest mistake myself. It is written about it in every such article, and still everyone is doing it. It would seem that the whole application is in my head, I can imagine every screen, every action, but, as it turned out later, this is not enough. In the process of work, there are many nuances, trifles, which for some reason have not been viewed in my head, and that's just what they take away the lion’s share of development time. I approached my next project more thoroughly and the TOR for it includes a description of transitions, pressure reactions, animations, etc. In short, it is necessary to eliminate as far as possible all white spots in the idea. Provide the maximum number of use cases. This will significantly speed up the work in the next stages of development.
Development
You should not think that you can do everything. Unfortunately, this is not the case. I decided and paid for it with wasted time and nerves. It seemed to me that since I imagine the final product, I don’t need to draw it, but I will do everything in the course of programming. Great misconception. As a result, I got a terrible, not only UI, but also UX. Although a working prototype created.
')
True, its creation should have taken a week or two, but not as not 2.5 months. Here it should be noted that the presence of this prototype has greatly helped in the future. From now on, I will create prototypes, but do it with the help of specialized tools:
Development. Reboot
The first option was no good, and, moreover, I had full confidence that Apple should not let it in the AppStore. Therefore, it was decided to restart the development. The first thing I did was rewrite the TK. It was no longer just a description of the idea, although he was still far from ideal. The description of the application screens, transitions between them appeared in it.
I found a designer for the app. Pro searches for designers, and workers, written quite a lot. I searched through freelansim.ru, and, of course, I spoke with everyone. It should be noted that the choice of people for work is always a subjective and intractable to a logical explanation decision. It even seems to me that this is akin to a lottery.
I was lucky that I chose a person who not only perfectly coped with the task, but also greatly helped in the testing phase.
The design was created and slowly the application took on the appearance. In the meantime, I decided that once I reloaded the development, I would do everything as my mind as possible. Since from my own experience I had only one unsuccessful prototype, I set about studying someone else's experience. Here is what I learned from read articles and viewed reports:
- Use CocoaPods - a great and easy tool to help manage third-party libraries;
- Structure the project in xCode - I broke my project quite primitively, but, at the same time, quite understandable.
- Think about statistics before starting development. For statistics, I used the project Yandex.Metrika and Parse. True, the statistics Parse went a nice addition. Basically, I connected this service for Push Notification, but now I plan to use it as a backend for these users. I wrote out separately all the events that I want to track in the application, and already in the course of development I just added them, without wasting time on the decision;
- Take out everything that is found in the project in more than one class in a separate file that will be easy to manage and change. This includes various enumerations, defines, constants and other data.
These simple preparatory steps and a good project structure save a lot of time for changes, especially for project navigation.
Shortcomings, frank mistakes in the project organization and interesting mistakes
This, I think, is the most interesting and useful part. Much of what I describe in it should be clear and obvious to an experienced developer, but when I first started, I lacked this knowledge.
Localization of the application
At WWDC14, Apple introduced a new way to localize applications. You can export the entire project to an .xliff file and translate it. This is practically the standard in the world of translators. At least the presentation said exactly that. I was delighted: a good, easy way, and all in one place. In the place of the program where translation is needed, instead of the usual line, a macro is written:
NSLocalizedString (@ “string”, @ “comment”).
At the beginning is the line that requires translation, and then a comment, mainly for the translator. It does not affect the program in any way. But the trouble is, no one is immune from mistakes, and there are places that are repeated in the program. In general, if you make a mistake somewhere, then for correction you will have to look through the whole project. But that's not all. The fact is that the string for translation in the .xliff file becomes the key, and if you change it in the program, and the translator does not change the translation file, you will receive two lines with the same translation and different keys. Xcode will not find the translation and the place will not be localized.
The solution to this problem was the combination of the old and the new method of localization. All strings needed for translation are placed in the Localizable.strings file as key value. And we turn to the key. Now we have the opportunity to correct the source code, without fear of translation. And the translator, again, gets a familiar and convenient format for work.
Strange mistakes
Everything described in this section was solely due to my ignorance.
I tested everything I wrote on my iPhone 5. The program worked perfectly, I looked at it and could not get enough of it. There is a moment in the application when the user has to evaluate his day, and for this he is offered to use a slider, and the assessment can be carried out on three different scales: one hundred to ten and three points. For the one-point and ten-point system, sliders are used, and for the three-point emoticons. All this is displayed in a table in which each criterion is allocated its own cell. For convenience of choice, I wrote the following:
typedef enum: NSInteger{ EDEvaluatePriceHundredPoint, EDEvaluatePriceTenPoint, EDEvaluatePriceThreePoint }EDEvaluatePrice; The values themselves are stored in CoreData and are presented as NSNumber. When choosing, I decided to do the following comparisons:
if (c.priceCriterion == [NSNumber numberWithInteger:EDEvaluatePriceHundredPoint]) { } It seemed logical to me, especially since it worked on my phone. Although two different objects are compared here.
But on the iPhone 5S and newer it no longer worked and empty cells appeared. A strange story that I still do not understand. But it is solved simply:
if ([c.priceCriterion integerValue] == EDEvaluatePriceHundredPoint) { } The second error appeared only on the iPhone 6 Plus and it was in the broken layout of the application. In addition, not all of his screens, but only on the elect. The problem turned out to be presented in xcode 6 constraint to margin. And by default, this feature is enabled. Again, I can not say why exactly this happened, it seems to me that the problem is in the use of Containers. But after all the same mechanism is used by Apple, for example, in TabBarController. And the problem, again, did not always appear.
PS Despite all the oddities and a bunch of pitfalls, I still liked to develop for the iPhone. My application is only a couple of weeks away, so it’s too early to talk about any results. Later, I will publish an application promotion report.
Source: https://habr.com/ru/post/256997/
All Articles