تكرار السؤال: …
الإجابة المختصرة
WebSocket مناسب لتحديثات ثنائية الاتجاه شبه الفورية، بينما polling أبسط للتحديثات النادرة.
الشرح
يعتمد الاختيار على تكرار التحديث وكلفة التأخير. الاستطلاع الدوري (Polling) بسيط وبلا حالة على الخادم ويعمل مع أي بنية، لكنه يهدر طلبات عندما لا تتغير البيانات ويضيف تأخيرًا يصل إلى فترة الاستطلاع. أما WebSocket فيفتح اتصالًا طويلًا ثنائي الاتجاه يدفع فيه الخادم التحديثات فور حدوثها، وهو مناسب للمحادثة والتداول وتتبع الموقع. لكنه يضيف مسؤوليات: إدارة دورة حياة الاتصال وإعادة الاتصال والمصادقة، وحدود الاتصالات المتزامنة على الخادم، واستهلاك البطارية. إذا كانت التحديثات نادرة أو من الخادم للعميل فقط فقد يكفي Server-Sent Events أو الاستطلاع، وللإشعارات في الخلفية يلزم FCM/APNs لأن اتصال WebSocket لا يبقى حيًا عندما يُغلق التطبيق.
مثال بالكود
// Polling: simple and stateless, but wasteful and delayed by up to the interval
final timer = Timer.periodic(const Duration(seconds: 15), (_) => repository.refresh());
// WebSocket: the server pushes updates immediately over one long-lived connection
final channel = WebSocketChannel.connect(Uri.parse('wss://api.example.com/live'));
final subscription = channel.stream.listen(
(message) => handle(jsonDecode(message as String) as Map<String, Object?>),
onError: (Object error) => debugPrint('socket error: $error'),
onDone: () => debugPrint('socket closed: ${channel.closeCode}'),
);
channel.sink.add(jsonEncode({'type': 'subscribe', 'topic': 'orders'}));أخطاء شائعة
- استخدام WebSocket لتحديث نادر (مرة كل دقائق) يمكن أن يخدمه طلب عادي، مما يزيد التعقيد دون فائدة.
- افتراض أن الاتصال يبقى مفتوحًا عندما يذهب التطبيق إلى الخلفية؛ يقطعه نظام التشغيل غالبًا، فلا بد من إعادة الاتصال عند العودة.
- الاستطلاع كل ثانية بدل التحول إلى الدفع من الخادم، فيرهق الخادم والبطارية.