📜 ⬆️ ⬇️

Fiction from students or how to collect cross-platform social geolocator

Hello!
Today I want to talk about a good experience that we have in high school.
I have been teaching for almost 5 years, and this year we went on an experiment. We (the teachers) decided to introduce as an element of the assessment of course work on the subject - “public censure”. Those. students write a post for Habr on the topic of coursework, and we follow the responses and public discussion. However, this assessment will not go to the minus (we should encourage our “valuable personnel”), however, it may not go as a plus (if public censure reaches its apogee). In general, the judges here are experts and users of habr. And it seems to me that this experience is useful for students - they will understand more deeply the problems of their work.
So, the first candidates: 3rd year students. Coursework in the discipline "Computer Graphics" (yes, we can also take interesting developments on this subject). At once I will make a reservation that we are preparing engineers, not programmers. Although our department already has 15 people working at Yandex in various positions. And very successfully. All project sources and links are below.

Here, in fact, the article itself (almost without revisions):

The idea of ​​this service came to one of us suddenly, when there was a question about the idea of ​​a term paper. We already had experience in creating a purely mobile application, under Android OS, but after looking at the zoo of phone and OS manufacturers we decided to try something new and we did it! The main essence of the project - the user in 3-4 clicks chooses what he wants to visit, selection criteria (price, availability) and method of movement, and the application shows which places correspond to his criteria and plots routes.

About the service


The main audience of the service is lazy people, young people and people leading an active lifestyle and having accounts in social networks or / and having a telephone with Internet access.
')
The main goal, from the very beginning, was to create a working mobile version and a PC version, and then the idea came to try myself in the iframe for social networks.

Having reviewed a couple of applications for phones and their mobile versions, we developed common service concepts:


As well as the main functionality, the rest is already like features:


And we started doing it!

About development


Scheme of service
image

Choosing a topic and endorsing it, we began with a plan and a search for development tools.

First of all, we needed a map, THIS IS A GEO SERVICE! We considered two platforms for maps - YandexCards and GoogleMaps, the second one was dropped immediately because of its bourgeois origin, bad maps of Russia and incomprehensible policy towards developers. We are not disappointed in the choice.

The beginning of our plan consisted of pumping up the skill in web development and a smooth transition to performing functions - before that none of us were actively engaged in web development. Having come to the fact that the first mobile and PC versions, curves and crutches, can be rolled out in November, we distributed the duties: one - layout and js, php, another - php, YandexApi, mongodb. In the future, these responsibilities are not particularly respected.

For the role of subd, we had two options: mongodb or mysql. We needed speed and ease of scalability. Mongodb was more convenient and easier to use, especially since one of us had experience working with it. By the way, a separate article is devoted to our comparison of mongodb and mysql, which will be published a little later.

At the very beginning we had a question: under which mobile browser to make a mobile version? The choice fell on opera mobile, because of its prevalence on old phones and availability. But later it turned out that it does not support the js api Yandex maps part.

As you know, there are two versions of opera for mobile devices - opera mini and opera mobile. On their differences, you can read the section on of the site .

About the coarseness of the coordinates


The coordinates are determined by js, he knows how to do it according to the standard and without loading the libraries, but sometimes there were funny moments: sitting at home from the hospital through a router or in a cafe from a laptop, the service determined that the user is in the very center of Moscow, and specifically in Alexandrovsky the garden. If you enter from a mobile phone through 3g, there will be a very large spread, in a house and a half. And also because of the browser settings, the service sometimes did not find the user. To fix these jambs, we introduced the function of manually entering the address when the coordinates were not determined successfully.

About the problems that we have with opera.

After downloading to the hosting version for PC, the development of a version for mobile phones began. After creating the mobile version, uploading it to the hosting and launching it in the opera, we were pleasantly surprised that the opera does not support part of js, we discovered this with android samsung GT-S5830 and on simbian. At the first test of the mobile version - the route was not displayed on the map, although if the same mobile chrome - everything draws.

Pro Parsers


With parsers we filled the database with information on cinemas and museums. The main task is the implementation of the parser, which will spin on the CRON and update our database (once a day). The parser consisted of regulars, standard php functions and libraries ... for working with DOM and ..., which is used to translate a text address into geographic coordinates. You can see the implementation of both parsers here.

About apivk and mailapi


We had no experience in developing an iframe for social networks, but after trying it, we realized that vk has a very strange api, namely two versions and few examples, whether they were too lazy or decided that it was not appropriate yet, but this is sad. In contrast, mail.ru api has many examples and good documentation.

About algorithms


When developing the service, we used several algorithms for issuing the nearest objects on the map, for museums and cinemas, as well as for user events, which are based mainly on requests to the database.
For example: to search for the 5 nearest cinemas we use the query mongod db.cinemas.find ({“geo”: {$ near: [x, y]}}). Limit (5), initially setting up the indexing in the database using the db command. cinemas.ensureIndex ({“geo”: “2d”, type: 1}).

activity


Our events are designed for sharing time, therefore we issue the nearest events within a radius of 2 km. After the event ends, it is automatically deleted from the database.

Events in our service cannot be compared with foursquare events, because in foursquare people just tinker, and we, as written above, “tickle” with the expectation of spending time together, and also we collect more detailed information, and not just the nickname of the user and its place, namely: the user's contacts, the name of the event, the date of the event, as well as for advanced events, you can specify the url of the site.

Development problems


About two months we worked and tested locally, but soon there was a need for hosting, we could not find a suitable hoster with a working mongodb for a long time, as a result we found it, a link to it is lower.

We had to abandon samopisny xmlrequest, due to the fact that mobile browsers may not support this technology in full.
What we used when developing

git
phpshtorm
eclipse
mongodb
YandexAPI

Links


Hosting: https://locum.ru/
Differences of opera mobile from opera mini http://www.opera.com/mobile/specs/
Http://twitter.github.com/bootstrap/index.html framework
Sources https://bitbucket.org/ziganzigan/habrcode
mail js API
VK api

Page of the project itself .

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


All Articles