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 AIDL or some other sort of IPC
• move the message center to another process
• convert Smack classes into Smack managers
• use DI for UI views (also investigate other uses to simplify code)
• 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. TODO TODO TODO