उल्का ऐप्स ऑफ़लाइन काम कैसे कर सकता है?

Question

यह उपयोगी है जब:

• सर्वर डाउन है और ग्राहक वास्तविक समय के लिए कनेक्ट नहीं कर सकता सिंक
• कोई इंटरनेट कनेक्टिविटी
• उपयोगकर्ता ऑनलाइन जाने के लिए नहीं चाहता है लेकिन आवेदन के साथ काम करना चाहता है;

Answer 1

हाँ! अधिकांश भाग के लिए यह पहले ही उल्का में लागू किया गया है।

यदि सर्वर से कनेक्शन खो गया है, तो ग्राहक अभी भी स्थानीय रूप से कार्य कर सकता है। डाटाबेस लिखने वाले क्लाइंट पर सफल होने लगते हैं और स्क्रीन पर तत्काल प्रतिबिंबित होते हैं। एक बार कनेक्शन फिर से स्थापित हो जाने के बाद उल्का सर्वर पर सभी लंबित विधि अनुरोध दोबारा भेज देगा और सर्वर से परिणामों के साथ क्लाइंट डिस्प्ले अपडेट करेगा। यह विलंबता मुआवजे का पूरा परिणाम है, ऑफ़लाइन होने पर सर्वर की तरह बहुत धीमा हो रहा है।

ग्राहक वर्तमान कनेक्शन की स्थिति देखने के लिए प्रतिक्रियाशील 'Meteor.status()' आउटपुट की निगरानी कर सकते हैं। उदाहरण के लिए आप एक पुन: कनेक्ट टाइमर के साथ पॉपअप ड्राइव करने के लिए Meteor.status का उपयोग कर सकते हैं और जीमेल की तरह 'अभी कनेक्ट करें' बटन का उपयोग कर सकते हैं।

संपादित करें: बेशक, उल्का जादू नहीं है। यदि आप ऑफ़लाइन होने पर 'रीलोड' दबाते हैं, या पृष्ठ से दूर नेविगेट करते हैं, तो आप अपना उल्का सत्र खो देंगे और जब तक आप नेटवर्क प्राप्त नहीं कर लेते तब तक फिर से शुरू नहीं कर पाएंगे। ऑफ़लाइन मोड वाले सभी वेब ऐप्स के बारे में यह सच है, इसलिए, यह आपके ऐप के उपयोगकर्ताओं को आश्चर्यचकित नहीं होना चाहिए।

Answer 2

कुछ और विकल्प हैं जो 'यदि आपका टैब बंद हो जाता है, या आप पुनः लोड करते हैं' को हल कर सकते हैं। मैंने अभी तक कोशिश नहीं की है लेकिन दिलचस्प लग रहा है।

https://github.com/awwx/meteor-offline-data:

उल्का ऑफलाइन डाटा

उल्का ऑफ़लाइन डेटा परियोजना के घर, एक "ऑफ़लाइन संग्रह" जो एक Meteor.Collection लपेटता को लागू करने: सर्वर से

डाटा है ब्राउजर डेटाबेस में लगातार संग्रहित, एप्लिकेशन को उपलब्ध कराने के बावजूद एप्लिकेशन को ऑफ़लाइन शुरू होता है।

उपयोगकर्ता द्वारा किए गए परिवर्तन ब्राउज़र डेटाबेस में भी सहेजे जाते हैं, यदि ब्राउज़र बंद है और फिर से खोला गया है तो उन्हें संरक्षित किया जाता है। अगली बार एप्लिकेशन ऑनलाइन जाता है सर्वर में परिवर्तन भेजे जाते हैं।

अपडेट ऑफ़लाइन होने पर भी एप्लिकेशन पर ब्राउज़र विंडो पर सक्रिय रूप से साझा किए जाते हैं।

और https://github.com/GroundMeteor/Meteor-GroundDB:

विशेषताएं:

लाइट पदचिह्न

