Handshake

Design Our design incorporates the use of Model-View-Presenter (MVP), Publish-Subscribe and Event-based architecture. MVP is used for the structure and organization of the classes in the application. Publish-Subscribe and Event-based are used together to handle the communication of information between classes. An in-depth description of these architectures and the rationale for using is below. MVP was chosen to be used in our application because of its benefits which are, clear and concise organization of classes, clear separation of responsibility and flexibility. The organization of classes made it easier to develop and add new features since the whole team understood where classes/object should be placed. MVP layers prevented us from writing unmanageable code. In conjunction, the responsibility of classes was clearly defined based on where in the MVP layer they resided in. Activities and Fragments were responsible for the presentation/rendering of the data (UI) and handling interaction with the user. The Presenter is responsible for reacting to UI events and retrieving data for the UI to show. Lastly the Model is responsible for managing state and business behaviours. A product of this separation of responsibility is that code reusability increases. For example, we might have two Views that have similar UI design and can merge the code that is the same into its own View object and use that View object in any View that requires it.
A product of these two benefits introduced by using MVP, there was a lot of flexibility in code. If there was a need to remove the Event-based/Publish-Subscribe architecture, only the Presenter and Model layers would need to be modified. In contrast to this, MVC, which is also used in many Android applications, Fragments/Activities would not have the separation of responsibilities like we do in MVP since they’d be responsible for rendering UI, handle UI interactions and handle the responsibility of the Presenter layer. Using MVC would not give us the same flexibility as in MVP as Activities/Fragments would end up handling too much work and management of these classes would become increasingly difficult as the application scaled. Organization would also be severely lacking and make development harder since there wouldn’t be expectations of where things are implemented (in the case of a developer reading what others wrote). An Event-bus and Publish-Subscribe system was used for communication between Activities/Fragments and also between Presenter layer and Model layer. Whenever an “event” occurs, publishers who wish to inform or pass data to an object in another part of this system, would grab the instance of the eventbus and post the event. Any subscribers who subscribe to this event type would be able to consume the event. This is especially useful for communication between the Presentation and Model layer. For tasks that are often performed such as, modifying SharedPreferences or adding pending connections to other users in a database it allows near complete decoupling. Also, if a new Presenter is created, there is no need to write bloat code for getting a reference to the database object or SharedPreferences. All you need to do is create an onEvent method and simply post your data in an Event object to the eventbus. Decoupling of Fragments and Activities is also another benefit which also improves manageability of code since these types of classes are often changed drastically during development. Sequence Diagram:

Sequence Diagram : Social API Interaction Sequence Diagram : Share Location

Sequence Diagram : Search NearBy Users Sequence Diagram : Stop Sharing Location

Sequence Diagram : Update Current Location Sequence Diagram : NFC Device Interaction

Class Level Representation Our design minimizes coupling by making use of an eventbus and Publish-Subscribe architecture. There is not one instance of Activities and Fragments having access to one another directly with the exception of the creation of Fragments by our MainActivity. If any Fragment/Activity requires communicating to another Fragment/Activity, we simply post events to the eventbus and any subscribed classes to that specific event can consume it. This design accommodates future requirement changes. It is very easy to make use of a different architecture for communication between Fragments/Activities as you’d only have to modify the Presenter layer for the most part since Presenter classes do the heavy lifting in terms of retrieving/updating data. Also, changing the way views interact and look with a user can be as easy as deleting the view and replacing it with another. Since views do not have any code which interacts with the Model layer, the number of changes to make when modifying a view is constricted to only view related things. This also applies to making changes in the Presenter and Model layers. We can envision our system being altered in many ways. One obvious way is that more social media platforms are supported in our app (eg. 30+ platforms). Our design would support the addition of new platforms by making it very simple and repeatable to add a new platform. At this moment all the platform API’s in use follow the same pattern. The platform is added to the list of supported platforms, then an event object is created for it. Following that the subscriber to platform events handles the actual logging in to the platform. These platforms all have different ways in which a user logs in and forcing the developer to do it one way ensures that our application does not become a mess of code due to having platform log in code all over the codebase. Our design discourages developers from feeling lazy and introducing platform code wherever it is easiest to by making sure that there is a clear, concise, repeatable method to adding a platform. One way our system may need to evolve is in the way communication between classes within the application happen. Right now we rely on an eventbus but this can become a hinderance in the future. For each event, it is required to create a plain-old-java-object (POJO) which makes events unique from each other (the class name). They may also contain fields or be empty objects. The problem with these events is that as the application gets larger and more features are added, more events are required. Eventually there will come a point where it is too difficult to keep track of all the events being used and who are the creators and subscribers of these events. It’s not that large of a problem but can become one in the case of new developers taking over the project. Our design can support this change because of the way our system has very little coupling and how we have a layered architecture where each layer has a clear separation of responsibility. Our Presenter classes are the main users of the eventbus. If a Fragment/Activity needs to communicate with another class (Fragment, Activity, database, etc.) it simply tells it’s Presenter(s) to perform the communication and retrieve/send the data through the eventbus. Since the eventbus is confined to one layer, Presentation layer, only the Presenter classes would need to be modified to handle a new communication system if the eventbus was to be replaced.