⬆️ ⬇️

How we developed an application for Habrahabr





CleverPumpkin and TM began substantive negotiations in September 2013. In fact, conversations about creating an application started back in December 2012 on the sidelines of Mofas and Boomburum communication , which maintained friendly relations from ancient times (when the palmz.in forum existed, and everyone was into PDAs). The Habra team had a clear idea about the desire of its users to have mobile applications, but everything was limited by the absence of an external API.



How it all began



Advanced users know that there are unofficial “Habra” applications that parse the site. But the new official application could not work on the same principle - somehow it is not Feng Shui.



History tour:

Old-timers probably remember that in the summer of 2010, the official Habr's app from the Redmadrobot company for the iPhone was already coming out. For the whole year, the application did not receive an update with fixes and new functionality, and then was withdrawn from sale in the App Store.


By May 2013, there was already a draft version of the external API, and the guys from “Habr” raised the question of solving a pressing problem: how to choose the format for creating applications for users. Different options were considered - inhouse development, purchase of a ready-made solution (parsley, which would be transferred to the official API) or outsourcing development from scratch.

')

Comment from Denis Kryuchkov , publisher of “Habrahabr”:

Mobile applications are a completely new direction for us. At the same time, we did not have the desire, the strength and the means to create from scratch another development department for this category of products. In general, we thought, talked and decided to outsource.


In November, we signed up and the development started. Surprisingly, one of the factors of choosing us as a contractor was that Denis is a regular user of the Sports.ru iOS application, which we have been developing for more than two years.



Project start







Unconditionally, it was about creating applications for iOS and Android. But collectively, we all came to the conclusion that it is necessary to create a unique case in the history of Russian mobile software - to release a product simultaneously for all 3 platforms. We all understand that Windows Phone does not occupy a very large market share, but the share is growing, and the platform is developing significantly. As a result, it was decided to start development right under 3 platforms.



At the end of November, we started developing WP and Android versions. In early December, and connected iOS. Initially, it was decided to have the same functionality on all three platforms - it was convenient from the point of view of using the API, and also allowed to maintain parity between the three platforms.



Design, design, layouts







We had detailed TZ in our hands, as well as API documentation. Designers started work. Under iOS and Android, our beloved staff designer Lena Larkina worked. And for WP, we attracted the excellent designer of this platform, Vladimir Morochkovsky . The base colors were taken as “Habrahabra” and bright gamma.



Comment from iOS / Android designer CleverPumpkin AndyLa :

The main task was to create an interface with the help of which users who use mobile devices for Internet surfing, could conveniently and fully work with Habr through the application. And since it is primarily a resource for reading articles, comfortable work with posts and comments was our priority.



Designing applications was carried out under three platforms, it was necessary to observe a single style, but taking into account the charms of each system. For example, for Android, we have a dark theme. All for users :)



Work on the post and comments took us the most time. We have analyzed many applications with content for reading. We studied what users like and what's stopping them.



We paid special attention to the comments, because comments on Habré are a storehouse of useful (and sometimes not so much :)) information. Therefore, work with them needed to be made convenient. Brainstorms on this topic were held from the first day of work on the project. We considered a lot of revolutionary concepts. But, as they say, everything ingenious is simple, so we stopped at a simple and concise solution.


Comment from morochkovsky wp designer:

Hi, I am Vladimir Morochkovsky, designer of the “Habra” application under Windows Phone.

In this big project I was in charge of Windows Phone. The whole process can be divided into three stages.



Design. In any project I like this stage the most. I believe that the design determines the aftertaste the application will leave the user and how interesting the design will turn out. Here we took the structure of the site and most comfortably entered it into Windows Phone.



Design. Favorite stage of the designer, customer and everyone who works on the project, since it is here that the designer wakes up in every manager. This project can be called an exception. Thanks to CleverPumpkin for trust and complete freedom in making decisions.



Design support or work on new versions. We have prepared many delicacies that are not included in the first version of the application. So please be more tolerant to the roughness of the first assembly. Write constructive suggestions and suggestions for improving the interface, we will all consider and think about the implementation.


Development





While the designers designed the interface, the developers have already written the components responsible for communicating with the API. Under all platforms only native development tools and zero cross-platform frameworks were used.



