Mobile Software Development: Integration Issues

    Convenient and simple solutions to problems when integrating with server capacities - what to do if there is a task to create two products that would fit perfectly together, provide each other with consistent data and work without failures by themselves.

    With details Egor Taflanidi, Redmadrobot.

    If you do not create a self-sufficient product (and there are actually very few such on mobile platforms), you create a so-called “business” application, usually behind which there is a server that provides relevant data and solves some time-consuming tasks.

    The server / client bundle is so firmly rooted in the mobile development environment that a modern “smart phone” without an Internet connection can simply turn into a brick. Some libraries and frameworks (likeRhoMobile / RhoConnect ) in essence are built around this very server / client integration, leaving it deeply “under the hood”.

    There are many approaches to the implementation of such an architecture (two products that would ideally fit together, provide each other with consistent data, and themselves work smoothly).

    • Development can be entrusted to one person (or to a closely collaborating team sitting in the same room - this is the same thing). He will dock all the necessary nodes and most effectively solve all the problems of integration.
    • You can give the server implementation to your server software development partners.
    • The customer may have its own team of server developers - this is often the case in cases of cooperation with banks.

    Whichever option you choose, unfortunately, often even a clearly defined specification of the server / client interaction protocol cannot provide the correct integration. And you will have a simple, obvious problem: the client and server protocols do not match .

    From the point of view of client development, this leads to the fact that the mobile application receives incorrect data. Or does not receive them at all.
    If the architectural design is not “bulletproof” enough and little time has been allocated for development, the application will “fall”, display rubbish and generally behave ugly.
    Accordingly, the correctness of the feedback is not guaranteed: who said that the serialized data from your application will be adequately recognized on the server?

    How to be

    The first thing that comes to mind is the sneaky decision to fit all the parsers and serializers in the mobile application to what already comes from the server.
    You get some kind of JSON like this:

    	data: {
    		“Field1”: “value1”,
    		“Filed2”: “value2”

    Instead of what is specified in the specification:

    	data: {
    		“Entity”: {
    “Field1”: “value1”,
    			“Filed2”: “value2”

    Valuable information - “ field1 ” and “ field2 ” come as it were. So why not allow a little trick - to read information from what is already provided?
    I already mentioned the keyword “ consistency ”. Literally from English “ consistently execute ” = “ consistently execute ”, in the sense that “ adhere to a given line of behavior ”.

    For example, if initially a phenomenon was called “ phenomenon ”, then it should be called “ phenomenon ” in the documentation , and in the source code should be the class “ Phenomenon ”, and in the incoming JSONs it should have the key “phenomenon ".
    When all project participants use the same glossary, this significantly reduces the risk of misunderstanding.
    Sooner or later, one of the developers can detect a discrepancy in the documentation - and fix it. And on the other side of the system, everything will collapse.
    In addition, based on the documentation already written for the server, other clients can subsequently be created for other mobile and, possibly, desktop platforms - and they will stumble upon the same problems: the implementation does not correspond to the documentation.
    This will lead to the fact that the system begins to grow with crutches and rot from the inside.


    A small service - very simple and quite limited in its functionality, but also attractive. It provides a mock implementation of your API.
    You get a unique URL to which you can set your mobile application. The kit comes with neat documentation for all implemented prototype web services, plus typical responses that should come from these web services.

    For example, you need a server that will render a set of some Entity entities . The list of users, the list of restaurants, the list of ATMs is not important.
    Each entity has its own ID, by which the server should be able to provide detailed information about this entity.
    Plus, the API must separately provide, say, service information - the timestamp field - the time the entity updated with the given ID.

    So, we assume that we have:

    Service 1 :

    • returns a set of entities to a GET request
    • on a POST request returns confirmation of adding a new entity

    Service 2 :

    • on a GET request it gives detailed information about the entity;
    • on an UPDATE query returns confirmation of updating the entity
    (a small caveat: unfortunately, does not allow to implement a full-fledged REST, so it is unlikely that it will be possible to send an updated entity to an UPDATE request).

    Service 3 :

    • on a GET request returns the date of the last update of the entity.


    An example of such a “server” is here .

    Description of mock services is extremely simple and declarative in nature.
    When you create a new mock API, you are immediately provided with an example:

    FORMAT: 1A
    # application
    Notes API is a * short texts saving * service similar to its physical paper presence on your table.
    # Group Notes
    Notes related resources of the ** Notes API **
    ## Notes Collection [/ notes]
    ### List all Notes [GET]
    + Response 200 (application / json)
              "id": 1, "title": "Jogging in park"
            }, {
              "id": 2, "title": "Pick-up posters from post-office"
    ### Create a Note [POST]
    + Request (application / json)
            {"title": "Buy cheese and bread for breakfast." }
    + Response 201 (application / json)
            {"id": 3, "title": "Buy cheese and bread for breakfast." }

    This code describes the operation of a service that responds to GET and POST requests.

    And the service itself can act as a proxy. With a single switch, you can redirect all traffic coming to the breadboard server to the “combat” back-end without changing anything in the client’s source code.

    It would seem that everything is fine, everything is beautiful, the service allows the team to work without blocking the process, provides a convenient scripting language ...
    The problem is that, alas, it does not have a special logic.
    You can simulate the return of an entity depending on its ID, but in any case it will be a finite state machine that is not able to analyze the situation in any way - it has a slightly different purpose.
    If you need to dig a little deeper - it does not matter. There is always an old, proven Soap UI.

    SoapUI is a multi-tasking combine, originally designed and aimed at testing SOAP and REST services in automatic mode. Among other things, he himself can act as the appropriate server and provide breadboard data.

    Instructions for action:
    We create a project and cut out everything superfluous from it.

    Create a new mock REST service.

    Add action.

    Let it return an Entities list.

    Add mock data.

    Let the service return this list only by the presence of an authorization key.

    We add the answer for the “unauthorized” user. We

    switch the Dispatch mode to the “SCRIPT” state and copy one of the given examples of checking the request parameters.

    We start it (after checking the port in the service settings; by default - 8080). We


    everything, the mock server is ready.


    Naturally, the above service is not the only one, and there are a number of its analogues, such as , which provide similar functionality.
    Alas, most of these solutions usually lack the flexibility to implement a full-fledged response to possible network requests.
    There are not so many really functional and convenient services for creating mock APIs.
    On the other hand, the simplicity of such solutions ensures their relatively rapid deployment, and at some stage of the project, this can be a decisive factor.
    So, may well be involved in creating a prototype or proof-of-concept-solution, and as the project evolves, you can already think about the subsequent move to more advanced services with logic, scripts ...
    And there you look - the battle server is already ready.

    A separate article, of course, is the BAAS server, but this is a slightly different story.

    How do you solve integration problems?

    Also popular now: