dimanche 29 mars 2015

Android Chat application - best practice

I'm building a chat application for Android and I thought about a programming design that include design patterns.


I want to know if my solution for doing it is the right thing to do or there is a better solution, that will be more efficient and easy in long term.


My application is currently have couple of basic actions/services that I can use:



  1. Monitoring

  2. Chat

  3. View

  4. Network


I thought to create the next classes:



  1. MainController - the main controller of the whole application(Mediator design pattern)

  2. MonitoringController - controller for only the monitoring issues, it only know the mainController and the other monitoring related classes.

  3. ChatController - same like MonitoringController, but chat issues related.

  4. ViewController - in charge for every change from/to the activities or fragments in the application, know the MainController.

  5. NetworkController - same like MonitoringController, but network issues related.


So, in other words, the mainController is my biggest class that know every other controller in the system, and that component is the only one that pass the events from one controller to the other. Every controller is implementing a dedicated interface that is used also in the mainController, so the mainController is implementing all the interfaces of all the controllers that "speak" with him.


This is how it's going to be for a top level design (of course that this will be larger in the next months, depends on the features I will add). enter image description here


Concerns:




  1. The mainController class will grow on every new feature, so that class will hold a lot of logic inside.




  2. The mainController will hold an instance of every other controller and vice verse - each controller will hold an instance of the mainController. So, I don't sure if this is a good thing from OOP perspective.




Advantages:




  1. I have only one controller(Main) that know every other controller, which I think is better from the other option of holding instance of each service that I need to use.




  2. Every controller don't know and doesn't care to which other controller to pass his callback, this is the mainContoller concern (fire and forget).




  3. Implementing new features is easy - I don't need to change a lot of code to support it, and I can add another controller if that feature is large enough.




Appreciate any thought or idea.


Aucun commentaire:

Enregistrer un commentaire