Comment from iOS developer CleverPumpkin purrrminator :

I wanted to immediately make a cool article storage application by connecting Core Data with a normalized database for permanent storage of posts and other entities. But, as it turned out, the application turned out completely incomprehensible to the user. One of a number of controversial situations for example: the user, while on the network, added some post to his favorites and immediately after that lost contact with the Internet, then went offline to the “Favorites” section, which naturally could not download posts from the server, and saw in it only one post — the one that was previously stored locally when the tape was loaded — this confused the experienced habraiser: “where did the rest of the elect go? I had a lot of them on “Habré”! Everything is lost!". It was somehow embarrassing to show that lonely selected post, but it was even more illogical to hide it from the user, because it exists in the local repository and it is marked as selected. We decided to stupidly go the User Experience way: “if you want to see the tape, request it from the server”. This does not mean that posts are now not stored at all locally and the application is not usable offline - I just added a unique key with flags belonging to a particular screen. So the normalization of the database was sacrificed for UX.


Comment from Android developer CleverPumpkin erakitin :

The first problems concerned the placement of various types of content in posts, and especially in the comments. In the case of fasting, the solution was found quickly. The html-content received from the server is parsed and optimized for small screens, then its css-styles are hung, and the resulting html is displayed in WebView. With comments, everything turned out to be much more complicated. Firstly, they have a tree structure, and secondly, the content is almost the same post. We have a few ideas to display comments of varying degrees of unrealizability. Among them, even the thought slipped to display all the comments in one WebView. But since among us there was no guru layout and javascript, then this idea is not seriously considered. We stopped at the native implementation: the comments are parsed the same way as the post, but the output is not html, but the Spanned-line, which in turn is displayed in the TextView. All media content, spoilers and code open in a new window by clicking on the appropriate link. I believe that with such an implementation we were able to solve the problem of providing complete information and the convenience of receiving it on small screens of smartphones.



Part of habrayuzerov asked, for what is so cheated the second version of Android. Initially, the application was developed with support for Android 2.3.3+. In the course of development, out of the blue there were problems associated with this particular platform. This did not stop us - they corrected them, in some places even had to write very crutch solutions. But during testing, more and more new bugs appeared, and the cost of testing doubled. Therefore, in the conditions of the upcoming release, it was decided to abandon the support of those 10% of devices running Android below 4.0.



In general, during the development process, problems constantly arose, both on our side and on the server side. Habr has a great team that quickly helped them solve at any time of the day or night, for which many thanks to them.


Comment from WP-developers - esavkin and garifzyanov :

First of all, we would like to thank all users of the WP version who tirelessly send us bugs, comments, suggestions, thanks, swearing and curses. We all write, lay out on the shelves and try to fix it all.



And now a couple of words about the development.



One of the most interesting and challenging tasks we have encountered is the article screen. I wanted to make it as fast and convenient as it is the main, after the tape, part of the application that the user most often works with.



At the design stage, it was assumed that we would succeed, naturally using a bit of magic, to visualize HTML articles through the RichTextBox. But its capabilities turned out to be rather scarce, and we were forced to switch to using WebBrowser, which is very well suited for displaying HTML, but which practically does not allow working with content inside of us and in order to implement the functionality stated in TZ, we had to posttamp markup, add js - events and css-styles.



All work with the elements with which the user interacts, occurs through calls to javascript functions. For example, when a user clicks on a picture, the js-function is called, which sends the code to c # id of the picture, after which the picture is shown by familiar means. The same thing happens when voting for an article, clicking on a spoiler, playing a video.



In the comments, we still decided to use RichTextBox, but there are very different problems. So if you saw the curve layout in the comments, please do not beat us with sticks - we do everything in our power.



In addition to all these joys, we had to maintain the old versions of WP, but on the whole it does not cause much inconvenience. We use familiar approaches: shared files, portable libraries, and other funny words.



Our plans for the future: to realize the wishes of users, to significantly improve the work of the cache, to increase the smoothness of the interfaces and the overall speed of work, to make the application as convenient and functional as possible. It's only the beginning!




Tools and Services



We used various tools for exchanging information and communications during the project.

