The downside of mobile clients is a server.Introduction
I will not reveal the secret that the development of mobile applications in a trend - this is facilitated by the rapid technical development: mobile devices improve every year in all characteristics and become more accessible for a wide range of people. Almost everyone who has a mobile gadget on their hands (whether it be a smartphone, communicator or tablet) uses applications: a browser, email and instant messaging client, games, business or financial programs. And often it is hidden from users that many of the applications interact with a remote server: they exchange data with it via the Internet.
By occupation (Java server application developer), I have to develop a server for mobile clients in the team (over the past 2 years I have been involved in the implementation of 3 such projects for foreign companies). A set of Java technologies was identified for solving problems of this kind, which varies depending on requirements and expediency (in other words, desires), since freedom allows you to experiment when choosing technologies. Formed point of view and experience I would like to share with the community.
Requirements
The peculiarity is that requirements are formed for both server and client applications, which in some cases are interconnected. First, 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. The customer is rarely satisfied with one type of device.
• speed: must be provided with sufficient workflow speed, comfortable response on the graphical user interface;
• simplicity: the simpler the protocol API, the less time it takes to implement and maintain the code, the less the developer’s qualifications can be;
• Efficiency: the more complex the protocol implementation, the more mobile device resources 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 - notify the application (user) about the occurrence of certain events, send a message to the user. This property should have, for example, a stock exchange system or an automatic taxi dispatcher.
• open API: it is assumed that third-party developers can use the functionality of the system through a documented protocol. After all, the client can be both a mobile and an external server application.
• other requirements ...
Team
The composition of the project team for system development could ideally be as follows:
• project manager: manages, controls the project, interacts directly with the customer;
• server application developer: developing a business logic server, database, network protocol;
• administrator application developer: develops a Web application, a user interface for setting up and managing a server application;
• developer client application for Android;
• developer of client application for iOS;
• client application developer for ...
• tester: tests the admin application and client applications.
The attentive reader will notice that if you write a server application with a graphical interface, for example, on HTML5, you can save. In this case, the development of client applications is not required - the user interface is provided by the browser. This article does not consider such a case, it is a question of developing "native" (native) applications for mobile devices.
I have worked in a team with a full team, but it will be realistic - not always human resources and the budget allows you to assemble such a team. And sometimes the roles have to be combined: project manager + server application developer, client application developer + tester.
Technologies, tools, libraries
To develop a server for mobile clients, 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 automatic testing of applications ;
•
Apache Log4j - logging library;
•
Jenkins - continuous integration system;
•
Hibernate - ORM (settings, configuration in properties, xml files and annotations);
•
hibernate-generic-dao - the implementation of DAO from Google, implements the basic methods for working with database data, simplifies the implementation of filtering and sorting in methods;
•
Spring - the implementation of authentication and authorization (security), a container of services and bins (configuration in xml files and annotations), we also use when creating tests.
Depending on the specifics of the system and the requirements for it, I use one of 2 options for implementing a data exchange protocol.
When cross-platform, speed, simplicity, efficiency, scalability, open API are required, I take
Jersey - an implementation of REST (RESTful Web services) Web services. This library allows you to use data serialization in JSON format or (and) XML. REST configuration is done through annotations. For exchange with mobile devices, the JSON format is taken for the reason that it has a simpler implementation on the client side (for this reason we do not use “classic” Web services), a smaller amount of traffic is generated. Jersey allows you to tune in to the most appropriate “look” of JSON.
Otherwise, if you need cross-platform, high speed, simplicity, efficiency, interactivity, then I take
•
Apache MINA - framework for creating network applications,
•
Google protobuf - library of encoding and decoding of structured data. The data structure is defined by the header files * .proto, 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 this needs to be laid at the design stage at the architecture level, taking into account business logic.
Consider a hypothetical task using the example of choosing technologies for a real SaaS service -
“Auction of services by Auknem” , which allows people to create an order to perform the required services or works, and organizations, in turn, leave their offers 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 unambiguously required to add scalability to them. What about interactivity? It would be great to inform contractors (executors) about the creation of new orders, and inform customers about the proposals received at the same moment in the application, and not just by e-mail. On the basis of this, we take to implement Apache MINA, Google protobuf. We look at the following property - open API. The service is public, so suppose that external developers may show interest in integrating with it. Wait a minute Not so simple. The protocol based on Apache MINA is quite strongly dependent on the implementation and integration without knowledge of the nuances is by no means transparent. In such a situation, it is necessary to weigh which factor is more important and make a choice.
Conclusion
I would be interested to know, and what technologies did you use, libraries when developing a server for mobile devices or similar systems? Everything changes, nothing lasts forever, at each level there are alternatives with their own advantages and disadvantages: MySQL -
PostgreSQL , Subversion -
Git , Apache Tomcat -
Jetty , Apache MINA -
Netty ...