How did the iPhone application for ServerClub
In anticipation of the fall, I completed the development of an iPhone application for hosting ServerClub.com. Now I had a free minute, and I would like to use it to share some lessons learned during the project with Habrasoobschestvom, as well as tell about the “rakes” that we met on the way.
So, it all started with the fact that the HQ of ServerClub.com , which provides servers and related services for hire, had the idea to add a multi-platform mobile client to the website, which would provide users with access to their servers, traffic data, sensors, tickets, finance, invoices, and also would allow to order servers directly from the application. In general, they conceived to repeat the entire functionality of the web client, rethinking and packaging it into a mobile application. It was immediately clear that there was still a lot of work to do, but still, as is often the case, optimism overcame the mind, and I rated the work at 1 calendar month, after which I expected to publish the application on the App Store. Here is only in the course of development, coordination and refinement, each major feature has “overgrown” with even minor nuances, the implementation and polishing of which took extra time. In addition, unexpected surprises were presented by reviewers, but first things first.
The composition of the project team is worth a separate mention. I worked in Moscow, the server-side developer was in Vietnam, the customer was in New York, the data center was in Holland, and the office with engineers was in St. Petersburg. In this case, all were Russian-speaking. This is globalization :)
The first thing decided to choose technology. A multi-platform html site that would work equally well not only on the iPhone, but also on Android and other platforms looked like an enticing option. Having considered the pros and cons, we decided to start with a native client for the iPhone, because of its popularity, as well as the ease of installing the application from the App Store. In the case of an html site, the only advantage is multiplatform and lower cost, to the detriment of navigation speed, rendering speed, and flexibility in the use of hardware capabilities. In general, the interests of the user were put at the forefront.
')
The customer immediately made special demands on the security of the connection to the server and the storage of access details to the user account. This predetermined the choice of https, Keychain, and more. It is important that these moments were agreed at the earliest stages of the project and I did not have to quickly redo everything at the release stage, when the customer suddenly came up with new requirements - and this also happened.
We started with developing an API for client-server interaction. To do this, I created a document that was shared with the whole team in Google Docs and in a couple of days formed the basis of the API. In the future, in the course of working on the project, we more than once supplemented it and clarified it, but the most important foundations were laid immediately, so we moved quickly, without going back and breaking the construction.
Now, having a well-developed and consistent API before my eyes, I saw a clearer picture of the upcoming amount of work. And it became clear that the initial estimates were optimistic. Having made a revaluation, brought it to the customer. We must pay tribute to him, he accepted them without complaint. One developer took up the server part, the client itself - I myself.
Working through the API and architecture, I already presented the navigation scheme for the application and was ready to give it to the design. Found a freelance designer. Agreed on a price and timing. For a couple of days, the layout of the 1st screen appeared, then the 2nd one. The job went. And suddenly the guy disappears. On calls and mail in response - silence. As it turned out, he had a baby. And according to him, he spent a lot of time in the hospital, tenderly holding his wife's hand. And so almost a week. Well, you can understand fatherly feelings. But time was lost, and trust was undermined. I had to quickly look for other options. The design that you will see on the screenshots below was done by another person.
Technological problems, perhaps, was not. Therefore, I will mention only some of the features. Those who are interested in more subtle details, I will try to answer in the comments. Interaction with the server: json via https, transfer of pictures: png via https. The frameworks that helped a lot in reducing routine and time: ASIHTTPRequest , SBJson , MBProgressHUD , SFHFKeychainUtils .
Belatedly, I discovered the animation of views using blocks. Now instead of several methods in which the animation is laid out in stages:
... starting with iOS 4.0, you can write in a more compact and readable way:
At first glance, both methods are similar, but in real code, when you have to control not only the alpha (as in this example), but also a bunch of other parameters from several views, the code based on the blocks starts to gain great visual clarity. And when the code is visually convenient for perception, as a result, it contains less errors, and at the final stage it will take less time to debug. I did not just make such a conclusion, but suffered through years of work in various projects. Therefore, I try to adhere to this principle, which I advise others.
And now about the very "rakes" that were waiting for me when publishing the application in the App Store. I must say, this is not my first application for the iPhone, and so far, reviews have passed without any claims from the censors. And then just three. First, it turned out to be deeply bogus for asking the user for his e-mail at login and registration. Earlier, I repeatedly re-read the Apple Review Guidelines, but either did not pay attention to this point, or it appeared there recently. I had to remove the registration screen, despite the extreme dissatisfaction of the customer. A login was used by a nickname and this saved him from the righteous wrath of the “gods” The second claim was, obviously, due to the negligence of the censor. He stated that ordering and paying for servers is possible only through an in-app purchase (IAP). But the fact is that the order through the application is not paid, but only formed as a POST request and sent to the server. I wrote about it and waited for an answer. After 7 days, the answer comes that the application (attention!) Needs to be REMOVED by an in-app purchase, since real goods, such as server rent, are not allowed to be paid via IAP. Vicious circle. Again the letter. Again failure after 5-7 days. After that, I filed an appeal, after which I was promptly called back and informed that all the claims had been removed, you just need to remove the registration screen, which I did. And thirdly, in the text of the user agreement, the censors saw a link to the main hosting page of ServerClub.com and demanded to remove it. What is the catch here, I did not even find out and just removed the link. All correspondence took about 20 calendar days.
Total, the whole development cycle - from idea to release in the App Store - took about 2 calendar months.
App on the App Store: http://itunes.apple.com/app/id453939265
Findings:
Perhaps it was in this project more than ever that I felt the whole infinity of the world, in which a small group of people, being on different continents and communicating exclusively through the Internet, did one thing in common, smoothly and efficiently. Thanks to everyone who made this project possible, and also to you, the reader, for showing patience and reading to the end.
So, it all started with the fact that the HQ of ServerClub.com , which provides servers and related services for hire, had the idea to add a multi-platform mobile client to the website, which would provide users with access to their servers, traffic data, sensors, tickets, finance, invoices, and also would allow to order servers directly from the application. In general, they conceived to repeat the entire functionality of the web client, rethinking and packaging it into a mobile application. It was immediately clear that there was still a lot of work to do, but still, as is often the case, optimism overcame the mind, and I rated the work at 1 calendar month, after which I expected to publish the application on the App Store. Here is only in the course of development, coordination and refinement, each major feature has “overgrown” with even minor nuances, the implementation and polishing of which took extra time. In addition, unexpected surprises were presented by reviewers, but first things first.
The composition of the project team is worth a separate mention. I worked in Moscow, the server-side developer was in Vietnam, the customer was in New York, the data center was in Holland, and the office with engineers was in St. Petersburg. In this case, all were Russian-speaking. This is globalization :)
The first thing decided to choose technology. A multi-platform html site that would work equally well not only on the iPhone, but also on Android and other platforms looked like an enticing option. Having considered the pros and cons, we decided to start with a native client for the iPhone, because of its popularity, as well as the ease of installing the application from the App Store. In the case of an html site, the only advantage is multiplatform and lower cost, to the detriment of navigation speed, rendering speed, and flexibility in the use of hardware capabilities. In general, the interests of the user were put at the forefront.
')
The customer immediately made special demands on the security of the connection to the server and the storage of access details to the user account. This predetermined the choice of https, Keychain, and more. It is important that these moments were agreed at the earliest stages of the project and I did not have to quickly redo everything at the release stage, when the customer suddenly came up with new requirements - and this also happened.
We started with developing an API for client-server interaction. To do this, I created a document that was shared with the whole team in Google Docs and in a couple of days formed the basis of the API. In the future, in the course of working on the project, we more than once supplemented it and clarified it, but the most important foundations were laid immediately, so we moved quickly, without going back and breaking the construction.
Now, having a well-developed and consistent API before my eyes, I saw a clearer picture of the upcoming amount of work. And it became clear that the initial estimates were optimistic. Having made a revaluation, brought it to the customer. We must pay tribute to him, he accepted them without complaint. One developer took up the server part, the client itself - I myself.
Working through the API and architecture, I already presented the navigation scheme for the application and was ready to give it to the design. Found a freelance designer. Agreed on a price and timing. For a couple of days, the layout of the 1st screen appeared, then the 2nd one. The job went. And suddenly the guy disappears. On calls and mail in response - silence. As it turned out, he had a baby. And according to him, he spent a lot of time in the hospital, tenderly holding his wife's hand. And so almost a week. Well, you can understand fatherly feelings. But time was lost, and trust was undermined. I had to quickly look for other options. The design that you will see on the screenshots below was done by another person.
Technological problems, perhaps, was not. Therefore, I will mention only some of the features. Those who are interested in more subtle details, I will try to answer in the comments. Interaction with the server: json via https, transfer of pictures: png via https. The frameworks that helped a lot in reducing routine and time: ASIHTTPRequest , SBJson , MBProgressHUD , SFHFKeychainUtils .
Belatedly, I discovered the animation of views using blocks. Now instead of several methods in which the animation is laid out in stages:
-(void)showPickerPopup { [UIView beginAnimations:nil context:nil]; [UIView setAnimationDuration:0.5]; [UIView setAnimationDelegate:self]; [UIView setAnimationDidStopSelector:@selector(pickerPopupShown)]; tableView.alpha = 0; [UIView commitAnimations]; } -(void)pickerPopupShown { tableView.hidden = YES; } ... starting with iOS 4.0, you can write in a more compact and readable way:
-(void)showPickerPopup { [UIView animateWithDuration:0.5 animations:^{ tableView.alpha = 0; } completion:^(BOOL finished) { tableView.hidden = YES; } ]; }
At first glance, both methods are similar, but in real code, when you have to control not only the alpha (as in this example), but also a bunch of other parameters from several views, the code based on the blocks starts to gain great visual clarity. And when the code is visually convenient for perception, as a result, it contains less errors, and at the final stage it will take less time to debug. I did not just make such a conclusion, but suffered through years of work in various projects. Therefore, I try to adhere to this principle, which I advise others.
And now about the very "rakes" that were waiting for me when publishing the application in the App Store. I must say, this is not my first application for the iPhone, and so far, reviews have passed without any claims from the censors. And then just three. First, it turned out to be deeply bogus for asking the user for his e-mail at login and registration. Earlier, I repeatedly re-read the Apple Review Guidelines, but either did not pay attention to this point, or it appeared there recently. I had to remove the registration screen, despite the extreme dissatisfaction of the customer. A login was used by a nickname and this saved him from the righteous wrath of the “gods” The second claim was, obviously, due to the negligence of the censor. He stated that ordering and paying for servers is possible only through an in-app purchase (IAP). But the fact is that the order through the application is not paid, but only formed as a POST request and sent to the server. I wrote about it and waited for an answer. After 7 days, the answer comes that the application (attention!) Needs to be REMOVED by an in-app purchase, since real goods, such as server rent, are not allowed to be paid via IAP. Vicious circle. Again the letter. Again failure after 5-7 days. After that, I filed an appeal, after which I was promptly called back and informed that all the claims had been removed, you just need to remove the registration screen, which I did. And thirdly, in the text of the user agreement, the censors saw a link to the main hosting page of ServerClub.com and demanded to remove it. What is the catch here, I did not even find out and just removed the link. All correspondence took about 20 calendar days.
Total, the whole development cycle - from idea to release in the App Store - took about 2 calendar months.
App on the App Store: http://itunes.apple.com/app/id453939265
Findings:
- It is necessary to form the main feature list with the customer at the earliest stages of the project. Although it is also silly to count on its 100% immutability.
- Stabilization, nuances and polishing should not be underestimated. Additional time will always be spent on them.
- it is important not only to harmonize and document the underlying technologies of the project, but also to bring them to each participant
- Do not be afraid of the iterative adjustments of their initial estimates. Hiding them from the customer and disrupting the deadlines in the future may bring more trouble, broken nerves and sleepless nights.
- unfamiliar freelancer in the project - a high risk, especially for a short-term project
- Well-readable code reduces development time, especially when stabilizing a project.
- read the Apple Review Guidelines carefully and more often, for it periodically and without notice to the developers changes
- in some cases, the App Review Board helps to deal with the obstinacy of censors, who are also human and they are mistaken.
Perhaps it was in this project more than ever that I felt the whole infinity of the world, in which a small group of people, being on different continents and communicating exclusively through the Internet, did one thing in common, smoothly and efficiently. Thanks to everyone who made this project possible, and also to you, the reader, for showing patience and reading to the end.
Source: https://habr.com/ru/post/134345/
All Articles