sacco_mobile/lib/features/profile/views/profile_screen.dart (1)

45-73: 🛠️ Refactor suggestion

Avoid recreating ProfileViewModel every frame – lift it out of build.

ChangeNotifierProvider(create: …) inside build leads to a fresh ViewModel each rebuild, wiping state (memberProfile, tab data, errors).
Move it to initState or use .value:

-class _ProfileScreenState extends State<ProfileScreen>
-    with SingleTickerProviderStateMixin {
-  late TabController _tabController;
+class _ProfileScreenState extends State<ProfileScreen>
+    with SingleTickerProviderStateMixin {
+  late TabController _tabController;
+  late final ProfileViewModel _viewModel = getIt<ProfileViewModel>();
@@
-    return ChangeNotifierProvider(
-      create: (_) => getIt<ProfileViewModel>(),
+    return ChangeNotifierProvider.value(
+      value: _viewModel,

This preserves network results across orientation changes and prevents duplicate API calls.

sacco_mobile/linux/flutter/generated_plugin_registrant.cc (1)

1-19: Be cautious about direct edits to generated files.

While the changes to register the FileSelectorPlugin are technically correct and align with the document upload functionality mentioned in the PR objectives, this is an auto-generated file as indicated by the comment at the top. Instead of manual edits, the recommended approach is to add the file_selector dependency to your pubspec.yaml file and let Flutter regenerate these files during the build process.

Make sure that the file_selector plugin is properly added to your pubspec.yaml dependencies:

dependencies:
  file_selector: ^[version]

After adding the dependency, run flutter pub get to update your dependencies and regenerate the platform-specific plugin files automatically.

sacco_mobile/lib/features/loans/views/loan_detail_screen.dart (1)

699-703: Division‑by‑zero guard for monthly‑payment calculation

If termMonths were ever 0 (e.g., corrupt data), this would raise a IntegerDivisionByZeroException.

- return loan.totalAmountPayable / loan.termMonths;
+ return loan.termMonths == 0
+     ? 0
+     : loan.totalAmountPayable / loan.termMonths;

Consider surfacing an error or fallback UI when the term is invalid.

sacco_mobile/lib/features/loans/viewmodels/loan_repayment_viewmodel.dart (2)

110-119: Document the penalty calculation business rules.

The method includes a comment mentioning this is an example calculation, but in a production app, actual business rules should be clearly documented.

// Calculate penalty amount (if any)
double calculatePenalty(Loan loan) {
  // Check if there are any missed payments
  if (loan.missedPaymentsCount > 0) {
-   // Example penalty calculation: 5% of outstanding balance per missed payment
-   // This is just an example, actual calculations would depend on business rules
+   // Penalty calculation: 5% of outstanding balance per missed payment
+   // Business Rule: For each missed payment, add 5% penalty on the outstanding balance
+   // Example: If outstanding balance is 1000 and 2 payments are missed, penalty is 100 (1000 * 0.05 * 2)
    return loan.outstandingBalance * 0.05 * loan.missedPaymentsCount;
  }
  return 0.0;
}

---

38-49: Consider adding more detailed error return information.

The method currently returns just a boolean success status. Consider enhancing error reporting with more details.

- Future<bool> makeRepayment({
+ Future<Map<String, dynamic>> makeRepayment({
  required int loanId,
  required double amount,
  required String paymentMethod,
  String? description,
}) async {
  if (_selectedLoan == null) {
    _errorMessage = 'No loan selected';
    notifyListeners();
-   return false;
+   return {'success': false, 'error': 'No loan selected'};
  }

And update the return statements throughout the method accordingly.

sacco_mobile/lib/features/loans/views/loan_list_screen.dart (3)

191-359: Extract loan card widgets to separate component files.

Both _buildLoanCard and _buildHistoryLoanCard methods are quite large and could be extracted into their own widget classes to improve maintainability and testability.

Create separate files for these components:

1. loan_card.dart for the active loan card
2. history_loan_card.dart for the loan history card

This approach would make the main file more manageable and the components reusable across the app.

Also applies to: 361-458

---

299-305: Use a more semantic approach for loan progress indication.

The current implementation uses the generic LinearProgressIndicator. Consider using a more domain-specific component that better communicates the loan payoff progress.

- LinearProgressIndicator(
-   value: loan.progressPercentage / 100,
-   backgroundColor: Colors.grey[200],
-   valueColor: AlwaysStoppedAnimation<Color>(
-     _getStatusColor(loan.status),
-   ),
- ),
+ // Create a custom LoanProgressIndicator
+ LoanProgressIndicator(
+   progressPercentage: loan.progressPercentage,
+   statusColor: _getStatusColor(loan.status),
+ ),

Where LoanProgressIndicator could be a custom widget that shows more contextual information about the loan payoff status.

---

521-538: Use an extension method for status color mapping.

The _getStatusColor method could be better implemented as an extension method on the loan status, which would make it more reusable across different screens.

Create an extension like this in a separate file:

// loan_status_extensions.dart
extension LoanStatusExtension on String {
  Color getStatusColor({bool light = false}) {
    switch (this) {
      case 'PENDING':
        return light ? Colors.amber[100]! : Colors.amber[700]!;
      case 'APPROVED':
        return light ? Colors.blue[100]! : Colors.blue[700]!;
      // ... other cases
      default:
        return light ? Colors.grey[200]! : Colors.grey[700]!;
    }
  }
}

Then update usage to:

loan.status.getStatusColor(light: true)

sacco_mobile/lib/features/loans/viewmodels/loan_application_viewmodel.dart (2)

170-177: Refactor getLoanTypeDetails to use orElse parameter instead of try-catch.

Using try-catch for control flow is inefficient when the firstWhere method provides a cleaner alternative with the orElse parameter.

Map<String, dynamic>? getLoanTypeDetails(String loanType) {
-  try {
-    return _loanTypes.firstWhere((type) => type['value'] == loanType);
-  } catch (e) {
-    return null;
-  }
+  return _loanTypes
+      .where((type) => type['value'] == loanType)
+      .firstOrNull;
}

Or use the orElse parameter correctly:

Map<String, dynamic>? getLoanTypeDetails(String loanType) {
  return _loanTypes.firstWhere(
    (type) => type['value'] == loanType,
    orElse: () => <String, dynamic>{},
  ).isEmpty ? null : _loanTypes.firstWhere((type) => type['value'] == loanType);
}

---

146-152: Document expected input format for financial calculations.

The financial calculation methods don't clearly document the expected format for inputs. Adding clear documentation would help prevent calculation errors.

// Calculate monthly payment
+ /// Calculates the monthly payment amount for a loan.
+ /// 
+ /// Parameters:
+ /// - amount: The principal loan amount (e.g., 10000)
+ /// - rate: The annual interest rate as a percentage (e.g., 15.0 for 15%)
+ /// - term: The loan term in months (e.g., 24 for 2 years)
+ /// 
+ /// Returns the monthly payment amount.
double calculateMonthlyPayment(double amount, double rate, int term) {
  final monthlyRate = rate / 100 / 12;
  final payment = (amount * monthlyRate * pow((1 + monthlyRate), term)) /
                (pow((1 + monthlyRate), term) - 1);
  return payment;
}

sacco_mobile/lib/features/savings/views/deposit_screen.dart (2)

110-122: Input formatter disallows decimal amounts.

FilteringTextInputFormatter.digitsOnly blocks “12.50” or “1000.75”, yet the back‑end accepts fractional values (double.parse is used later). Switch to a regex‑based formatter that permits one optional decimal point:

- inputFormatters: [
-   FilteringTextInputFormatter.digitsOnly,
- ],
+ inputFormatters: [
+   FilteringTextInputFormatter.allow(RegExp(r'^\d+\.?\d{0,2}$')),
+ ],

---

31-35: Minor: Use the current locale instead of hard‑coding 0 decimal digits.

If the product later supports currencies that require cents, hard‑coding decimalDigits: 0 will silently round user data.

- decimalDigits: 0,
+ decimalDigits: NumberFormat.compactSimpleCurrency(locale: 'en').decimalDigits ?? 2,

sacco_mobile/lib/features/savings/views/withdraw_screen.dart (2)

110-122: Decimal amounts are blocked for withdrawals as well.

Mirror the regex change suggested for the deposit screen so users can withdraw non‑integer figures.

---

399-418: Race‑condition possibility – user can tap “Withdraw” twice.

Because _submitWithdrawal awaits makeWithdrawal after showing the confirmation dialog, the user can spam the button before state switches to loading. Disable the button immediately after the dialog is accepted to guard against duplicate requests, or track an internal _isSubmitting flag.

sacco_mobile/lib/features/savings/views/savings_account_screen.dart (1)

400-408: Arrow direction for deposit / withdrawal is counter‑intuitive.

Conventionally:
• Deposit → arrow up ( money coming into the account )
• Withdrawal → arrow down ( money going out )

Consider swapping the icons so the UI communicates intent more clearly.

sacco_mobile/lib/features/savings/views/transaction_detail_screen.dart (2)

17-23: Avoid re‑creating expensive NumberFormat / DateFormat objects every build.

intl formatters allocate native resources; caching them enhances performance:

static final _currencyFormat = NumberFormat.currency(symbol: 'UGX ', decimalDigits: 0);
static final _dateFormat     = DateFormat('dd MMMM, yyyy');
static final _timeFormat     = DateFormat('hh:mm a');
...
Widget build(BuildContext context) {
  return Scaffold(
    ...
    Text(_currencyFormat.format(transaction.amount))

---

250-278: Fixed 140 px label width can truncate text on small devices / large font scales.

Switch to Flexible/Expanded widgets or use LayoutBuilder to allocate space dynamically, improving accessibility:

- SizedBox(
-   width: 140,
-   child: Text(label, ...),
- ),
+ Flexible(
+   flex: 3,
+   child: Text(label, overflow: TextOverflow.fade, softWrap: false, ...),
+ ),

sacco_mobile/lib/features/savings/views/all_transactions.dart (2)

623-629: “This Week” computation assumes Sunday‑based weeks.

today.weekday % 7 makes Sunday the first day; most locales consider Monday the first weekday.
Prefer the DateTime.monday constant or the intl package’s week‑of‑year helpers to avoid regional confusion.

---

756-775: Repeated ! assertions on color shades risk null crashes on custom themes.

Colors.orange[700]! is safe with the default palette but can return null when the primary swatch is overridden.
Either keep the nullable type and provide a fallback or use ColorScheme from the app theme.

sacco_mobile/lib/features/savings/viewmodels/transaction_viewmodel.dart (1)

67-70: Setting state to loading on every pagination request causes UI flicker.

When _page > 1, consider a separate loadingMore flag or keep _state as success and expose a boolean isPaginating to avoid replacing the entire list with a loader.

sacco_mobile/lib/features/profile/views/next_of_kin_form_screen.dart (2)

137-159: Consider extracting relationship dropdown data to constants.

The relationship options are hardcoded in the widget. For maintainability, consider moving these to a constants file or fetching them from an API if they might change in the future.

- items: const [
-   {'value': 'SPOUSE', 'label': 'Spouse'},
-   {'value': 'CHILD', 'label': 'Child'},
-   {'value': 'PARENT', 'label': 'Parent'},
-   {'value': 'SIBLING', 'label': 'Sibling'},
-   {'value': 'OTHER', 'label': 'Other'},
- ],
+ items: AppConstants.relationshipOptions,

And in your constants file:

static const List<Map<String, String>> relationshipOptions = [
  {'value': 'SPOUSE', 'label': 'Spouse'},
  {'value': 'CHILD', 'label': 'Child'},
  {'value': 'PARENT', 'label': 'Parent'},
  {'value': 'SIBLING', 'label': 'Sibling'},
  {'value': 'OTHER', 'label': 'Other'},
];

---

232-257: Consider allowing decimal input for percentage share.

The percentage share field only allows integer input through FilteringTextInputFormatter.digitsOnly, but is validated and stored as a double. Consider allowing decimal input for more precise percentage allocation.

- inputFormatters: [
-   FilteringTextInputFormatter.digitsOnly,
- ],
+ inputFormatters: [
+   FilteringTextInputFormatter.allow(RegExp(r'^\d*\.?\d*$')),
+ ],

sacco_mobile/lib/features/profile/views/document_viewer.dart (2)

21-33: Download functionality needs implementation.

The download functionality is currently a placeholder with a TODO comment. Consider implementing this feature or creating a follow-up task to track this work.

Would you like me to suggest an implementation for the document download functionality? This could utilize Flutter's path_provider and dio packages to download and save files to the device.

---

120-156: PDF viewer implementation needed.

The code includes a commented-out implementation for a PDF viewer. Consider either implementing this functionality with the flutter_pdfview package or removing the commented code and creating a separate task for this feature.

Would you like me to provide guidance on implementing the PDF viewer using flutter_pdfview or another recommended package?

sacco_mobile/lib/features/profile/views/edit_profile_screen.dart (1)

176-194: Consider adding currency formatting for better UX.

The monthly income field would benefit from currency formatting to improve readability and user experience.

  // Monthly Income Field
  AppTextField(
    controller: _monthlyIncomeController,
    labelText: 'Monthly Income (UGX)',
    hintText: 'Enter your monthly income',
    keyboardType: TextInputType.number,
    inputFormatters: [
      FilteringTextInputFormatter.digitsOnly,
+     CurrencyTextInputFormatter(
+       locale: 'en_UG',
+       symbol: 'UGX ',
+       decimalDigits: 0,
+     ),
    ],
    validator: (value) {
      if (value == null || value.isEmpty) {
        return 'Please enter your monthly income';
      }
-     if (double.tryParse(value) == null) {
+     if (double.tryParse(value.replaceAll(RegExp(r'[^0-9.]'), '')) == null) {
        return 'Please enter a valid amount';
      }
      return null;
    },
  ),

You'll need to add the currency_text_input_formatter package to your pubspec.yaml:

currency_text_input_formatter: ^2.1.11

sacco_mobile/lib/features/profile/views/document_upload_screen.dart (2)

11-18: Prefer a strongly‑typed enum over string literals for documentType.

Using the raw strings 'ID' / 'PHOTO' ties correctness to spelling and letter‑case.
A small typo later ('Photo') would silently bypass your if in _uploadDocument and break uploads at runtime.

+enum DocumentType { id, photo }

 class DocumentUploadScreen extends StatefulWidget {
-  final String documentType; // 'ID' or 'PHOTO'
+  final DocumentType documentType;
   final String documentTitle;
@@
-    required this.documentType,
+    required this.documentType,

Adapt comparisons:

-if (widget.documentType == 'PHOTO') {
+if (widget.documentType == DocumentType.photo) {

The refactor provides compile‑time safety and IDE autocompletion.

---

95-115: Button‑enable logic can be simplified and made more robust.

Currently the “Select from Gallery / Take Photo” buttons are only disabled when BOTH _selectedFile != null and state == loading.
During an upload, _selectedFile is non‑null, so it works, but the double condition is unnecessary and slightly brittle.

-onPressed: _selectedFile != null && viewModel.state == ProfileState.loading
+onPressed: viewModel.state == ProfileState.loading

(Same for the camera button.)

This keeps the intent clear: “disable interaction while an upload is running”, regardless of current selection.

Also applies to: 121-127

sacco_mobile/lib/features/profile/views/profile_screen.dart (2)

169-176: Pass a typed DocumentType rather than raw strings when navigating.

As noted on the upload screen, using string literals like 'PHOTO' / 'ID' is error‑prone.
After introducing the DocumentType enum, update navigation:

-documentType: 'PHOTO',
+documentType: DocumentType.photo,

Same for 'ID'. This guarantees compile‑time checking across screens.

Also applies to: 330-367

---

548-570: Hard‑coding a 120 px label column may break on small screens & RTL locales.

Wide labels or devices in portrait with very small width could overflow, while right‑to‑left languages will mis‑align.
Consider using IntrinsicWidth or Flex with Expanded(flex: …) instead of a fixed pixel width, and wrap the whole row in Directionality to respect RTL.

Not urgent, but improves accessibility and internationalisation.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro