Mobile Client Server Development

    The reverse side of mobile clients is the server.

    Introduction

    I’ll not tell you a secret that the development of mobile applications in a trend is facilitated by rapid technological development: mobile devices improve every year in all respects and become more accessible to a wide range of people. Almost everyone who has a mobile gadget in their hands (be it a smartphone, communicator or tablet) uses applications: a browser, an email and instant messaging client, games, business or financial programs. And often it’s hidden from users that many of the applications interact with a remote server: they exchange data with it via the Internet.
    By type of activity (Java server application developer), I have to develop servers for mobile clients in my team (over the past 2 years I participated in the implementation of 3 such projects for foreign companies). A set of Java technologies has been identified for solving problems of this kind, which varies depending on requirements and expediency (in other words, desires), since freedom in choosing technologies allows you to experiment. I would like to share the formed point of view and experience with the community.

    Requirements

    The peculiarity is that the requirements are formed for both the server and client applications, which in some cases are interconnected. To begin, I will describe the basic requirements in the context of the data exchange mechanism:
    • cross-platform client: it is often important to provide support for different platforms - Android, iOS, Windows Phone, etc. Rarely, the customer is satisfied with one type of device.
    • speed: sufficient work speed should be provided for the workflow, a comfortable response on the graphical user interface;
    • simplicity: the simpler the API of the protocol, the less time it takes to implement and maintain the code, the less can be the qualification of the developer;
    • Efficiency: the more complex the implementation of the protocol, the more resources of the mobile device that are limited are consumed.

    Additional requirements depend on the specifics of the application:
    • server scalability - for SaaS, social applications, where ideally a large flow of visitors is expected, this condition is mandatory. For business applications where there are restrictions on the number of users or the number is predicted, this property is not required;
    • interactivity: a number of applications need to be provided with a notification mechanism - inform the application (user) about the occurrence of certain events, send a message to the user. For example, an exchange system or an automatic taxi dispatcher should have this property.
    • open API: it is assumed that third-party developers can take advantage of the system’s functionality through a documented protocol. After all, the client can be both a mobile and an external server application.
    • other requirements ...

    Command

    The composition of the project team for developing the system could ideally be as follows:
    • project manager: manages, controls the project, interacts directly with the customer;
    • server application developer: develops a business logic server, database, network protocol;
    • administrator application developer: develops a Web application, a user interface for configuring and managing the server application;
    • developer of a client application for Android;
    • developer of a client application for iOS;
    • client application developer for ...
    • tester: tests the administrator application and client applications.

    An attentive reader will notice that if you write a server application with a graphical interface, for example, in HTML5, you can save. In this case, the development of client applications is not required - the user interface provides a browser. This article does not consider such a case, it is a question of developing “native” applications for mobile devices.

    I have worked in a team with a full complement, but it will be realistic - not always human resources and the budget allows me to assemble such a team. And sometimes roles have to be combined: project manager + server application developer, client application developer + tester.

    Technologies, tools, libraries

    To develop a mobile client server I usually use the following stack of “free” technologies:
    Apache Tomcat - servlet container;
    MySQL - DBMS;
    Subversion - version control system;
    Maven - a framework for automating the assembly of projects;
    JUnit - will ensure the effectiveness of automated testing of applications ;
    Apache Log4j - logging library;
    Jenkins - a system of continuous integration;
    Hibernate - ORM (settings, configuration in properties, xml files and annotations);
    hibernate-generic-dao - Google’s DAO implementation, implements the basic methods for working with database data, simplifies filtering and sorting in methods;
    Spring - implementation of authentication and authorization (security), a container of services and beans (configuration in xml files and in annotations), we also use it when creating tests.

    Depending on the specifics of the system and the requirements for it, I use one of the 2 options for implementing a data exchange protocol.
    When cross-platform, performance, simplicity, efficiency, scalability, open API are required, then I take Jersey- implementation of RESTful Web services (RESTful Web services). This library allows you to use serialization of data in JSON or (and) XML format. REST configuration is done through annotations. For the exchange with mobile devices, the JSON format was taken because it has a simpler implementation on the client side (for this reason we do not use “classic” Web services), less traffic is generated. Jersey allows you to tune in to the most appropriate “look” JSON.
    Otherwise, if you need cross-platform, high-speed, simplicity, efficiency, interactivity, then I take
    Apache MINA - framework for creating network applications,
    Google protobuf- A library for encoding and decoding structured data. The data structure is determined by * .proto header files, the compiler generates Java classes from them (there is also the possibility of generation for other programming languages: C ++, Objective-C, etc., which provides the cross-platform property);
    • java.util.concurrent - use the standard package.
    This option can be scaled, but it needs to be laid at the design stage at the architecture level, given the business logic.

    Consider a hypothetical task on the example of the choice of technologies for a real SaaS service - “Auknem” service auction, which allows people to form an order to perform the required services or work, and organizations, in turn, leave their proposals for them. We take all the basic requirements by default. Due to the fact that registration in this system is free and free, it is definitely necessary to add scalability to them. And what about interactivity? It would be great to inform contractors (performers) of the creation of new orders, and to inform customers of proposals received at the same time in the application, and not just by email. Based on this, we take for implementation Apache MINA, Google protobuf. We look at the following property - open API. The service is publicly available, so suppose that external developers may be interested in integrating with it. Wait a minute! Not so simple. The protocol based on Apache MINA is quite dependent on the implementation and integration without knowledge of the nuances is far from transparent. In such a situation, you have to weigh which factor is more important and make a choice.

    Conclusion

    I would be interested to know what technologies and libraries you used in developing a mobile device server or similar systems? Everything changes, nothing lasts forever, at each level there are alternatives with their advantages and disadvantages: MySQL - PostgreSQL , Subversion - Git , Apache Tomcat - Jetty , Apache MINA - Netty ...

    Also popular now: