-
Notifications
You must be signed in to change notification settings - Fork 0
Choice Of Technologies
The choice of the project's technologies plays an important part on the speed and ease of development, and as such these are the reasons some were chosen in detriment of others.
There are plenty of programming languages supported by the Android platform to build an android application and each one has individual strengths and weaknesses. Only some languages look interesting and those that were taken into consideration were:
- Java
- Kotlin
It is an object oriented language and is one of the most popular programming languages, which makes it more likely to be understood by other developers. This language is the most popular option when it comes to develop android applications and is also the official language of the Android platform, meaning it is the one that has the most support from google.
- A lot of support in the form of documentation.
- Robust language.
It is a object oriented programming language and is getting more and more used nowadays. Described as a general purpose language, Kotlin introduces functional features to support interoperability and intelligibility and was born out of the aspiration for heightened productivity. The goal was to improve the coding experience in a way that was practical and effectual. Kotlin is entirely compatible with Java and was specifically designed to improve existing Java models by offering solutions to API design deficiencies.
- Inherently lightweight, clean and less verbose.
- Fixes a series of issues that Java suffers.
Every new Android version introduces changes that bring significant security and performance improvements – and enhance the user experience of Android overall. Some of these changes only apply to apps that explicitly declare support through their target Sdk Version manifest attribute (also known as the target API level). Configuring an app to target a recent API level ensures that users can benefit from these improvements, while still allowing it to run on older Android versions. Targeting a recent API level also allows your app to take advantage of the platform's latest features to the delight of your users.
The chosen API Level for this project was the the API 19: Android 4.4 (KitKat), because is the recommended by google and supports all objective functionalities for this project.
When choosing the Database Management System there are a few options to consider, but the first decision is to choose whether to use a relational database or a document based one.
- Well defined schema containing table definition and their relationships.
- Less redundancy due to data normalization.
- To add a new field the table must be updated as well as its relationships if necessary.
- Vertical scalability.
- Consistency and Availability.
- Mature software, the main relational database management systems are well documented and have a large working community.
- Hard to change structure during production. A single change will have a ripple effect across (potentially) the whole database.
- Inefficient when a huge volume of data is used.
- Dynamic schema, documents can be changed (e.g. when a field is added to a document) with no impact on the rest of the database.
- Documents can be created without having to first define their structure.
- Each document can have its own unique structure.
- Horizontal scalability, good for large or ever-changing data sets.
- Flexible and fast in simple queries.
- Hard to maintain data integrity.
- Less performance on complex queries.
The project requires the entities of the database to have well defined structures as well as well defined relationships with one another and as such the chosen DBMS was of a relational type
.
Within the relational database model there are a lot of technologies to consider, to name a few:
- Microsoft SQLServer
- Oracle
- MySql
- PostgreSQL
Upon inspection of the each one, PostgreSQL
was the one that stood out, due to the particularity of geometric and geographic functionalities of the system. The project will require some calculations based on geographic coordinates of its users and PostgreSQL
fits those requirements.
There are several technological options on the Social Routing Service. This component has to support communication with the DBMS
as well as communication with a Client Application
while exposing its functionalities through an API. The considered technologies were:
- NodeJs
- JVM
NodeJs
is built with a single threaded event loop model and this characteristic alone is enough to put it aside. The server side of the project will need to compute routes for multiple users at the same time, and considering this is a complex and time consuming task, concurrency will most likely be required. The Java Virtual Machine
offers this option, and requires the less amount of research when compared with another less known (by us) technologies.
We decided to work within the JVM
environment. Next is which programming language to use and the choices we are considered were Java
and Kotlin
. For some of the reasons already stated in the Client Application and to keep the project consistent and avoid working in multiple languages and build tools we chose Kotlin
.
- Java vs Kotlin (Client Side Application)
- https://docs.oracle.com/javase/tutorial/getStarted/intro/definition.html
- https://kotlinlang.org/docs/reference/comparison-to-java.html
- https://www.androidauthority.com/develop-android-apps-languages-learn-391008/
- https://clearbridgemobile.com/java-vs-kotlin-which-is-the-better-option-for-android-app-development/
- Document based database vs Relational Databases (Server Side):
- NodeJs vs JVM (Server Side)