mirror of
https://github.com/permissionlesstech/bitchat-android.git
synced 2026-07-24 22:45:20 +00:00
bump to 0.6
This commit is contained in:
callebtc
+30
-1
@@ -5,10 +5,39 @@ All notable changes to this project will be documented in this file.
|
||||
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
|
||||
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
||||
|
||||
## [Unreleased]
|
||||
## [0.6]
|
||||
|
||||
### Added
|
||||
- Channel password management with `/pass` command for channel owners
|
||||
- Monochrome/themed launcher icon for Android 12+ dynamic theming support
|
||||
- Unit tests package with initial testing infrastructure
|
||||
- Production build optimization with code minification and shrinking
|
||||
|
||||
### Fixed
|
||||
- Favorite peer functionality completely restored and improved
|
||||
- Enhanced favorite system with fallback mechanism for peers without key exchange
|
||||
- Fixed UI state updates for favorite stars in both header and sidebar
|
||||
- Improved favorite persistence across app sessions
|
||||
- `/w` command now displays user nicknames instead of peer IDs
|
||||
- Button styling and layout improvements across the app
|
||||
- Enhanced back button positioning and styling
|
||||
- Improved private chat and channel header button layouts
|
||||
- Fixed button padding and alignment issues
|
||||
- Color scheme consistency updates
|
||||
- Updated orange color throughout the app to match iOS version
|
||||
- Consistent color usage for private messages and UI elements
|
||||
- App startup reliability improvements
|
||||
- Better initialization sequence handling
|
||||
- Fixed null pointer exceptions during startup
|
||||
- Enhanced error handling and logging
|
||||
- Input field styling and behavior improvements
|
||||
- Sidebar user interaction enhancements
|
||||
- Permission explanation screen layout fixes with proper vertical padding
|
||||
|
||||
### Changed
|
||||
- Updated GitHub organization references in project files
|
||||
- Improved README documentation with updated clone URLs
|
||||
- Enhanced logging throughout the application for better debugging
|
||||
|
||||
## [0.5.1] - 2025-07-10
|
||||
|
||||
|
||||
@@ -1,64 +0,0 @@
|
||||
# ChatScreen.kt Refactoring Plan
|
||||
|
||||
## Current State
|
||||
- Single file: `ChatScreen.kt` (~1,100+ lines)
|
||||
- Multiple UI responsibilities mixed together
|
||||
- Hard to maintain and test individual components
|
||||
|
||||
## Proposed Component Structure
|
||||
|
||||
### 1. Main Screen (ChatScreen.kt)
|
||||
**Responsibilities:**
|
||||
- Main layout orchestration
|
||||
- State management delegation
|
||||
- Window insets handling
|
||||
- Component coordination
|
||||
|
||||
### 2. Header Components (ChatHeader.kt)
|
||||
**Responsibilities:**
|
||||
- TopAppBar with different states (main, private, channel)
|
||||
- Nickname editor
|
||||
- Peer counter with status indicators
|
||||
- Navigation controls
|
||||
|
||||
### 3. Message Components (MessageComponents.kt)
|
||||
**Responsibilities:**
|
||||
- MessagesList composable
|
||||
- MessageItem with formatting
|
||||
- Message text parsing and styling
|
||||
- Delivery status indicators
|
||||
- RSSI-based coloring
|
||||
|
||||
### 4. Input Components (InputComponents.kt)
|
||||
**Responsibilities:**
|
||||
- MessageInput with different modes
|
||||
- Command suggestions box
|
||||
- Command suggestion items
|
||||
- Input validation and handling
|
||||
|
||||
### 5. Sidebar Components (SidebarComponents.kt)
|
||||
**Responsibilities:**
|
||||
- SidebarOverlay with navigation
|
||||
- ChannelsSection for channel management
|
||||
- PeopleSection for peer list
|
||||
- Sidebar state management
|
||||
|
||||
### 6. Dialog Components (DialogComponents.kt)
|
||||
**Responsibilities:**
|
||||
- Password prompt dialog
|
||||
- App info dialog
|
||||
- Other modal dialogs
|
||||
|
||||
### 7. UI Utils (ChatUIUtils.kt)
|
||||
**Responsibilities:**
|
||||
- RSSI color mapping
|
||||
- Text formatting utilities
|
||||
- Common styling constants
|
||||
- Helper functions
|
||||
|
||||
## Benefits
|
||||
- Each file has a single, clear responsibility
|
||||
- Components are easier to test in isolation
|
||||
- Better code organization and navigation
|
||||
- Simplified debugging
|
||||
- Easier to add new UI features
|
||||
@@ -1,103 +0,0 @@
|
||||
# BluetoothMeshService Refactoring - Progress Report
|
||||
|
||||
## ✅ COMPLETED: Extracted Components (All compile successfully)
|
||||
|
||||
### 1. PeerManager.kt (161 lines)
|
||||
**Responsibilities:**
|
||||
- Active peer tracking and lifecycle management
|
||||
- Peer nickname management and stale peer cleanup
|
||||
- RSSI tracking and peer list updates
|
||||
- **Interface:** `PeerManagerDelegate`
|
||||
|
||||
### 2. FragmentManager.kt (194 lines)
|
||||
**Responsibilities:**
|
||||
- Message fragmentation for large messages (>500 bytes)
|
||||
- Fragment reassembly and cleanup
|
||||
- Fragment timeout management (30 seconds)
|
||||
- **Interface:** `FragmentManagerDelegate`
|
||||
|
||||
### 3. SecurityManager.kt (236 lines)
|
||||
**Responsibilities:**
|
||||
- Duplicate detection and replay attack protection
|
||||
- Key exchange handling and validation
|
||||
- Message encryption/decryption operations
|
||||
- Packet signature verification
|
||||
- **Interface:** `SecurityManagerDelegate`
|
||||
|
||||
### 4. StoreForwardManager.kt (295 lines)
|
||||
**Responsibilities:**
|
||||
- Message caching for offline peers (12 hours regular, unlimited favorites)
|
||||
- Store-and-forward delivery when peers come online
|
||||
- Cache cleanup and management
|
||||
- **Interface:** `StoreForwardManagerDelegate`
|
||||
|
||||
### 5. MessageHandler.kt (284 lines)
|
||||
**Responsibilities:**
|
||||
- Processing different message types (ANNOUNCE, MESSAGE, LEAVE, etc.)
|
||||
- Broadcast vs private message handling
|
||||
- Message relay logic with adaptive probability
|
||||
- Delivery acknowledgment sending
|
||||
- **Interface:** `MessageHandlerDelegate`
|
||||
|
||||
### 6. BluetoothConnectionManager.kt (611 lines)
|
||||
**Responsibilities:**
|
||||
- BLE advertising and scanning
|
||||
- GATT server/client setup and management
|
||||
- Device connection tracking (both server and client modes)
|
||||
- Packet broadcasting to all connected devices
|
||||
- **Interface:** `BluetoothConnectionManagerDelegate`
|
||||
|
||||
## 📊 Size Reduction Analysis
|
||||
|
||||
| Component | Lines | Responsibility |
|
||||
|-----------|--------|----------------|
|
||||
| **PeerManager** | 161 | Peer lifecycle & tracking |
|
||||
| **FragmentManager** | 194 | Message fragmentation |
|
||||
| **SecurityManager** | 236 | Security & encryption |
|
||||
| **StoreForwardManager** | 295 | Offline message caching |
|
||||
| **MessageHandler** | 284 | Message type processing |
|
||||
| **BluetoothConnectionManager** | 611 | BLE connection management |
|
||||
| **Original File** | ~1000+ | All responsibilities mixed |
|
||||
|
||||
**Total Extracted:** ~1781 lines (distributed across 6 focused files)
|
||||
**Reduction Factor:** Original single file → 6 smaller, focused components
|
||||
|
||||
## 🏗️ Next Steps for Integration
|
||||
|
||||
### Phase 1: Refactor Existing BluetoothMeshService
|
||||
1. **Update BluetoothMeshService.kt** to use the new components
|
||||
2. **Wire up all delegate interfaces**
|
||||
3. **Maintain exact same public API** so ChatViewModel doesn't change
|
||||
4. **Test compilation and functionality**
|
||||
|
||||
### Phase 2: Integration Testing
|
||||
1. **Verify all existing functionality works**
|
||||
2. **Test key scenarios:**
|
||||
- Peer discovery and connection
|
||||
- Message sending/receiving
|
||||
- Fragment handling
|
||||
- Store-and-forward delivery
|
||||
- Security validation
|
||||
|
||||
### Phase 3: Benefits Validation
|
||||
1. **Easier unit testing** (each component can be tested independently)
|
||||
2. **Better code maintainability** (clear separation of concerns)
|
||||
3. **Improved debugging** (isolated component logs)
|
||||
4. **Future extensibility** (easier to add new features)
|
||||
|
||||
## 🔧 Current Build Status
|
||||
✅ **All 6 extracted components compile successfully**
|
||||
✅ **No breaking changes to existing interfaces**
|
||||
✅ **Original BluetoothMeshService.kt still intact**
|
||||
✅ **Ready for integration phase**
|
||||
|
||||
## 💡 Key Design Decisions Made
|
||||
|
||||
1. **Delegate Pattern:** Each component uses a delegate interface for clean separation
|
||||
2. **Coroutine Scope per Component:** Isolated lifecycle management
|
||||
3. **Thread-Safe Collections:** Maintained from original implementation
|
||||
4. **Same UUIDs and Constants:** No protocol changes
|
||||
5. **Preserved iOS Compatibility:** All timing and logic matches iOS exactly
|
||||
6. **Error Handling:** Maintained original defensive programming patterns
|
||||
|
||||
The refactoring successfully breaks down a monolithic 1000+ line service into 6 focused, maintainable components while preserving 100% compatibility with the iOS implementation.
|
||||
@@ -1,80 +0,0 @@
|
||||
# RSSI Color Change Fix - Implementation Summary
|
||||
|
||||
## Problem Identified
|
||||
The username colors in the chat were not changing based on RSSI signal strength even though RSSI values were being logged as changing. Investigation revealed that:
|
||||
|
||||
1. **RSSI values were only captured once** during the initial BLE scan discovery
|
||||
2. **No mechanism existed** to continuously update RSSI values from connected devices
|
||||
3. **UI was not being notified** of RSSI changes to trigger recomposition
|
||||
4. **Chat rendering was using stale RSSI values** that never changed after initial connection
|
||||
|
||||
## Root Cause
|
||||
The `BluetoothMeshService` was only recording RSSI during the scan phase (`handleScanResult`) but never updating it during the connection lifetime. Bluetooth GATT provides `readRemoteRssi()` for connected devices, but this wasn't being used.
|
||||
|
||||
## Solution Implemented
|
||||
|
||||
### 1. Device-to-Peer ID Mapping
|
||||
- Added `deviceToPeerIDMapping` to link Bluetooth devices to peer IDs
|
||||
- This allows RSSI updates to be associated with the correct peer ID
|
||||
|
||||
### 2. GATT RSSI Reading Callback
|
||||
- Added `onReadRemoteRssi()` callback in the GATT client callback
|
||||
- Updates `peerRSSI` map when new RSSI values are read
|
||||
- Maps device addresses to peer IDs for proper tracking
|
||||
|
||||
### 3. Periodic RSSI Monitoring
|
||||
- Added background coroutine that runs every 5 seconds
|
||||
- Calls `readRemoteRssi()` on all active GATT connections
|
||||
- Provides continuous RSSI updates during connection lifetime
|
||||
|
||||
### 4. UI Notification System
|
||||
- Added `didUpdateRSSI()` delegate method to notify UI of RSSI changes
|
||||
- When RSSI changes, the delegate is called to potentially trigger UI updates
|
||||
- Chat screen automatically recomposes when RSSI values change
|
||||
|
||||
### 5. Key Exchange Enhancement
|
||||
- Modified `handleKeyExchange()` to map devices to peer IDs
|
||||
- Transfers any existing peripheral RSSI data to peer-based tracking
|
||||
- Ensures proper RSSI association after peer identification
|
||||
|
||||
## Code Changes Made
|
||||
|
||||
### BluetoothMeshService.kt
|
||||
1. **Added device mapping**: `deviceToPeerIDMapping` concurrent hash map
|
||||
2. **RSSI callback**: `onReadRemoteRssi()` implementation in GATT callback
|
||||
3. **Periodic monitoring**: `monitorRSSI()` function called every 5 seconds
|
||||
4. **Key exchange update**: Links devices to peer IDs for RSSI tracking
|
||||
5. **Delegate method**: `didUpdateRSSI()` interface method for UI notifications
|
||||
|
||||
### ChatViewModel.kt
|
||||
1. **Delegate implementation**: Added `didUpdateRSSI()` method
|
||||
2. **Logging**: Debug output when RSSI values change
|
||||
|
||||
### ChatScreen.kt
|
||||
- **No changes needed** - existing `getRSSIColor(rssi)` function already works
|
||||
- UI automatically recomposes when `meshService.getPeerRSSI()` returns updated values
|
||||
|
||||
## How It Works Now
|
||||
|
||||
1. **Initial Discovery**: RSSI captured during BLE scan (as before)
|
||||
2. **Connection**: Device mapped to peer ID during key exchange
|
||||
3. **Monitoring**: Every 5 seconds, `readRemoteRssi()` called on connected devices
|
||||
4. **Update**: RSSI callback updates `peerRSSI` map with new values
|
||||
5. **Notification**: Delegate notified of RSSI change
|
||||
6. **Rendering**: Chat screen uses updated RSSI values for color calculation
|
||||
7. **Recomposition**: UI automatically updates with new colors
|
||||
|
||||
## Expected Behavior
|
||||
- Username colors now change dynamically as users move closer/farther away
|
||||
- Colors reflect real-time signal strength: green (strong) → yellow (medium) → red (weak)
|
||||
- Updates occur every 5 seconds while devices are connected
|
||||
- Your own username remains green regardless of signal strength
|
||||
- Works for both client and server GATT connections
|
||||
|
||||
## Testing
|
||||
- Build successful with `./gradlew assembleDebug`
|
||||
- No compilation errors
|
||||
- All existing functionality preserved
|
||||
- Ready for testing with actual devices
|
||||
|
||||
The fix addresses the core issue where RSSI values were static after connection. Now they continuously update, providing the dynamic color feedback based on signal strength that was originally intended.
|
||||
@@ -12,8 +12,8 @@ android {
|
||||
applicationId = "com.bitchat.android"
|
||||
minSdk = libs.versions.minSdk.get().toInt()
|
||||
targetSdk = libs.versions.targetSdk.get().toInt()
|
||||
versionCode = 1
|
||||
versionName = "1.0"
|
||||
versionCode = 2
|
||||
versionName = "0.6"
|
||||
|
||||
testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
|
||||
vectorDrawables {
|
||||
|
||||
@@ -1,62 +0,0 @@
|
||||
# Username Color Feature Demo
|
||||
|
||||
The bitchat Android app already has the username color feature fully implemented! Here's how it works:
|
||||
|
||||
## How It Works
|
||||
|
||||
1. **Your username remains green** - Uses `colorScheme.primary` (bright green in dark mode, dark green in light mode)
|
||||
2. **Other users get unique colors** - Based on their peer ID using the `getUsernameColor()` function
|
||||
3. **Colors are consistent** - Same user always gets the same color across sessions
|
||||
4. **Terminal-friendly palette** - 16 colors that work on both black and white backgrounds
|
||||
|
||||
## Color Palette
|
||||
|
||||
The system uses these 16 terminal-friendly colors for other users:
|
||||
|
||||
- 🟢 Bright Green (#00FF00)
|
||||
- 🔵 Cyan (#00FFFF)
|
||||
- 🟡 Yellow (#FFFF00)
|
||||
- 🔴 Magenta (#FF00FF)
|
||||
- 🟦 Bright Blue (#0080FF)
|
||||
- 🟠 Orange (#FF8000)
|
||||
- 🔶 Lime Green (#80FF00)
|
||||
- 🟣 Purple (#8000FF)
|
||||
- 🩷 Pink (#FF0080)
|
||||
- 💚 Spring Green (#00FF80)
|
||||
- 🟦 Light Cyan (#80FFFF)
|
||||
- 🩷 Light Red (#FF8080)
|
||||
- 🟦 Light Blue (#8080FF)
|
||||
- 🟡 Light Yellow (#FFFF80)
|
||||
- 🩷 Light Magenta (#FF80FF)
|
||||
- 🟢 Light Green (#80FF80)
|
||||
|
||||
## Example Chat Display
|
||||
|
||||
```
|
||||
[14:23:45] <@you> hello everyone! ← Your message (green)
|
||||
[14:23:47] <@alice> hey there! ← Alice (cyan)
|
||||
[14:23:50] <@bob> how's it going? ← Bob (yellow)
|
||||
[14:23:52] <@charlie> great to see you all ← Charlie (magenta)
|
||||
[14:23:55] <@you> having a great time ← Your message (green)
|
||||
[14:23:58] <@alice> same here @you! ← Alice (cyan again)
|
||||
```
|
||||
|
||||
## Code Implementation
|
||||
|
||||
The feature is implemented in `/app/src/main/java/com/bitchat/android/ui/ChatScreen.kt`:
|
||||
|
||||
- Line 342-350: Color assignment logic in `formatMessageAsAnnotatedString()`
|
||||
- Line 820-855: `getUsernameColor()` function that generates consistent colors
|
||||
- Uses peer ID for consistency (falls back to nickname if no peer ID available)
|
||||
- Integrates perfectly with the existing IRC-style chat format
|
||||
|
||||
## Testing
|
||||
|
||||
The feature is already working in the app. When you chat with multiple users, you'll see:
|
||||
- Your messages in green
|
||||
- Each other user in their own unique color
|
||||
- Same user always has the same color
|
||||
- Colors remain consistent across app restarts
|
||||
- Works in both light and dark themes
|
||||
|
||||
The feature is **complete and ready to use**! 🎉
|
||||
@@ -1,73 +0,0 @@
|
||||
# BluetoothMeshService Refactoring Plan
|
||||
|
||||
## Current State
|
||||
- Single file: `BluetoothMeshService.kt` (~1000+ lines)
|
||||
- Multiple responsibilities mixed together
|
||||
- Hard to test and maintain
|
||||
|
||||
## Proposed Structure
|
||||
|
||||
### 1. Core Service (BluetoothMeshService.kt)
|
||||
**Responsibilities:**
|
||||
- Service lifecycle management
|
||||
- Coordination between components
|
||||
- Public API for sending messages
|
||||
- Delegate management
|
||||
|
||||
### 2. Connection Management (BluetoothConnectionManager.kt)
|
||||
**Responsibilities:**
|
||||
- BLE scanning and advertising
|
||||
- GATT server/client setup and management
|
||||
- Device connection tracking
|
||||
- Peer discovery and RSSI tracking
|
||||
|
||||
### 3. Packet Processing (PacketProcessor.kt)
|
||||
**Responsibilities:**
|
||||
- Incoming packet handling
|
||||
- Message type routing
|
||||
- TTL and duplicate detection
|
||||
- Timestamp validation
|
||||
|
||||
### 4. Message Handler (MessageHandler.kt)
|
||||
**Responsibilities:**
|
||||
- Processing specific message types (ANNOUNCE, MESSAGE, LEAVE, etc.)
|
||||
- Message parsing and validation
|
||||
- Relay logic
|
||||
|
||||
### 5. Fragment Manager (FragmentManager.kt)
|
||||
**Responsibilities:**
|
||||
- Message fragmentation for large messages
|
||||
- Fragment reassembly
|
||||
- Fragment cleanup and timeouts
|
||||
|
||||
### 6. Store-and-Forward Manager (StoreForwardManager.kt)
|
||||
**Responsibilities:**
|
||||
- Message caching for offline peers
|
||||
- Delivering cached messages when peers come online
|
||||
- Cache cleanup and management
|
||||
|
||||
### 7. Peer Manager (PeerManager.kt)
|
||||
**Responsibilities:**
|
||||
- Active peer tracking
|
||||
- Peer nickname management
|
||||
- Stale peer cleanup
|
||||
- Peer list updates
|
||||
|
||||
### 8. Security Manager (SecurityManager.kt)
|
||||
**Responsibilities:**
|
||||
- Key exchange handling
|
||||
- Message signing and verification
|
||||
- Duplicate detection tracking
|
||||
|
||||
## Refactoring Strategy
|
||||
1. Extract each component while maintaining exact functionality
|
||||
2. Use dependency injection for component communication
|
||||
3. Ensure all existing tests pass
|
||||
4. Maintain the same public API
|
||||
|
||||
## Benefits
|
||||
- Easier to test individual components
|
||||
- Better separation of concerns
|
||||
- More maintainable code
|
||||
- Easier to add new features
|
||||
- Better code reuse
|
||||
Reference in New Issue
Block a user