Design

System Architecture

This section introduces the design of the mobile application. Generally speaking, this architecture adopts the classic Model-View-Controller (MVC) pattern (Reenskaug and Coplien, 2009).

Models include UserModel, ChannelModel , VideoModel, WikiModel and many others, each holding information and buffered data from X5GON Backend.

Data updates are made from ViewControllers to Views.

User interactions are captured through GestureRecognisers and Actions in various ViewControllers and then delegate to the MainController.

With the main logic implemented in the MainController, it dispatch changes to relevant Models, which will then be reflected in Views eventually.

Meanwhile, daemon Refresher workers keep track of the Model changes and update them with the X5Learn backend when suitable.

Reason

Our team adopted the MVC architecture mainly because of its high cohesion and low coupling. We can group sections of similar actions on DataModels together in the MainController, and ensure there is little to no coupling among these three parts. In other words, modifications to views would in no way break our API, and similarly otherwise. This gives us confidence when working on our code and helps us to work together as a team with multiple development branches on the same code base.

Single Responsibility Principle (DeMarco, 1979)

We have made substantial effort to separate responsibility among multiple modules in our application. As an example, we abstracted the reloading and refreshing logic out of all ViewControllers and put them into an Extension named refresher().

Refreshing can be done easily with passing lambda or Closures to the extension without any other code needed.

We find this principle particularly useful as we can maintain a same set of multi-threading strategy and Queue throughout the code base. For a deeper dive into our multi-threading strategy, see implementation section for more details.

Liskov's Substitution Principle (Liskov, 1994)

We strictly follow the Open Closed Principle and its extension Liskov's Substitution Principle throughout our DataModels. For instance, models like Videos or PDFs are subtypes of Content and can be substituted seamlessly in the code. This allows us to share multiple properties among the DataModels and eliminate redundancy.

Prototype Design Pattern (Duell, 1997)

Prototype Design Pattern is used in the project on PlayerViewController to ensure single responsibility principle and make different ViewControllers replicas for various Video sessions cleaner. For more information on our playerView implementation, see here for details.

Adapter Design Pattern (Freeman et al., 2004)

Whilst we are developing our application, the backend from our client is transforming from X5GON to X5Learn, such that we are supporting two back-ends at the same time. Therefore, we utilised the Adapter Design Pattern to make sure our MainController have access to the same set of API at the same time.

Singleton Design Pattern (Gamma et al., 1994)

To ensure that there is only one hefty MainController available globally, we utilised the singleton design pattern. The controller is available globally and statically, and is forbidden be constructed twice throughout the application's lifecycle.

Data Storage and Entity Relations

As a typical client side application, we are only storing limited amount of user and cache data.

User token, name and ID information are stored with NSUserDefaults (Apple Developer, 2020b) to ensure data persistence after quitting the application.

Videos, audios and PDF contents are only cached and can be retrieved with the CoreData of iOS (Apple Developer, 2020a).

See below, an entity diagram, on relations of user and cache data stored.

Application Map

We tried to make our application as intuitive as possible so as the user would be easy to navigate around. All views can be divided into NavigationViews and MainViews.

NavigationViews are used to navigate users around and incorporating supporting views such as SettingsView and SearchView.

MainViews are the core content presenting views and the user profile console.

References

Apple Developer (2020). Core Data | Apple Developer Documentation. [online] Available at: https://developer.apple.com/documentation/coredata [Accessed 22 Jan. 2020].

Apple Developer (2020). UserDefaults - Foundation | Apple Developer Documentation. [online] Available at: https://developer.apple.com/documentation/foundation/userdefaults [Accessed 22 Mar. 2020].

DeMarco, T., 1979. Structured Analysis And System Specification. Englewood Cliffs, NJ: Yourdon.

Duell, Michael (July 1997). "Non-Software Examples of Design Patterns". Object Magazine. 7 (5): 54. ISSN 1055-3614.

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley. pp. 97ff. ISBN 0-201-63361-2.

Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; Bates, Bert (2004). "Head First Design Patterns" (paperback). O'Reilly Media: 244. ISBN 978-0-596-00712-6. OCLC 809772256. Retrieved 2013-04-30.

Liskov, Barbara; Wing, Jeannette (1994-11-01). "A behavioral notion of subtyping". ACM Transactions on Programming Languages and Systems. 16 (6): 1811–1841. doi:10.1145/197320.197383.

Reenskaug, Trygve; Coplien, James O. (20 March 2009). "The DCI Architecture: A New Vision of Object-Oriented Programming". Artima Developer. Archived from the original (html) on 23 March 2009. Retrieved 3 August 2019. "More deeply, the framework exists to separate the representation of information from user interaction."

System Architecture

Reason

Design Principles and Patterns

Single Responsibility Principle (DeMarco, 1979)

Liskov's Substitution Principle (Liskov, 1994)

Prototype Design Pattern (Duell, 1997)

Adapter Design Pattern (Freeman et al., 2004)

Singleton Design Pattern (Gamma et al., 1994)

UML Class Diagram

Data Storage and Entity Relations

Sequence Diagram

Application Map

References

About COMP0016 Team 4 - Project X5GON Mobile Website

Important Links

Source Code