Unread और Total messages: असल में मतलब क्या है?

Unread (अपठित) क्या है?

Unread का मतलब आम तौर पर उन संदेशों की संख्या होती है जिन्हें सिस्टम ने “पढ़ा हुआ” मार्क नहीं किया है। “पढ़ा हुआ” मार्क होना कई तरीकों से तय किया जा सकता है: आपने message खोला, preview किया, conversation thread में स्क्रॉल किया, या server ने “seen/read” event रिकॉर्ड किया। अलग-अलग ऐप्स का नियम अलग हो सकता है, लेकिन बेसिक concept यही है: read-state flag।

Total messages क्या है?

Total का मतलब उस फोल्डर/इनबॉक्स/थ्रेड में मौजूद कुल messages की संख्या है— चाहे वो पढ़े हुए हों या नहीं, archive हों या inbox में हों (यह नियम भी design पर निर्भर है)। कई सिस्टम में “Total” एक filtered view का total होता है (जैसे केवल “Inbox” के messages), जबकि “All mail” अलग total दिखा सकता है।

आसान लाइन में: Unread = state-based subset, Total = overall count। इसलिए ये दोनों हमेशा अलग होंगे, और कभी-कभी “unread 0” लेकिन “total 300” बिल्कुल normal है।

Status update क्या होता है? (Flags और counters की दुनिया)

ऐप में किसी message के साथ कुछ status flags होते हैं—जैसे: is_read, is_deleted, is_archived, is_spam, has_attachment आदि। UI पर जो counters दिखते हैं, वो इन flags पर aggregation करके निकाले जाते हैं।

उदाहरण: Unread count = उन messages की गिनती जहाँ is_read = false और message उस view में शामिल है (जैसे inbox)। Total count = उन messages की गिनती जहाँ message उस view में शामिल है (read/unread दोनों)। यानी counters वास्तव में queries या indexes का output होते हैं।

क्यों “स्टेटस” बदलते हैं?

• यूज़र ने message खोलकर पढ़ लिया
• यूज़र ने “Mark as read/unread” किया
• किसी rule/filter ने message को किसी folder में move किया
• server sync ने नए messages खींचे या delete/expire किया
• multi-device पर read status बदल गया

जब भी इनमें से कोई action होता है, सिस्टम counters को अपडेट करता है—कभी तुरंत, कभी delay के साथ। यहीं से mismatch की समस्याएँ शुरू हो सकती हैं।

Unread count कैसे बनता है: step-by-step

मान लीजिए आपके पास 10 messages हैं। उनमें से 3 आपने नहीं खोले। सामान्य रूप से Unread = 3। लेकिन real apps में ये इतना सरल नहीं रहता, क्योंकि read-state तय करने के rules अलग हो सकते हैं।

Rule 1: “Open” बनाम “Preview”

कुछ apps में message को केवल list में preview करने से unread नहीं हटता, लेकिन कुछ apps (या कुछ सेटिंग्स) में notification expand करने से भी message read mark हो सकता है। इसलिए आप सोचते हैं “मैंने तो पढ़ा नहीं”, पर सिस्टम ने mark कर दिया।

Rule 2: Conversation threading

अगर messages thread में grouped हैं, तो read/unread logic thread-level भी हो सकती है। एक thread में 5 messages हैं, आपने आखिरी message खोला, तो ऐप पूरे thread को read मान ले सकता है, या केवल उस message को। ऐसे में Unread count का behavior अलग दिखेगा।

Rule 3: Server authoritative बनाम client authoritative

कुछ सिस्टम में server “final truth” होता है: read receipt server पर अपडेट होगा तभी unread घटेगा। दूसरे सिस्टम में client local state तुरंत बदल देता है और बाद में server sync करता है। Slow network में दोनों के बीच फर्क दिख सकता है।

Total messages count: क्यों यह भी simple नहीं होता?

“Total” सुनते ही लगता है “बस गिनती”—लेकिन इसमें भी design choices होते हैं: क्या total में archived शामिल है? deleted शामिल है? spam शामिल है? expired temp mails शामिल हैं? अलग-अलग view अलग query चलाते हैं, इसलिए total हर screen पर अलग हो सकता है।

Folder/View आधारित total

• Inbox total: केवल inbox में मौजूद messages
• All mail total: inbox + archive + अन्य labels
• Filtered total: search/filter के बाद बची हुई लिस्ट की संख्या

इसलिए कभी-कभी user कहता है: “मेरे पास तो 50 mails हैं, total 120 क्यों दिखा रहा?” —क्योंकि वो 120 किसी दूसरे scope का total हो सकता है (उदाहरण: All mail, या server-side stored history)।

Badge count और UI count अलग क्यों दिखते हैं?

मोबाइल में app icon पर badge संख्या दिखती है। कई users इसे unread समझते हैं, लेकिन badge का source अक्सर अलग होता है: push notification payload, OS badge rules, या cached counters।

Common कारण

