I guess the easiest way to understand what is going on is to look at the code.
Find the method getManufacturer() in "src/java/org/smslib/modem/ ModemGateway.java" file. This is a typical ask-and-get-response method. You should lock on the "getDriver().getSYNCCommander()" object for the whole duration of your interaction with the AT commands. With the current design: 1) If some other activity is going on, you will be on-hold, as the SYNCCommander semaphone object is locked by someone else. 2) There is no way to interrupt the current activity in order to jump in and take priority. 3) When you start, everything else is on hold. The current method of passing AT commands to the modem is not the best one - its just a quick-and-dirty to pass an AT command. I plan to add more formal support for custom AT commands in the next version. On Apr 6, 2:33 pm, bodat <[email protected]> wrote: > Yes, for example there is an ongoing activity like sending or reading > or queuing then I issue an AT command what will be its priority? > > Will it wait for the ongoing activity to finish before it is being > executed? If that's the case, then is there a facility to halt other > ongoing activity and make this AT command be the first in priority? > > For me this another one important feature. Let say there are > cases that you need to issue an AT command and you like it > to be the first to be executed. This will cause other activity to > temporarily stop and resume after the command is fully executed. > > There are also cases that it is a series of AT command. > > Regards, > Rey. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
