Switching from Google Maps to Yandex MapKit

Recently I happened to transfer the application from using the Google Maps API v1 to Yandex MapKit .

According to the subjective opinion of the majority of Yandex maps for Russia have higher detail, and therefore, if your application is focused only on Russia or ex-USSR and Turkey (in general, those countries where Yandex is), then it makes sense to consider using MapKit.

The application has the following functionality: a map with points of objects on it and the ability to search for these points by address, displaying the current location and zoom. For each point, you can tap and see a pop-up balloon containing additional information about the point. When taping on a separate balloon, a new activity opens with detailed information about this point and a piece of map that displays only this one single point.


Let's start ... We go to github and pick up the library from there. If you thought that since the library is distributed through GitHub, then it is OpenSource, then here you will find disappointment. The library is distributed as Android Library Project + jar-файлwith a bunch of obfuscated classes, which lies in daddylibs. There are no sources, therefore, to look inside and understand that we can’t work, and sometimes I really want to, because the documentation (in the library folder javadoc) is, to put it mildly, bad: the description of the existing API is minimal, and many methods are not documented at all. Therefore, the project lying next to the sample library is very useful.

By the way, do not be alarmed by the abundance of open tasks on the github. These are not necessarily bugs - this is such a way to ask a question in the community about using the library. There is no forum or separate place for such questions. Have a question? Create issue!

To obtain the key, you must send a request to those. Yandex support, and until it was issued to debugus, you can use a key of the form as a key1234567890(Thanks to the sample project, not a word in the documentation about this). Speaking of keys, the first surprise awaits us here: it MapViewdoesn’t read the key from the resource file, so if you have several layouts inside it MapView, you will have to copy the key to each of them MapView, put it into the configuration file and can @string/api_keynot be accessed through it . This riddle took me a lot of time, the corresponding task was created a long time ago, but as you can see, the situation has not changed in 3 months. In general, the reaction speed of Yandex support is scary.

So, after receiving any, the first thing it was decided to collect a sample-project and play with it. The repository contains the Eclipse files of the project, I use IntelliJ IDEA, so the first thing was to create and configure the project from existing sources. There was a surprise here - until now I still didn’t fully understand what was the matter, but the situation was as follows: the project was normally compiled and packaged into apk, but then in runtime, when trying to switch to any of the activities, it fell with an error string resource not found(the literal text of the error is now not remember). There is an empty Rstub file in the library files , I’m risking to suggest that the problem was that IDEA for some reason in the finalapk-file was packing it precisely, which led to further errors. The problem was solved by removing the library module from the sample-project dependencies and adding it again.

It would seem that both libraries have a similar API and the transition should not take too much time: both there and there MapView, and there MapController, and there and there GeoPoint... But the similarities end there. Despite the same class names, methods are named differently and not for every method from the Google API there is a direct analogue of it from MapKit. For example, in MapKit there is no method that allows you to get the coordinates of the ViewPort(visible area of ​​the map), so you have to implement it yourself - by converting screen ( ScreenPoint) coordinates to global ( GeoPoint) - thousand. Screen coordinates need to be counted not relative to the screen, but relative to itself MapView.

In Google Maps, a balloon (floating view with tap on a point) one element along with the point itself, in MapKit it is a separate object. Therefore, the logic of working with balloons will have to be rewritten almost completely.

In Google, the API GeoPointstores coordinates in the form of a pair of int's - this is longitude / latutude * 1E6, for Yandex it is doublelongitude and latitude. On the one hand, the use of int's instead of double' s allows you to save a couple of bytes of memory and speed up calculations related to coordinates (integer operations are always faster than floating-point operations). With Durga hand, this kind of code constructs floods: *1E6,/1E6. In general, here I put a plus to Yandex, 1E6it’s more convenient to work with the API without constant multiplications / divisions , and the ratio of convenience to performance gain, in my opinion, is not great in this situation.

Another challenge was the unpredictable behavior of theBalloon s. The fact is that from time to time the opened balloons are displayed under other OverlayItem's and are blocked. At the same time, the method setPrioritythat all the elements displayed on the map have no effect. As it turned out later, the reason for not overriding the method correctlycompareTo. This method is used when showing a balloon to sort objects in the z-plane. Neither the documentation nor the example contains any information about this problem; this dependence was generally established quite by accident during the experiments.

And finally, another significant difference between Yandex MapKit and Google Maps is that MapKit does not support direct geocoding, only the opposite. Those. the library provides a way to translate geographic coordinates (lat / long) into an address or place name (see class GeoCode). But in the opposite direction - the street or city does not know how to coordinate, so direct geocoding will have to be implemented independently, for example, using the same Yandex Maps Web API . Google can do this in both directions at once.

In conclusion, I would like to say that in general, the impression of using Yandex Maps is positive, the API is quite convenient, the capabilities for my tasks turned out to be enough, but the main minus is the documentation. We hope that Yandex will nevertheless put everything in order.