Facing Bugs in AIPVST: Real Debugging Challenges, Permission Fixes & Play Store Safety

AIPVST पर काम करते समय मुझे एक बात बहुत जल्दी समझ आ गई थी—application बनाना और application को production-ready बनाना दो अलग चीजें हैं। UI सही दिख रही हो, APIs response दे रही हों और debug APK चल रहा हो, इसका मतलब यह नहीं कि application हर device पर smoothly काम करेगी या Google Play Store पर बिना किसी issue के approve हो जाएगी।

AIPVST एक छोटा application नहीं है। इसमें membership management, subscriptions, autopay, PhonePe payment gateway, live emergency help, location tracking, financial assistance, pension support, Kanyadaan, donations, support queries और admin-level reporting जैसे कई modules हैं।

इतने सारे modules के साथ bugs आना expected था। लेकिन कुछ issues ऐसे थे जो सिर्फ code देखकर solve नहीं हुए। उनके लिए actual devices, slow internet, denied permissions, payment callbacks और release builds पर बार-बार testing करनी पड़ी।

Debug Mode में सब ठीक, Release में Problem

Flutter development के दौरान सबसे confusing situation तब आती है जब application debug mode में perfectly काम करती है, लेकिन release APK या Play Store build में behaviour बदल जाता है।

AIPVST में भी शुरुआत में कुछ APIs debug build में सही चल रही थीं, लेकिन release build में loader रुक जाता था, response देर से आता था या user को proper error message नहीं मिलता था।

Problem सिर्फ API की नहीं थी। कई बार network timeout, invalid token, null response और screen dispose होने के बाद controller update होने जैसे छोटे issues मिलकर application को unstable बना रहे थे।

Dio Error Handling को Proper बनाना

हमने Dio requests को सिर्फ success response पर depend नहीं रखा। Timeout, no internet, server error और unauthorized response के लिए अलग handling की गई।

try {
  final response = await dio.get(
    endpoint,
    options: Options(
      headers: {
        'Authorization': 'Bearer $token',
      },
    ),
  );

  if (response.statusCode == 200) {
    // Process response
  } else {
    // Handle unexpected status
  }
} on DioException catch (e) {
  if (e.type == DioExceptionType.connectionTimeout) {
    // Show connection timeout message
  } else if (e.response?.statusCode == 401) {
    // Clear session and redirect to login
  } else {
    // Show safe fallback message
  }
}

यह code बहुत complicated नहीं है, लेकिन production application में यही छोटे safeguards बड़ा फर्क डालते हैं।

Debugging का मतलब सिर्फ error हटाना नहीं है। सही debugging वह है जिसमें user को application crash होने के बजाय clear और useful feedback मिले।

Duplicate API Calls और Multiple Loader Issue

कुछ screens पर एक ही API दो या तीन बार call हो रही थी। इसका कारण कभी onInit(), कभी widget rebuild और कभी navigation के बाद controller दोबारा initialize होना था।

इससे तीन problems हो रही थीं:

• Server पर unnecessary requests जा रही थीं।
• एक ही data बार-बार load हो रहा था।
• Loader जल्दी बंद या लगातार active रह जाता था।

GetX controllers में initialization और refresh logic को अलग किया गया। साथ ही loading flags को ऐसे manage किया गया कि एक request complete होने से पहले दूसरी duplicate request start न हो।

if (isLoading.value) return;

try {
  isLoading.value = true;
  await fetchData();
} finally {
  isLoading.value = false;
}

Simple guard condition ने कई random UI issues खत्म कर दिए।

Live Help और Location Permission की असली Challenge

AIPVST का Live Help module project का सबसे important हिस्सा है। User emergency के समय location share कर सकता है और authorized team distance देखकर call या direction open कर सकती है।

Location feature बनाना आसान लग सकता है, लेकिन Android permissions के साथ कई edge cases आते हैं:

• User ने location permission deny कर दी।
• Permission allow है, लेकिन GPS बंद है।
• User ने “Don’t ask again” select कर दिया।
• Precise location की जगह approximate location मिली।
• Permission dialog के बाद screen rebuild हो गई।
• Location मिलते-मिलते request timeout हो गई।

शुरुआत में सिर्फ permission request करने के बाद location fetch की जा रही थी। लेकिन real devices पर यह flow reliable नहीं था।

Correct Permission Flow

Final implementation में permission से पहले service status check किया गया। उसके बाद permission status check किया गया और permanently denied होने पर user को application settings खोलने का option दिया गया।

if (!await locationServiceEnabled()) {
  showEnableLocationMessage();
  return;
}

final permission = await checkLocationPermission();

if (permission == denied) {
  await requestLocationPermission();
}