• Push delay: नया mail आया, push ने badge बढ़ाया, लेकिन app ने अभी sync नहीं किया
• Local cache: app ने local storage में पुराना unread रखा, refresh नहीं हुआ
• Multiple accounts: badge सभी accounts का sum दिखा सकता है, लेकिन inbox स्क्रीन सिर्फ एक account दिखा रही हो
• Notification grouping: OS ने कुछ notifications group कर दीं, badge behavior बदल गया

इसलिए “Unread 0” और badge “2” दिखना असंभव नहीं है—यह sync timing और counting scope का mismatch है।

Multi-device और sync: असली game-changer

आज लोग एक ही account फोन, लैपटॉप, टैबलेट—सब पर खोलते हैं। आपने लैपटॉप पर mail पढ़ लिया, लेकिन फोन offline था। फोन पर unread तब तक दिखेगा जब तक sync नहीं होगा। इस बीच आप समझेंगे “फोन bug है”, जबकि यह expected behavior है।

Two-phase अपडेट

अक्सर systems दो चरणों में update करते हैं: पहले local UI update (optimistic), फिर server confirmation। या पहले server update, फिर clients को refresh event। दोनों designs में edge cases आते हैं, खासकर weak network में।

Conflicts भी हो सकते हैं

एक device message को unread mark करता है, दूसरा device उसे read mark करता है। server को तय करना पड़ता है कि final state क्या होगा (last-write-wins, versioning, या timestamp आधारित rules)। यदि conflict resolution स्पष्ट नहीं है, तो counters “jump” कर सकते हैं।

Filters, search, और sorting: काउंट बदलने का छुपा कारण

बहुत से apps “Unread” को सिर्फ उन messages पर लागू करते हैं जो current filter में दिख रहे हों। उदाहरण: आपने filter लगाया “Only with attachments”. अब Unread count उस filtered subset का हो सकता है, जबकि total count पूरे inbox का। UI में यदि labels साफ नहीं हैं, तो user को लगता है numbers गलत हैं।

Sorting और pagination

यदि inbox paginated है (जैसे 20 items per page), तो client केवल पहले page के messages का data रखता है। लेकिन counter server-side total होता है। कभी-कभी client “estimated count” दिखाता है और बाद में सही करता है। इसी वजह से loading के दौरान total/unread बदलते हुए दिख सकते हैं।

Status अपडेट कब होता है: event timeline समझें

एक typical flow इस तरह हो सकता है:

• message आता है → server stores → client fetch/sync → UI में दिखता है → unread बढ़ता है
• user message खोलता है → client marks read → server को read event भेजता है → server confirms → unread घटता है
• user delete करता है → client hides item → server delete/label update → total/filtered total बदलता है

अगर इनमें से कोई भी step delay या fail हो जाए, तो counters momentarily गलत या stale हो सकते हैं। अच्छे apps इस स्थिति में refresh संकेत (pull-to-refresh) या subtle sync indicator देते हैं।

Temp inbox/receive-only सिस्टम में यह कैसे लागू होता है?

Temporary inbox या receive-only email viewer में unread/total logic अक्सर और सरल होना चाहिए, क्योंकि “sent mail”, “drafts” जैसी जटिलताएँ नहीं होतीं। फिर भी कुछ चुनौतियाँ बनी रहती हैं: incoming mail का refresh interval, server-side retention/expiry, और message duplicate detection।

Expiry का असर

अगर messages auto-expire होते हैं, तो total count time के साथ घट सकता है। user को यह “delete” जैसा लगेगा, लेकिन वास्तव में retention policy के कारण cleanup हुआ होता है। इसलिए UI में स्पष्ट संकेत देना उपयोगी रहता है कि messages समय के बाद हटते हैं।

Polling बनाम push

कई temp inbox systems polling करते हैं (हर कुछ सेकंड में fetch)। polling delay के कारण unread count देर से बढ़ेगा। push का उपयोग हो तो immediate दिखेगा, लेकिन push और fetch mismatch से badge/preview inconsistencies आ सकती हैं।

Practical tips: numbers “गलत” लगें तो क्या check करें?

• Refresh/sync करें: नेटवर्क कमजोर हो तो state update pending हो सकता है
• Filters हटाकर देखें: search या label filter total/unread बदल देता है
• Multiple accounts verify करें: badge sum हो सकता है, स्क्रीन single account
• Archived/Spam folders check करें: कुछ systems unread को inbox से अलग scopes में भी गिनते हैं
• Device sync देखें: दूसरे device पर read किया हो तो state बदलना बाकी हो सकता है

और अगर आप developer हैं, तो आपके लिए सबसे जरूरी बात: UI में हमेशा clear करें कि count किस scope का है—Inbox, All, Filtered, या Account-level। clarity बढ़ेगी तो support tickets कम होंगे।

निष्कर्ष

Unread और Total messages एक ही चीज नहीं हैं। Unread एक state-based subset है, जबकि Total एक scope-based aggregation है। काउंट mismatch के पीछे अक्सर bug नहीं, बल्कि sync timing, filters, multi-device states, और server vs client authority जैसी डिजाइन realities होती हैं। जब आप यह logic समझ लेते हैं, तो UI में दिखने वाले status updates ज्यादा “predictable” लगने लगते हैं—और आप सही expectations के साथ inbox use करते हैं।