Hmm... maybe. The whole Queue thing is already re-implemented in the new code, but it may be of some use if you could also disable those threads as well. I'll keep a note.
On Apr 7, 1:57 am, whome <[email protected]> wrote: > > Yes, this is the dirty way of doing it. By the way I have added an > > enhancement request for this > > issue:http://code.google.com/p/smslib/issues/detail?id=202 > > I see, now I noticed this comment. Nice, I will appreciate this if can > minimize the background overhead on special use-cases. After exploring > a source code could same rule be applied to AGateway.QueueManager > inner class task? > * AGateway.QueueManager: if understood properly it sends queued > outgoing messages, but its no use if user app send&read messages > without callbacks. > * ModemGateway.getQueueSchedulingInterval: hardcoded 5sec queuemanager > interval > > If I (or anyone else) don't need an asyncronous sending or call > service.queueMessage(msg) method its no use. A simple failsafe would > do fine, call sendMessage if user accidentally called queueMessage but > a task was disabled. Do you think its a safe? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SMSLib User Group" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/SMSLib?hl=en -~----------~----~----~----~------~----~------~--~---
