Using Location API to create Chat and other services

Posted on by Nate Macleitch

Hi guys!

We would like to share the information with you on how to create Chat and other services using Location API.

1. How it works

It should be noted that QuickBlox geo service provides wide functionality, which can be used for creating, retrieving and removing the data as well as sorting and requesting the data in the required format. This service is completely integrated into our infrastructure and it provides the ability to transfer string data using field Status. The only thing to remember is that you should consider the limit of 1000 symbols.

As for other systems a lot of them can operate only with string fields in the DB and sometimes it is necessary to use text transfer protocol only. Despite all of this, the problems of transferring, for example, binary code through network or saving it into DB exist. In this case client and server are exchanging text messages that are wrapped into XML or JSON. Since an object itself is presented as markup then we get a message that contains markup in the markup. The target object is an unsafe message, since it is determined by a programmer on the client’s side (recipient), unlike a message that is strictly structured and uses the SDK libraries. If a fail occurs in the structure of the target object, the entire message won’t be correct and won’t pass the validation process. Additionally the message itself can be checked for inappropriate content, including XML.

2. Using additional services based on QuickBlox

Using GeoData you can create additional services: public chat (bulletin board), POI or private chat with certain users. All of these capabilities are based on two things – availability of the Status field and use of base64. In our case, we come across two obstacles at once. First of all, services are connected through text transfer protocol (http) using REST technology. When standard http request is sent to the server, we will get a response with a header and a body of an object that has been requested (only in cases when it is provided in a response). GeoData is a response (with XML structure) that has a Status field.

Request and response have string data. Response is sent in XML format, which means the storing of XML in the Status field is not allowed. Furthermore validator will not allow this. In this case there is no need to transfer the binary data, but you still can use it, for example, for small icons, avatar, labels! To solve this and other problems the encoding base64 can be used. We can use encoding for storing, transferring or fetching the data.

Base64 allows presenting any object as unique text string. Thus we use HTTP protocol as transport protocol. It is quite logical since it acts the same way for other protocols of application layer, for example, SOAP (web-services, windows communication foundation) and REST.

3. Wrapping Chat or other data in base64

How to create additional service:

1. We need to use the SDK for our platform. It will give us the ability to operate with GeoData like with object. We use GeoData because it has string field Status that isn’t strictly validated. QuickBlox is a type of Web services that works like REST, by http protocol. It means that requests are sent using form fields and server responses are come in XML.

2. It is necessary to define the required additional functionality. After this we will be able to build the appropriate structure for an object.

Structure is a message. It can be specified with type and parameters. To do this we enter the field <t>, that is indicates type of a message (1 – location, 2 – public chat, 3 – private chat).

<t> Type of a message (INT) (1- location, 2- chat etс.)</t>
<to> Destination (for private chat)</to>
<from> Author (for both types of chat)</from>
<text> Message text</text>

3. Creating tools for creating and encoding the messages.

  • Create a message (following the scheme above)
  • Encode this message into base64
  • Create GeoData object
  • Add your base64 message to the GeoData Status field
  • Send it to the server

4. Creating tools for obtaining required messages. General principle – take all GeoData objects, extract messages, decode them, sort and choose the ones which are needed (for example by type or recipient).

4. Recommendations on how to process data

There is a problem here – considerable resources and time are required. We can solve this problem either by using а background mode of GeoData loading that is provided in the SDK (only in Windows Mobile version right now) or ping the server periodically, collect the data, cache it and use only last data pages.

Here is a screenshot of the Dane Cook app which is already using this method to power its Map+Chat feature:


We hope this information was helpful for you!