On Apr 6, 10:35 pm, whome <[email protected]> wrote:
> Main reason to keep everything in a single thread (reading sms,
> sending sms) is an application logic. I do not need to create any
> artifical fifo queues for messages, I _must handle_ messages
> accordingly within the app logic thread. Doing my own read/send can
> keep calls in a strict order.
Fair enough :)
> If I set NULL to notfication its ok, I think you mean these three
> listeners?
> srv.setInboundNotification(null);
> srv.setOutboundNotification(null);
> srv.setCallNotification(null);
Yes - or just leave them alone. Nulls are the default values.
> Doing a loop described below I probably can disable KEEP_ALIVE command
> as well, its an overhead because am doing a constant read polling
> anyway. How do I disable isAlive() AT command. Do I put
> "Settings.SERIAL_KEEPALIVE_INTERVAL = Integer.MAX_VALUE" and be ok?
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
> Minimising smsLib background threads I can put "Settings.QUEUE_THREADS
> = 1" and should be safe?
This setting is a sin of the past (my past :)). Leave it as is and
just continue with your development - this configuration option will
dissapear in the next release.
> ps: I am using the following modem and seems to work fine, I have sent
> and read test sms messages (7-bit encoding).
> modem: Samba 55-SET GSM/GPRS modem
> identifiation: are manufacturer=SIEMENS, model=MC55
> site:http://www.openxtra.co.uk/accessories/sms-modems/samba55/prodsamba55....
Nicely packaged modem - I want one!
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