ब्रॉड ब्राउज़र समर्थन क्रोम, सफारी, फ़ायरफ़ॉक्स और इंटरनेट एक्सप्लोरर 9 निवर्तन सामान्य उल्का करने के लिए।संग्रह अगर कोई स्थानीय स्टोरेज संग्रह संग्रह में परिवर्तन फिर से शुरू होता है विधियों का पुनर्गठन क्रॉस विंडो टैब ऑफ़लाइन अपडेट करने के लिए ऑफ़लाइन क्लाइंट-साइड केवल डेटाबेस का समर्थन करता है EJSON.minify और EJSON.maxify स्थानीय स्टोरेज में संपीड़ित डेटा भविष्य में वहां सर्वर साइड

Answer 3

पर कस्टमाइज़ संघर्ष हैंडलर हो जाएगा मैं एक विशेषज्ञ नहीं हूँ, लेकिन के लिए एक समाधान की कल्पना करते हैं:

एक गोली/सेल (यकीन है कि हम इस तरह के डिवाइस पर एक उल्का ढेर स्थापित कर सकते हैं नहीं पर नहीं

), लेकिन डेस्कटॉप पर, उपयोगकर्ता को ऑफलाइन उपलब्धता की आवश्यकता होती है जैसे बिक्री बिंदु, कुछ लेनदेन लॉगिंग, ए सीमित या अद्यतित उत्पाद सूची, मूल्य निर्धारण और सूची इत्यादि। (स्टॉक का उपयोग कर लेनदेन जो भौतिक रूप से स्थानीय नहीं है, को «पुष्टि (ऑफलाइन ऑर्डर)» (उस स्टॉक वाले स्थान पहले से ही बेच सकते हैं ऑफ़लाइन ऑर्डर द्वारा आरक्षित, क्योंकि उन्हें पता नहीं है, क्योंकि वे या अन्य उपयोगकर्ता ऑफ़लाइन हैं, विशेष रूप से यदि उपयोगकर्ता के पास स्टॉक है तो ऑफ़लाइन है)

इसके अलावा, कुछ विशेषताओं का उपयोग केवल तभी किया जा सकता है जब ऑनलाइन (एक और उल्का वेब ऐप का उपयोग करके)

बेशक, एप्लिकेशन के सभी हिस्सों को ऑफ़लाइन उपयोग नहीं किया जा सकता है: संवेदनशील रिकॉर्ड निर्माण, कुछ लेन-देन, खोज जो पूर्ण संग्रह की आवश्यकता है आदि। ऑफ़लाइन विशेषताएं स्थानीय मैक के माध्यम से काम करती हैं एक काम कर रहे स्थानीय पूर्ण स्टैक्ड उल्का के साथ हैन वेबसर्वर पहले से ही स्थापित है।

ओप्लोग इन ऑफ़लाइन डीबी को केंद्रीकृत सर्वर, प्रति उपयोगकर्ता एक विशिष्ट डीबी पर दर्पण संग्रह में सिंक करेगा, इसलिए उपयोगकर्ता के मशीन पर ऑफ़लाइन उपलब्ध सभी बड़े डेटा नहीं। विचार कुछ सुविधाओं की उपलब्धता को बनाए रखना है। हम सभी उपयोगकर्ताओं के ऑफ़लाइन लेन-देन के लिए अन्यथा केवल एक डीबी प्राप्त कर सकते हैं, लेकिन ओप्लॉग इन सभी लेन-देन को सभी उपयोगकर्ता के ऑफ़लाइन डीबी पर सिंक करेगा। हम इन रिकॉर्डों को पोस्ट और साफ़ कर सकते हैं ASAP, लेकिन गोपनीयता के लिए अच्छा नहीं है। सबसे अच्छा यह है कि क्लाइंट का ऑफलाइन डीबी - और केंद्रीकृत सर्वर पर एक प्रतिबिंबित होता है - इसमें केवल उस उपयोगकर्ता द्वारा बनाई गई रिकॉर्ड्स या जानकारी शामिल होगी जिसमें उपयोगकर्ता को प्रति उपयोगकर्ता एक विशिष्ट डीबी की आवश्यकता हो सकती है।

एक केंद्रीय सर्वर साइड फ़ंक्शन नियमित रूप से मान्य होगा और इन रिकॉर्ड्स को सभी उपयोगकर्ताओं के समेकित केंद्रीकृत डीबी में पोस्ट करेगा।

एक आसान तरीका: स्थानीय ऑफ़लाइन उल्का ऐप के साथ किए गए सभी लेनदेन जो उपलब्ध होने पर एक webservice पर लेनदेन पोस्ट करेंगे। बिक्री चालान संख्या:

हम 2 चालान नंबर की एक अवधारणा इस्तेमाल कर सकते हैं (इस तरह से, उन, 2 अनुप्रयोगों का उपयोग कर आगे पीछे जा रहा प्रबंधन करने के लिए नहीं है।) (? दस्तावेज़ ID) लेन-देन समय में उत्पन्न

अनुक्रमिक चालान संख्या: लेखांकन उद्देश्यों के लिए, बाद में उत्पन्न (जब ऑनलाइन और 15 से 20 सेकंड के दस्तावेज़ के लिए पुराना।हमें यकीन है कि सभी नए चालान कि उस अवधि में बनाया गया)

विचार यहाँ एक स्थानीय उल्का ढेर स्थानीय दृढ़ता की कार लेने, Oplog केंद्रीकृत दृढ़ता के साथ समन्वयन करना (जब तक हम asynchrone भेज वेब सेवा लेनदेन पोस्टिंग जब के लिए कहता है है के लिए पता ऑनलाइन, लेकिन हम बड़े डीबी के साथ ऑटो sinc खोला)

(आखिरकार, शायद बेहतर 2 अनुप्रयोग चल रहे हैं: स्थानीय पर, एक केंद्रीय सेवा और इन 2 बातों को एक साथ करने का तरीका, या एक ऑनलाइन और ऑफ़लाइन ऐप उपयोगकर्ता को प्राथमिकता में ऑनलाइन उपयोग करने और ऑफलाइन होने पर ऑफलाइन होने का एक सुविधाजनक तरीका है)

यदि अच्छा हो तो अच्छा होगा अधिक जानकार लोगों का ty एक कामकाजी तरीके का मूल्यांकन और दस्तावेज। मैंने अभी तक मूलभूत प्रक्रिया में अभी तक उल्का का उपयोग नहीं किया है।

धन्यवाद,

मार्क

Answer 4

लाइन के नीचे:

1) या तो पूरी तरह से ब्राउज़र वास्तविक सत्र (हर कब तक हर एप्लिकेशन द्वारा अनुरोध करने क्योंकि परिवर्तन मिला बचा सकता है?। ऐसा ऐप, हर 10 सेकंड पर्याप्त नहीं है, हमें हर घटना की ज़रूरत है)। क्या हम इसे फ़ायरफ़ॉक्स कहने में प्रोग्राम कर सकते हैं? (लेकिन इसे केवल एक बदलाव के लिए सबकुछ (एचटीएमएल, जेएस, मिनोमोन्गो डीबी इत्यादि) को बचाने की ज़रूरत होगी!)

