Technical aspects of developing an ios application for the portal AllCafe.ru

If you are working on a project with a large attendance and content, partly (or completely) formed by users - then, most likely, you already thought that it would be nice to make a mobile client. So we, working on our project, decided that users would be more willing to use our project and more actively create new content. Besides - we can make life easier for the user, so why not.
And we did. Caution, a lot of pictures and text.

The most popular mobile platforms in Russia, at the moment - iOS and Android. We decided to write first for the iPhone.

Usage scenario

So, there is a portal with a huge base of restaurants, bars and cafes, accumulated over its long life. In addition to the restaurant database there is a huge amount of feedback about them.
')
Have you ever been in a situation where, having come to an institution with friends, did you find that there are no places, or noisy, or smoky, or for some other reason, today it does not suit you? Personally, my colleagues and I have been in such situations. The first thing you think about - is there anywhere near the institution where you can spend the evening? We decided to help the user in this situation.

Began to think about user interaction and applications. Began to throw some interface circuit.

Implementation

Made an API for communicating the application with the portal database. To save traffic, to load data faster, and because the data in the database is stored in this form, we decided to transfer them to JSON. Then iOS 5 has not yet come out, in which public tools appeared to work with JSON, therefore they took the json-framework .

To navigate in the application, we used UINavigationController along with UITabBarController. While studying the issue of sharing them in the application, we came to two options:

1. UINavigationController inside UITabBarController - each ViewController inside UITabBarController allows you to "go deeper" further, but all this within a specific tab. This principle works Dropbox client for iPhone. A schematic example in the video.
2. UITabBarController inside UINavigationController - we see visually the same thing as in the first case, but the “deepening” of the view takes place inside the application itself. According to this principle, the VKontakte client for iPhone works. A schematic example in the video.

We liked the second option more, we used it. The description of the implementation of both options is slightly beyond the scope of this post, so if anyone is interested - write in a personal, give a link to the description + examples (in a personal - in order to avoid habraeffekt).

So, we started with help in the situation described above - what is next. The first thing that the user sees when launching the application (after the boot screen, of course) is the map. The script is simple:

• application launch;
• user location;
• loading of institutions whose coordinates are inside the visible (on the screen) area (bounding box);
• display of labels on the map.

In our project CouchDB is used as a database. To select restaurants within the application window, use the search on the bounding box along with the geocouch module. The application passes the window borders to the API, and the database selects the institutions in this “rectangle”. All other queries in the database use the standard document-oriented database structure. For example, when adding reviews, we create additional fields in the document that make it easy to find reviews left from a specific device, etc. We receive coordinates for the institutions from the Yandex.Maps geocoder. Google’s application is currently used in the application (built-in framework MapKit), but In the near future (after a stable release), we plan to switch to using Yandex.Map, especially since their cities in Russia are much more complete.

Result on the screenshot:


The data is loaded using a normal asynchronous request via NSURLConnection, so as not to block the user interface for this time.

The second screen is the places whose labels at the moment managed to be loaded on the map, only in the form of a list and with a distance to them. What pleased me - in Objective-C, the CLLocation class has a built-in distanceFromLocation method for determining the distance between two points on the map (I personally, fluently, did not burn with the desire to calculate the formulas I was given in the results). It is clear that this calculation does not take into account the fact that you need to move not along a straight line, but along roads / junctions, the value is not the exact length of the route from the current place to the institution, and determining the user's coordinates may give an error or not have time to determine his location . But, nevertheless, this information can be useful and play a decisive role, especially if it happens in the freezing winter and you want to quickly reach / run. Or you have a Friday :)



The screen with information about the restaurant / bar contains brief information about the restaurant, news and user feedback from the portal. Of course - every review or news can be opened and read. The text of the news / feedback is also uploaded from the portal via the API and output via the UIWebView — on the portal, you can insert images / photos into reviews, you also want them to be visible to users of the application.

Feedback from the application

Of course, we wanted users to write a review directly from the app. Sit, you, for example, in a famous restaurant - and you do not carry coffee for 40 minutes. We got an application - wrote a negative review about the place (believe me, restaurant managers read reviews and take them into account).

Writing a review, in order not to litter a rather limited screen of the phone, it was decided to split it into 3 screens:

• writing review text + attaching photos;
• information about the visit (date / type of service / assessment);
• recommendations and adding the review itself.

After adding a review - it is added to the site database, therefore it is visible to both portal users and users of the mobile application. Adding photos is also done through the API using a PUT request.

App Store

Of course, each such story should contain a part about how the cones were stuffed from the App Store.
We sent the first version of the application to the App Store in early October. She got there from the 3rd time, each attempt took about a week. Twice we were refused, and, probably, for the same reasons as all applications tied to geolocation.

The first failure: they asked for a demo video, because The reviewers did not understand how the application works, but for some reason we did not foresee this situation. They launched the application, the map opened somewhere in the states. And that's all. Since the base of restaurants and bars, ours contains only information on the cities of Russia and Estonia - they did not see anything more either on the map or on the list. We recorded the video, sent the application to the review again.

The second failure: we have chosen the availability of the application worldwide, and it fully works only in Russia and Estonia. A week down the drain, chose the right countries and sent again. From the 3rd attempt the application passed a review.

Now we have already planned quite a large amount of work on the application. There is room to grow, to strive for, and indeed we are only at the beginning of the road. By a strange coincidence, this is only for iOS 5 (one more of our oversight), but this week we hope to post a version with support for version 4.

The application weighs only 200 kilobytes, if it became interesting to you - we will be glad to see you among our users: a link to the application .