This is our standard workflow in custom development.



Code storage - Bitbucket

Graphics Storage - Dropbox

Accounting tasks and bugs - Pivotal Tracker

Matching design layouts and sketches - Trello

Accounting for API improvements between CP and TM - Trello

Inhouse Chat - Hipchat

External communication - Skype / Telegram



For analytics inside the application, we used Flurry with a large number of events to assess the relevance of functionality, as well as to track network errors. For realtime statistics implemented Google Analytics. Crashes are collected through Crashlytics (for iOS and Android) and Bugsense (www.bugsense.com).



API development interactions





As the application development process progressed, changes were required to the API. It was also necessary to create easy and convenient requests. For example, during pull-to-refresh, all posts or tapes are not loaded again, but only diff comes. And comments and rating counters are updated via an additional easy query.



The guys from “Habr” showed resilience and attentiveness while working with us, were able to adapt many methods for us and implement not very simple requests. The result was excellent - the API works stably and clearly.



Testing







About 45 (alpha, beta and release candidate) builds were released on each platform during development. Bugs and comments were already introduced at the stage of beta-assemblies, which also fell into the hands of the guys from “TM”. Testing on iOS and Android was facilitated by the support of modern operating systems - iOS 7.0+ and Android 4.0+. In the case of the presence of 2.3+ support, Android would have added about 15 devices to the testing.



Participated in testing:

iOS - 6 smartphones

Android - 27 devices (smartphones and tablets)

WP - 4 smartphones



Under Android, devices are especially loved, on which the behavior of the application can sometimes be very surprising - it's Meizu, Fly and Philips. Be sure to test on all series of Samsung S - S2, S3, S4 and S5 - the most popular devices among active Android users. Well, the Nexus series is also a must - it is popular with Android developers.



Completion of tests meant an approach to the long-awaited release.

A couple of weeks before the release, we also started sending assemblies to the rest of the members of the CleverPumpkin team for gray testing (when the “tester” knows how the application works inside, but does not see the features of the code), as well as assemblies to our friends and acquaintances for black testing. You may be familiar with the terms black box and gray box, we just adapted these methodologies a little for ourselves.



Using the name “Habrahabr” in the App Store and

iOS reject version



The old application “Habra”, which was discussed at the beginning of the article, was published in the App Store under the name “Habrahabr”. The application has long been withdrawn from sale, and after some time Apple independently hides the application from the list in iTunes Connect. Everything was safely forgotten about this, so for almost a month we tried to figure out who took the name “Habrahabr” in the store. After clarifying the circumstances, Apple returned a record of the old application to iTunes Connect, and now the task was to change its name. Only here, when Apple returned, he arbitrarily placed the application in the App Store and for several days it was available to the public. Even the reviews appeared fresh:







You can make changes to the meta-data (application name, description, screenshots) only with updates, and we had the task to place a new application in a new card so that the reviews were clean, so an update of the old version was impossible. I had to create a build with the old Bundle ID (application identifier) ​​and fill it into an old card with a different application name than “Habrahabr”. We chose a straightforward “Habrahabr OLD”, filled the developer stable build and after 5 days passed the review, and the application in the App Store, respectively, did not release to the public store.



Then we successfully changed the name to “Habrahabr” in the new card. So illogical event, but in the end it was a success. We also received confidence that the release version will be easy to review, because we just poured in a stable developer build. But who knew that everything would go wrong, as we had planned ...



On the 4th day after uploading the release version, we get Reject.



18.2. Apps that contain user generated content that is frequently pornographic (ex "Chat Roulette" apps) will be rejected



We can find your app for your display of user-generated content which may become sexually explicit. Therefore, we recommend that you follow the App Store Review Guidelines.



- Use Moderators to remove and inappropriate content

- Require that your users agree to terms (EULA) for objectionable content

- Users need to choose this content

Developer act by by by

- Developer needs a friend of the EULA


Moving away from the shock, we prepared a long explanation about the “Habra” moderators, the presence of two EULA and other things that Apple requires. The next night we get Reject again. Now the reason is trivial - the reviewer could not log in, because it was on this night that “Habr” and many other “TM” projects moved to the new DC, but it was a necessary necessity. It is simply surprising that the reviewer hit exactly those 2 night hours when “Habr” was unavailable.



