Road to Kontalk 5.0

This page must not be translated. Also please do not edit if you are not a Kontalk developer.

Kontalk is starting to become a big project and lately it's been growing a bit uncontrollably. Some refactoring is needed at this stage, before implementing OMEMO which is expected for version 5.0. Special care must be taken for:

• modularization of app components, especially for the UI part
• drop usage of intents and broadcasts for message center service communication. Use a simpler mechanism such as an event bus
• convert Smack classes into Smack managers
• use DI at least for UI views
• use a database library or build something easier to use without exposing too much low-level stuff (keep in mind that the messages content provider will be exposed one day)
• read contact information directly from system contacts (that is, store only phone:hash associations)
• support for multiple encryption methods
• refactor compose fragments after having modularized everything inside it. Ok for the common parent class, but the parent was designed too much to be for the children
• unit and automated tests

The redesign will happen gradually within the 4.x series, until OMEMO is completed and 5.0 will be released.

This page will contain technical design notes about this major redesign of the app.

Messages content provider

The messages content provider will be exposed one day, so the current use of cursors and a content provider can't be dismantled. Using an ORM in this case would be counter-productive (unless the ORM itself interfaces with the content provider, but that's an extra layer we don't want), so a good thing to do here would be to simplify the messages provider itself. It currently makes use of many things such as triggers, workarounds, tricks on the ContentValues objects it receives for inserts/updates.

Some work to simplify the messages provider has already been done, by removing some triggers and move more business logic to the provider itself. The next step would be build a more consistent API so we can design a formal contract to expose the provider to external apps.

Message Center communication

Introduce some event bus or similar technology to ease communication with the message center. A layer on top of intents and broadcasts has already been introduced through MessageCenterClient, but I don't think it's the answer, at least not completely. Keeping the listener architecture while introducing the event bus stuff just between the message center client and the message center service is counterproductive. Give up separating the message center into a different process and connect through event bus directly. Particular attention should be given to starting and stopping the message center: tie them to application components lifecycle or find a way for using a wake-on-bus message.

Modularize compose message fragments

TODO

Support for multiple encryption mechanism

TODO