2) या हमारे पास क्लाइंट साइड पूर्ण उल्का स्टैक स्थानीय सामान की देखभाल कर रहा है (अपने स्वयं के एक स्थानीय ऐप) लेकिन किसी भी तरह से अपने सीआरयूडी संचालन को किसी अन्य टैब या ब्राउज़र के उदाहरण में किसी अन्य ऑनलाइन ऐप में संचारित करना। (वह दूसरा ऐप वास्तविक रिमोट सर्वर द्वारा परोसा जाएगा) समस्या यह है कि ऐसे 2 ऐप्स संवाद कर सकते हैं। मुझे लगता है कि ब्राउज़र सुरक्षा कारणों से इसे रोक देगा)

एक और अधिक रचनात्मक विचार हो सकता है: क्लाइंट के ढेर पर ओप्लॉग सक्रिय करें। फिर, प्रत्येक बैक-ऑनलाइन और लगातार ऑनलाइन होने पर, वास्तविक ग्राहक के ओप्लॉग को मुख्य ऐप में निर्यात/आयात किया जा सकता है (

3) जब तक हम ग्राहक के उल्का से कॉल() अनुरोध नहीं भेज सकते सर्वर पर एक और उल्का ढेर के लिए पूर्ण ढेर। (क्या यह संभव है? वहाँ है उल्का में URL डोमेन सीमाओं के बारे में कुछ नियम)

लेकिन यह एक गोली पर एक पूर्ण उल्का ढेर होने की संभावना का समाधान नहीं होता (मैं कर रहा हूँ नहीं बारे में पता shuch बात संभव है)

नहीं