We inform the reviewer that everything is OK, the server has been restored. We are waiting for the next night, and here “Habra” is changed by SSL-certificates, on the validity of which all interaction with the API is based. The application becomes completely unworkable. Now we get to reload the build and the next 5-day upholding of the queue for review. Hi, heartbleed!



In desperation, I am preparing an Expedited Review application. With confidence that the chances are very small, because we do not have an update for fixing a critical bug and are not tied to any solemn event, send a request. After a day, we get Apple's consent to the Expedited Review! An hour later, the application was already taken in the review and ... you won’t believe it - again the rejection for the same reasons as the very first time. The reviewer, apparently, turned out to be from another team, and he didn’t read, it seems, our correspondence with another reviewer. Again, in real time, in the middle of the night, we have to explain in paragraphs what and how is happening with the content in the application. Well, finally we get a specific indication - add the “Complaint” button for each post.



Thank you for your response. It would be appropriate to implement the reporting mechanism to comply with the Guidelines.


At 2:00 am, manager, iOS developer and designer just do not sleep. Half an hour of work and we have a build with a button for the complaint. Fill the build and wait for the review, and it is still Expedited - that's his advantage, even with the redjack you are still the first in line. After 5 minutes we get the approval of the build, well, finally. Everything is ready for release!



Release



In our opinion, the release was successful. At the time of the announcement (Tuesday 17:00) all applications were already available in stores, and were also easily found by keywords. Habr experienced some problems on the server side related to authorization, but they were fixed by the evening of that day. I started receiving the first feedback to the support box and in Google Play reviews. The information below is April 24th:



The iOS community rated the app in the App Store positively.







Windows Phone users were also very excited about the release.







But Android users reacted quite negatively, including advertising.







In any case, many thanks to all those who provided useful remarks in the support, in the comments to the post about the release of applications and in reviews in stores. This is really important and useful information for all of us. It also seems to me that users expected to see a super-application with mega-functionality ... The expectations of some did not materialize and they rated the application at 1 star. To this I can only quote "Moscow was not built right away."



In the comments of this post, all experts who participated in the development of applications will provide answers to your questions. But I will immediately make a remark: information regarding future functionality and updates will be strictly limited. Well, the release of the iPad version is scheduled for the next week. Expect.



PS Some interesting statistics



iOS devices and firmware


Devices by popularity:

1. iPhone 5 - 30.8%

2. iPhone 5s - 28.8%

3. iPhone 4s - 16.8%

4. iPhone 4 - 9%

...

iPhone 5c - 3.4%



It seems that sales of 5c have failed in Russia.



Android devices and firmware


Devices by popularity:

1. Nexus 5 - 11.1%

2. Nexus 4 - 10.1%

3. Nexus 7 - 6.1%

4. Samsung S3 - 4.4%

5. Samsung S4 - 3%



Here we have a striking difference in devices from the Sports.ru audience - there are nine Samsung'es and one Sony Ericsson in the first ten.



Android 4.4 in 44% of users. There are even 5 sessions with Android 5.





Windows Phone devices and firmware


Devices by popularity:

1. Nokia 920 - 26.5%

2. Nokia 520 - 10.1%

3. Nokia 820 - 8.3%

4. Nokia 925 - 8.2%

5. Nokia 720 - 6.4%



41% of WP users already have Windows Phone 8.1 Developer Preview installed!

On version 7.5, about 10% of users



Distribution of installations between platforms (April 22-28)


Android - 48%

iOS - 41%

WP - 11%



Distribution by country by the number of sessions


iOS



Android





Cities by the number of sessions (the same on all platforms almost)


1. Moscow

2. St. Petersburg

3. Kiev

4. Ekaterinburg

5. Novosibirsk



PPS Now for review in the App Store version 1.1.0 with more loyal advertising. Soon version 2.0.0 with iPad support will be released. Also tomorrow version 1.0.1.0 for Windows Phone is sent for review for various pleasant changes.

Links to the app: iOS | Android | Windows phone

Source: https://habr.com/ru/post/221329/



All Articles