Moving from Google Maps to Yandex MapKit

Recently it was possible to translate the application from the use of 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 Rosiiu or ex-USSR and Turkey (in general, in those countries where Yandex is available), 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 tapes on a separate balloon opens a new activit with detailed information about this point and a piece of the map that displays only this single point.

')
Let's begin ... We go on github and we take away library from there. If you thought that if the library is distributed through GitHub, then it is OpenSource, then you will be disappointed. The library is distributed as an Android Library Project + jar- with a bunch of obfuscated classes, which lies in the libs . There is no source code, therefore, to look inside and understand that we cannot work, and sometimes we really want to, because the documentation (in the folder with the library is javadoc ) is 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, don't be intimidated by the abundance of open tasks on the githaba. These are not necessarily bugs - this is the way to ask the community about the use of the library. There is no forum or separate place for such issues. Have a question? Create an issue!

To obtain the key, you must send a request to those. Yandex support, and as long as it was not given to us, you can use a key like 1234567890 as a debug key (thanks to the sample project, not a word in the documentation). MapView of keys, the first surprise awaits us here: MapView does not read the key from the resource file, so if you have several layouts containing inside MapView , you will have to copy the key to each MapView , MapView it to the configuration file and access it via @string/api_key will fail . This riddle took a lot of time from me, the corresponding task was created a long time ago, but as you can see, in 3 months the situation has not changed. In general, the reaction rate of Yandex support is scary.

So, after getting it, first of all it was decided to collect a sample-project and play with it. The Eclipse project files are in the repository, I use IntelliJ IDEA, so the first step was to create and configure the project from existing sources. There was a surprise waiting here - I didn’t understand until the end what was the matter, but the situation was as follows: the project compiled normally and packaged in apk , but then at runtime, when trying to switch to any of the activites, it fell with a string resource not found error ( the literal text of the error now I do not remember). There is an empty R file in the library files, I would venture to suggest that the problem was that IDEA, for some reason, packed it into the final apk file, which led to further errors. The problem was solved by removing the library module from the sample-project dependencies and re-adding it.

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

On Google Maps, a balloon (pop up a twist at tap on a point) has one element along with the point itself, in MapKit it is a separate object. Therefore, the logic of work with balloons will have to be rewritten almost completely.

In the Google API, GeoPoint stores the coordinates as a pair of int 's - this is longitude / latutude * 1E6 , for Yandex it is double longitude and latitude. On the one hand, using int 's instead of double ' s can save a couple of bytes of memory and speed up calculations related to coordinates (integer operations are always faster than floating point operations). On the other hand, this floods the code with constructions of the form: *1E6 , /1E6 . In general, here I put the plus sign on Yandex, without constant multiplications / divisions by 1E6 with the API, it is more convenient to work, and the ratio of convenience to gain in performance, in my opinion, is not great in this situation.

Another difficulty was the unpredictable behavior of Balloon 's. The fact is that from time to time openable balloons are displayed under other OverlayItem 's and turn out to be blocked. At the same time, the setPriority method, which all elements displayed on the map have no effect on. As it turned out, the reason for the compareTo redefinition of the compareTo method. This method is used when displaying a balloon to sort objects in the z-plane. Neither the documentation nor the example contain any information about this problem, this dependence was generally established quite by chance during the experiments.

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

In conclusion, I would like to say that, in general, the impression of using Yandex Maps is positive, the API is quite convenient, there were enough opportunities for my tasks, but the main drawback is documentation. Let's hope that Yandex will put everything in order after all.