Skip to content

Architecture

Sam Kazerouni edited this page Jan 17, 2017 · 9 revisions

Capture.png

The Models package contains all the models required which are mapped to the ones used in the database. These are the current models for our application and will be updated in the future.

Models Package: model.png

This package contains the view models for each activity in our application, currently we have LoginActivity, MainActivity and StartingMapActivity. These view models are used to update the views of these activities and contain logic related to user interface.

Activities View Models Package:

activitiesviewmodel.png

This is another View Models package, it updates the views, contains some business logic related to views, however these each fragment in our application has an associated view model which takes care of the fragments view.

Fragments View Models Package:

fragmentsviewmodel.png

The Utility package contains all utility classes and enums of the application. These utility classes are converters, tools, etc…

Utility Package utility.png The Service packages are the most important packages in our application because they contain most of business logic related to the core of our application. They have IRepository types in their constructor using dependency injection, which retrieves a repository type and can interface to the database easily. There is no instantiation of these types and the singleton pattern is used for each repository type. This is all maintained in the framework. The Data services contain business logic related to data.

Data Service Package:

dataservice.png

This is another service package which is very important. The General Service package contains core business logic and doesn’t contain business logic related to data.

General Service Package:

generalservice.png Repository Package: repository.png The repository classes are the commands to make calls to the database and use the RestClient class shown below. These are classes are the gateway to the database, they use the RestClient to send HTTP requests to the webservice which then sends a POST or GET to database. The response from webservice is then returned to the Restclient and passed onto the Repository.

Contracts

These are the contracts packages, the repository and service contracts contain several methods which are used in our repositories and services respectively. We define them here before we use them in our application.

Repository Contracts Package:

repo_contracts.png

Service Contracts Package:

service_contracts.png

Rest Client:

restclient.png

Infrastructure

MvvmCross Framework (Application framework) https://mvvmcross.com/

MvvmCross is a cross-platform mvvm framework that allows developers to create cross platform apps. Model-View-ViewModel is an software architectural pattern. MVVM is a variation of Martin Fowler's Presentation Model design pattern. Like Fowler's Presentation Model, MVVM abstracts a view's state and behavior. However, whereas the Presentation Model abstracts a view (i.e., creates a view model) in a manner not dependent on a specific user-interface platform.Several reasons why we are using

MVVM and Presentation Model both derive from the model–view–controller pattern (MVC). MVVM facilitates a separation of development of the graphical user interface (either as markup language or GUI code) from development of the business logic or back-end logic (the data model). The view model of MVVM is a value converter meaning the ViewModel is responsible for exposing (converting) the data objects from the model in such a way objects are easily managed and consumed. In this respect, the view model is more model than view, and handles most if not all of the view's display logic The view model may implement a mediator pattern, organizing access to the back-end logic around the set of use cases supported by the view.

We took advantage of all the benefits that are provided by MVVMCross, such as bindings, converters, IoC, etc. For the Portable Class Libraries, the other option to sharing code is file-linking. PCL is neat, tidy, and requires no overhead when your common code library changes. File-linking is a manual process and can begin to get cumbersome after constant project changes. Furthermore, extensibility of the application can be easily done using the concept of plugins. Plugins can be added to the framework which can make our application grow much faster.

The disadvantage of using MvvmCross framework is that there a learning curve.

Clone this wiki locally