if (permission == permanentlyDenied) {
  openAppSettings();
  return;
}

यहाँ एक important बात थी—permission deny होने पर application को blank या stuck नहीं होना चाहिए। User को simple Hindi-English message दिया गया कि location क्यों जरूरी है और उसे settings से कैसे enable करना है।

उदाहरण:

Live Help के लिए आपकी location आवश्यक है। कृपया location permission allow करें ताकि सहायता टीम आपकी सही position तक पहुँच सके।

Play Store-Safe Permission Handling

Google Play Store पर application publish करते समय permissions बहुत carefully handle करनी पड़ती हैं। Development के दौरान कई बार developers सभी possible permissions manifest में add कर देते हैं, लेकिन production में यह सही approach नहीं है।

हमने AIPVST में principle रखा:

“जो permission feature के लिए जरूरी है, सिर्फ वही permission request करनी है।”

Location Permission

Live Help और direction features के लिए location जरूरी है। लेकिन background location की जरूरत हर स्थिति में नहीं थी, इसलिए unnecessary background tracking permission avoid की गई।

जब user Live Help या location-related feature use करता है, तभी permission मांगी जाती है। Application open होते ही बिना context के location popup दिखाना user experience और Play Store review—दोनों के लिए सही नहीं है।

Notification Permission

Android 13 और उसके बाद notifications के लिए runtime permission जरूरी है। इसे भी app launch पर force नहीं किया गया। User को पहले बताया गया कि notification किसलिए चाहिए—जैसे assistance updates, membership alerts या payment information।

<uses-permission
    android:name="android.permission.POST_NOTIFICATIONS" />

Permission request से पहले छोटा explanation दिखाने से user को trust मिलता है और denial rate कम होता है।

Photo and Media Permission

Member profile या document upload के लिए पूरे device storage का access मांगना जरूरी नहीं था। Modern Android versions के लिए selective photo access और system picker को prefer किया गया।

पुरानी broad storage permissions को blindly use करना Play Store policy issue बन सकता है।

Data Safety और Privacy Policy

Play Store listing में सिर्फ permissions सही होना काफी नहीं है। Data Safety form में यह clearly mention करना पड़ता है कि application कौन-सा data collect करती है और क्यों।

AIPVST जैसे platform में निम्न data हो सकता है:

• Name और mobile number
• Member profile information
• Location during Live Help
• Payment and transaction references
• Uploaded profile image
• Support query information

इन details को hide करने के बजाय privacy policy और Data Safety section में transparent तरीके से explain करना जरूरी था।

Play Store safety सिर्फ approval पाने के लिए नहीं है। यह user को यह भरोसा देने के लिए है कि उसकी information बिना वजह collect या misuse नहीं की जाएगी।

PhonePe Payment में Success लेकिन App में Pending

Payment integration के दौरान सबसे common और serious issue था—user ने payment complete कर दी, लेकिन application में transaction pending दिखाई दे रही थी।

ऐसा इसलिए हो सकता है क्योंकि payment app से वापस आने के बाद सिर्फ client-side result पर भरोसा करना safe नहीं है। Payment status backend से verify करना जरूरी है।

हमने payment flow को इस तरह रखा:

1. Backend से payment order create किया गया।
2. User को PhonePe payment flow पर भेजा गया।
3. Application return होने के बाद payment status API call की गई।
4. Final status server-side response से update किया गया।
5. Pending होने पर कुछ समय बाद status recheck करने का option रखा गया।

Payment screen पर सिर्फ “Payment Successful” दिखा देना पर्याप्त नहीं है। Server verification जरूरी है, वरना network interruption के कारण गलत status save हो सकता है।

Autopay Status Mismatch

कुछ members का autopay backend में active था, लेकिन mobile application में inactive दिखाई देता था। यह bug देखने में छोटा था, लेकिन membership system के लिए काफी important था।

Investigation के बाद पता चला कि अलग APIs में status values अलग format में आ रही थीं:

• 1 और 0
• "1" और "0"
• true और false
• ACTIVE और INACTIVE

Mobile side पर normalization की गई और backend responses को consistent format में बदला गया।

bool parseStatus(dynamic value) {
  return value == true ||
      value == 1 ||
      value == "1" ||
      value.toString().toLowerCase() == "active";
}

यह एक छोटा fix था, लेकिन इससे member list, profile और autopay dashboard—तीनों जगह status सही हो गया।

SharedPreferences और Old Session Data

कई बार user logout करके दूसरे account से login करता था, लेकिन पुराना member ID या token local storage में रह जाता था। इससे गलत profile load होने या unauthorized API response का issue आता था।

Logout के समय सिर्फ token remove करना पर्याप्त नहीं था। User से जुड़े सभी local keys clear करना जरूरी था।

