Pros of FlorisBoard

• Customizable keyboard layout with multiple languages and themes
• Open-source project with active community development
• Supports gesture typing and clipboard management

Cons of FlorisBoard

• Still in beta, may have stability issues
• Limited emoji support compared to QKSMS
• Steeper learning curve for users accustomed to traditional keyboards

Code Comparison

FlorisBoard (Kotlin):

override fun onCreateInputView(): View {
    return InputView(this).also { inputView ->
        setInputView(inputView)
    }
}

QKSMS (Kotlin):

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.main_activity)
}

FlorisBoard focuses on creating a custom input view for the keyboard, while QKSMS sets up a standard activity layout. This reflects the different purposes of the two apps: FlorisBoard as a keyboard replacement and QKSMS as a messaging app.

Both projects use Kotlin, demonstrating modern Android development practices. However, FlorisBoard's code is more specialized for keyboard functionality, whereas QKSMS has a broader scope for messaging features.

Pros of Signal-Android

• Enhanced security features, including end-to-end encryption
• Broader functionality beyond SMS, including voice and video calls
• Regular updates and active development from a dedicated team

Cons of Signal-Android

• Larger app size and potentially higher resource usage
• Requires users to create an account and use Signal's servers
• Less customizable interface compared to QKSMS

Code Comparison

QKSMS (Kotlin):

override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
    binding = ComposeActivityBinding.inflate(inflater, container, false)
    return binding.root
}

Signal-Android (Java):

@Override
public View onCreateView(@NonNull LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    View view = inflater.inflate(R.layout.conversation_fragment, container, false);
    composeText = view.findViewById(R.id.embedded_text_editor);
    return view;
}

Both repositories use similar patterns for creating views, but QKSMS utilizes Kotlin's view binding feature for a more concise syntax, while Signal-Android uses traditional Java view inflation and findViewById methods.

Pros of Element

• Supports end-to-end encryption for secure messaging
• Offers cross-platform synchronization and multiple device support
• Provides a wider range of features, including voice/video calls and file sharing

Cons of Element

• More complex codebase due to additional features
• Potentially higher resource usage and battery consumption
• Steeper learning curve for new contributors due to project complexity

Code Comparison

QKSMS (Kotlin):

override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
    binding = ComposeActivityBinding.inflate(inflater, container, false)
    return binding.root
}

Element (Kotlin):

override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View {
    _views = FragmentRoomDetailBinding.inflate(inflater, container, false)
    return views.root
}

Both projects use Kotlin and follow similar patterns for view inflation in fragments. Element tends to have more complex view hierarchies due to its broader feature set.

Pros of DeltaChat

• Decentralized architecture using email protocols for enhanced privacy and security
• Cross-platform compatibility with iOS, desktop, and web versions available
• End-to-end encryption for all messages and attachments

Cons of DeltaChat

• Steeper learning curve due to email-based system and additional setup requirements
• Potentially slower message delivery compared to traditional SMS or instant messaging
• Limited adoption and user base compared to more mainstream messaging apps

Code Comparison

DeltaChat (Kotlin):

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
    if (savedInstanceState == null) {
        supportFragmentManager.beginTransaction()
            .replace(R.id.main_container, ConversationListFragment())
            .commit()
    }
}

QKSMS (Kotlin):

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.main_activity)
    if (isDefaultSms()) {
        navigator.showMain()
    } else {
        navigator.showDefaultSmsDialog()
    }
}

Both projects use Kotlin and follow similar patterns for activity creation. DeltaChat focuses on loading a conversation list fragment, while QKSMS checks for default SMS app status before navigation.

Pros of Thunderbird

• Backed by Mozilla, providing more resources and potential for long-term support
• Integrates with existing Thunderbird desktop client, offering a seamless experience across devices
• Supports multiple email accounts and protocols beyond just SMS

Cons of Thunderbird

• Larger codebase and more complex functionality, potentially leading to slower updates and more bugs
• Less focused on SMS-specific features compared to QKSMS
• May have a steeper learning curve for users who only need SMS functionality

Code Comparison

QKSMS (Kotlin):

override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
    binding = ComposeActivityBinding.inflate(inflater, container, false)
    return binding.root
}

Thunderbird (Java):

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    View view = inflater.inflate(R.layout.message_list_fragment, container, false);
    initializeMessageList(view);
    return view;
}

The code snippets show differences in language (Kotlin vs Java) and approach to view binding. QKSMS uses view binding, while Thunderbird uses a more traditional approach with findViewById() calls (not shown in the snippet).

Both projects follow modern Android development practices, but QKSMS's use of Kotlin and view binding may lead to more concise and null-safe code.

Pros of proton-mail-android

• Focuses on privacy and security with end-to-end encryption
• Integrates with the broader Proton ecosystem (ProtonVPN, ProtonCalendar)
• Regularly updated with new features and security improvements

Cons of proton-mail-android

• Limited to email functionality, unlike QKSMS which handles SMS/MMS
• Requires a Proton account, while QKSMS works with any SMS provider
• Less customizable UI compared to QKSMS's extensive theming options

Code Comparison

QKSMS (Kotlin):

override fun bindIntents() {
    conversationRepo.getConversations()
            .autoDisposable(scope())
            .subscribe { conversations ->
                newState { it.copy(conversations = conversations) }
            }
}

proton-mail-android (Kotlin):

override fun observeData() {
    viewModelScope.launch {
        mailboxManager.observeMailboxes()
            .collect { mailboxes ->
                _uiState.update { it.copy(mailboxes = mailboxes) }
            }
    }
}

Both projects use Kotlin and follow reactive programming patterns, but proton-mail-android leverages Kotlin coroutines for asynchronous operations, while QKSMS uses RxJava.