As already illustrated in the Architectural Design, our system follows a traditional client-server infrastructure, where the mobile application is the client that communicates with a centralised server over a REST API using JSON. The reason why we chose REST over SOAP is because REST is
- simple (it uses standard HTTP methods like GET, PUT, POST and DELETE),
- infrastructure friendly (all network components like firewalls, proxies or load balancers are optimised for RESTful traffic),
- cacheable,
- scalable (REST is stateless and hence very scalable) and
- efficient.
The implementation of the mobile application depends on the platform it is build for. Our application will be provided for both iOS (using Swift, which is more powerful than Objective-C) and Android (using JAVA and the Android Software Development Kit (SDK)). Both applications will be hybrid, which means that they are a combination of a web application and a native application. For the web part, technologies like HTML, CSS and JavaScript will be used. However, since the app needs to access device capabilities (GPS), it needs to be hosted inside a native application, which will be downloadable from Google’s and Apple’s app store, respectively.
The mobile application will then communicate with the server using JSON, which is a data-interchange format similar to XML. The server itself will be developed using JAVA and MySQL. It is divided into two layers, the logic tier and the data tier. The logic tier is responsible for
- processing all the requests from the clients,
- matching users depending on their skills and interests,
- storing and retrieving data from the database,
- converting data back to JSON and sending it back to the client.
Moreover, it will send push notifications to Apple and Google, which in turn will forward them to the clients (All mobile devices from Apple and Google have a persistent and encrypted connection to their push notification servers).
The data tier (MySQL server) is responsible for the storage of all personal user information as well as their current location. Whenever a user opens his application, his current location will be send to our centralised server, which will update the current location to its new one. The matching algorithm is based on the last sent location of each user.
Please comment with your real name using good manners.