await prefs.remove('token');
await prefs.remove('user_id');
await prefs.remove('member_id');
await prefs.remove('role_id');
await prefs.remove('profile_data');

कुछ settings जैसे theme preference को intentionally preserve किया गया, क्योंकि user को हर login पर theme दोबारा select नहीं करनी चाहिए।

Light और Dark Theme Persistence

Application में light और dark theme control दिया गया था। शुरुआत में theme switch screen पर change हो जाता था, लेकिन app restart करने के बाद फिर default theme दिखाई देती थी।

यह issue SharedPreferences में selected theme save करके और application initialization के समय value restore करके solve किया गया।

Theme सिर्फ UI feature नहीं है। अगर user ने dark mode select किया है, तो next launch पर भी वही preference रहनी चाहिए।

Long Lists और Performance Issues

AIPVST में हजारों members और payment records हैं। Member screen पर total records 2700 से ज्यादा होने के कारण सारे records एक साथ load करना practical नहीं था।

हमने list rendering और API queries में optimization किया:

• Pagination लागू की गई।
• Search को debounce किया गया।
• Images के लिए caching use की गई।
• Unnecessary widget rebuild कम किए गए।
• Loading और empty states अलग बनाए गए।

Search field में हर character पर API call होने की जगह थोड़ी delay के बाद request भेजी गई।

debounce(
  searchText,
  (_) => fetchMembers(),
  time: const Duration(milliseconds: 500),
);

इससे server load कम हुआ और typing experience भी smooth हुआ।

CI4 APIs में Validation और Safe Responses

Backend CodeIgniter 4 पर बना है। शुरुआती APIs में कुछ endpoints missing parameters पर direct database query चला देते थे, जिससे error response inconsistent हो जाता था।

बाद में हर important endpoint पर validation और standard JSON structure रखा गया:

{
  "status": true,
  "message": "Members fetched successfully",
  "data": []
}

Error response भी predictable रखा गया:

{
  "status": false,
  "message": "Required parameters are missing",
  "data": []
}

इससे Flutter side पर अलग-अलग response formats handle करने की जरूरत कम हुई।

Real Device Testing क्यों जरूरी था?

Emulator पर बहुत सारी चीजें सही चलती हैं, लेकिन real mobile पर behaviour अलग हो सकता है। AIPVST को अलग-अलग Android versions, screen sizes और network conditions पर test किया गया।

Testing के दौरान खास तौर पर check किया गया:

• Slow mobile network पर API behaviour
• GPS off होने पर Live Help flow
• Permission denied और permanently denied cases
• Payment app से वापस आने का flow
• Application background से resume होना
• Large member और payment lists
• Hindi text wrapping और overflow
• Dark mode और light mode consistency

कई bugs code review में नहीं मिले। वे सिर्फ तभी सामने आए जब app को actual user की तरह use किया गया।

इस Project से क्या सीखा?

AIPVST पर debugging करते समय सबसे बड़ा lesson यह था कि production application में केवल happy path नहीं देखना चाहिए।

User हमेशा permission allow नहीं करेगा। Internet हमेशा fast नहीं होगा। Payment response हमेशा तुरंत नहीं आएगा। API हमेशा expected data नहीं देगी।

इसलिए हर important feature के लिए हमें सोचना पड़ा:

• अगर internet नहीं है तो क्या होगा?
• अगर API timeout हो जाए तो क्या होगा?
• अगर permission deny हो जाए तो user आगे कैसे जाएगा?
• अगर payment pending हो तो status कैसे verify होगा?
• अगर old session data बचा हो तो क्या होगा?
• अगर list में हजारों records हों तो app कैसे perform करेगी?

“Code चल रहा है” development का अंत नहीं है। असली काम तब पूरा होता है जब application errors, weak network, denied permissions और unexpected user actions के बाद भी stable रहे।

Final Result

कई rounds की debugging, API improvements, permission handling और real-device testing के बाद AIPVST को production-ready बनाया गया।

आज application Google Play Store पर available है और membership, live emergency help, subscriptions, autopay, PhonePe payments, donations, pension assistance, Kanyadaan और community welfare programs जैसे complex workflows को एक platform पर manage कर रही है।

इस project ने मुझे सिर्फ Flutter या CodeIgniter 4 के बारे में नहीं सिखाया। इसने यह सिखाया कि एक reliable application बनाने के लिए frontend, backend, permissions, payments, privacy और user behaviour—सभी को एक साथ समझना पड़ता है।

और honestly, यही debugging का सबसे interesting हिस्सा है—हर solved bug application को थोड़ा और stable, secure और user-friendly बना देता है।