📜 ⬆️ ⬇️

Impressions of working with the Mamba.Ru application platform

In this post, I will share the experiences and problems that we encountered while working with the Mamba application platform.

Platform Description

The Mamba application platform is a pretty young product. We started writing applications for it at the end of last year. I cannot give details on finance, specific examples, figures, because I have no right. I will only talk about some technical details that I hope will be useful primarily for programmers.

games and apps

Mamba is trying to create a certain line between applications and games, although the situation here is quite interesting. In my opinion, somewhere before the beginning of 2012, games were generally banned as such. Any application should, according to the rules of placement (if it is not intended for dating), one way or another to facilitate the familiarity of users. In clause 4 of the FAQ there is a reservation that they do not want to make the game portal, but under certain circumstances the game application may be allowed.

The game section appeared quite “sharply” and immediately with a lot of games. Moreover, most gaming applications do not even think to introduce users. Apparently, this is some kind of agreement between the game manufacturers and the mamba; I cannot explain these tricks in any other way.
')
API and interaction with Mamba

With a few exceptions, I was pleased with the API provided. Everything is quite logical and understandable.

The first request when a user enters the application is determined by the presence of corresponding variables in the GET parameters. It is advisable to save them all into the session, because later on navigating through the pages (we did not have a flash application) you will need sid - the session ID and oid - the unique user ID in mamba. Without the first, access to most of the API functions is impossible.

Try at least sometimes with an Ajax to “pull” your application so that the session does not expire. It is clear that everything depends on the session settings, but if you lose the user, you can “resurrect” him only by inviting him to press F5.

After the first call, the sid-key is valid for four hours. But the trick is that the documentation says, “The SID key is relevant for 4 hours since the last request to the server!”. So - this is all not true. It is relevant 4 hours from the time of generation. That is, if the user has logged into the application, then he will be able to stay there for a maximum of 4 hours. Then all api-calls will be cursed and you will have to ask the user to press F5, since it is impossible to get a new key in a different way.

Be prepared for the fact that some parts of the API can stop working completely independently of each other. Sometimes they fall, and we had cases when photos were not given in 1 request from 5. We press F5, and we occasionally receive empty data. As if there are no photos of a person.

The next problem is changing your user data. In order not to twitch the API often, we are somehow forced to store some information (link to the photo, name, age) in our office. But to find out whether it has changed since the last call, unfortunately, is impossible. I will not give advice - for each application it is individual. But I will say only that the pictures change often enough, especially for girls.

It is very useful to have a flag - whether the application is installed by the user and periodically (preferably at night) to check whether the user has deleted it. Since it makes no sense to send such users any notifications.

The signature generation described on this page works in principle. But remember that $ request_params should not contain empty values. We just have all the appeal to the API was issued in the form of a class with fields - request parameters. And for server-to-server requests (for example, console cron-tasks for sending notifications) the sig field was NULL as not filled, but it was actually iterated like all other fields when generating a signature. It is clear that this is our cant, but I was looking for the place of the error for a long time.

Be careful with the URLs of the application. We accidentally left a redirect from a regular domain to www, and therefore the JS-API did not work, because in the settings of the application there were addresses without www.

Secret URL for payment - "URL handler billing." This is really magic. Nowhere in the documentation you will find exactly how your script should respond to incoming requests from the mamba when a payment is received. So know that this is described in the section Server response format . Yes, here we are talking about your server. In addition, regardless of what your script returned, the money will still be credited (I'm not sure that always, but it happened) - this is bad because the user will not see his money in your application and will be distressed.

Previously, it was necessary to write app_id in the JS-API directly in the body of the js-scripts that invoke the recharge dialogs. Now this is not there, but until that moment it strained, since there were two applications - one test and one combat, and we sometimes forgot to change this figure.

Another fun moment that Mamba reserved for developers: keep in mind that all test (unpublished) applications will be perfectly visible in your profile. The achievement board will also contain entries from these apps. Trifle, as they say, but unpleasant.

When querying the server-server (that is, outside the user session) do not forget to set secure = 1, otherwise it will not work.

Sending messages to the user - just clarify. Messages can be sent with an active session, or not having one. In the first case, messages can be sent on behalf of the current user only to those who are in his contact list. To do this, use the contacts.sendMessage method. In the second case, use notify.sendMessage . But there are two points: daily_balance , which returns the rest of the messages, has never changed in my memory and most likely is just a constant. Maybe then they will fix it. And keep in mind that notifications do not reach immediately and not all.

Best of all data profiles Mamba (if you need to save it completely) stored in Mongo. It is just perfect for storing huge nested arrays .

Browsers

IE freaks out as usual. In particular, sessions may not work in frames, and not always, but only at certain points in time. Some wonderful title helps.

If you have a test application that runs on a domain like my-app.local, then you need to enable “Allow Cross Network Navigation” in the opera.

Aggressively configured adblock can block and not show the contents of the frame, so add the address of the page with the application to the exceptions.

Get ready for problems with safaris on iOS and iPad. By default, cookies are not stored inside the frame. In fact, this is a privacy policy, and there is no way around it. The only way out is to determine that the cookie has not been set and redirect the user to a special page where to explain how to change the security policy. This question only concerns the case if you need sessions in your application.

General remarks

Moderation is fast enough. But moderation may be refused on the grounds that the application is not filled with real people. That is, before moderation we have to fill it with at least ten questionnaires, but nobody says where to get so many SIM cards. There are no developer accounts. They are basically absent as a class. The difficulty is to create such type of accounts that should not be tied to the phone, but they were allowed to go only to certain applications - I do not see. Apparently Mamba has not yet matured.

But at the same time, it is possible in some countries to register questionnaires without confirmation of the phone. It is clear that they will have some restrictions in foreign regions, but knowing the list of such countries, you can easily register registration forms and perform various kinds of cheats if your application allows it (bonuses for invited friends, free periodic bonuses, and so on). Be careful with such things. If necessary, it is possible to completely cut off users who have not confirmed the phone from the application (the is_real flag in the anketa.getFlags method will be equal to 0).

Keep in mind that any technical assistance is very difficult to obtain. You will have to delve into any mistakes and incomprehensibility yourself, there is not even the simplest forum where you can ask a question. You can get to the developers, but it is very long and not the fact that the answer will suit you.

Recently, an even more interesting thing happened. The part of the questionnaire and the structure of the information in it were completely changed. The block “Interests” appeared. And with all this, through the API to get new data is impossible. They simply do not.

Well, remember that the most important thing at the beginning is the number of installations. Therefore, in the first stage, you can even forget about earnings, and increase the number of new users. To do this, use different bonuses for friends listed in the app. In order for you not to be forgotten - use the achievements board and bonuses for adding the application to your favorites (this is easy to check by API). Well, log everything. Get a separate database with signs for different logs and record all user actions. In the future it will be easier to figure out what happened and how this could have been avoided.

UPD: thanks to all who voted, but this post does not pretend to the application development manual. The simplest application can be done in one evening by carefully reading the documentation. Here are the pitfalls that you will learn about only when you come across this directly. And I hope that this post will help you avoid these stones.

Post written in collaboration with ZaiSL

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


All Articles