relnotes.html
来自「SMSLib一个很有用的程序,有服务平台和收发平台」· HTML 代码 · 共 173 行 · 第 1/2 页
HTML
173 行
<body>
<center><h2>Release Notes<br/>SMSLib for Java</h2></center>
<br>
SMSLib for Java is a Java API Library which can be used from Java applications in order to enable them to send and receive SMS text messages via a connected GSM Modem.
<br><br>
<strong>Examples applications.</strong>
<br>
In the distribution directory, you will find example applications, which will show you the basics of how to use SMSLib for Java. These are:
<ul>
<li><strong>SendMessage.java:</strong> This example shows you how to connect and send an SMS message from your GSM Modem.</li>
<li><strong>ReadMessages.java:</strong> This example shows you how to connect and read messages from your GSM Modem (synchronous mode).</li>
<li><strong>ReadMessagesAsync.java:</strong> This example shows you how to connect and read messages from your GSM Modem (asynchronous mode).</li>
</ul>
Please, see <a href="http://smslib.org" target="_new">http://smslib.org</a> for latest information.<br/>
This project is hosted on SourceForge.<br/>
This project is distributed under the LPGL license.
<br/><br/><br/><br/>
<strong><h3>Compiling (makefile).</h3></strong>
You need to have the JDK (preferable 1.5), Java Comm libraries and a <i>make</i> utility installed.<br/>
There are two makefiles available, one for Win32 and one for Linux<br/><br/>
<strong>Win32:</strong><br/>
To build the library and examples, run "make -f makefile.win32" from the command prompt.<br/>
To clean up the directories, run "make -f makefile.win32 clean" from the command prompt.<br/><br/>
<strong>Linux & Unices:</strong><br/>
To build the library and examples, run "make -f makefile.unix" from the command prompt.<br/>
To clean up the directories, run "make -f makefile.unix clean" from the command prompt.<br/>
<br><br><br>
<strong><h3>Revision History.</h3></strong>
<strong>Version 1.1 - April 21, 2006</strong>
<ul>
<li><strong>SMSLib API</strong> [<font color="#00aa00">Enhancement</font>]: Added support for reception of 7bit-encoded large messages, either in 8bit referencing mode or in 16bit referencing mode (used to be working only in 8bit referencing mode).</li>
<li><strong>SMSLib API</strong> [<font color="#00aa00">Enhancement</font>]: Added support for sending large messages. Currently, works <strong>only</strong> for 7bit encoded messages. Uses 16bit referencing mode. With this enhancement, <strong>SMSLib now fully supports sending and receiving large, 7bit-encoded messages</strong>.</li>
<li><strong>SMSLib API</strong> [<font color="#00aa00">Enhancement</font>]: Added back the calls to "flush()" method of the output stream (CSerialDriver.java).</li>
<li><strong>SMSLib API</strong> [<font color="#00aa00">Enhancement</font>]: Added a new exception, named <strong>OopsException</strong> ( :) ). I will be using it for "panic" situations that SMSLib may face. If you ever get such an exception, please provide the stack trace to me!</li>
</ul>
<br/>
<strong>Version 1.0.2 - April 20, 2006</strong>
<ul>
<li><strong>SMSLib API</strong>: Some timing changes were made in CSerialDriver.java.</li>
<li><strong>SMSLib API</strong> [<font color="#ff0000">Critical</font>]: A bug in <strong>setReceiveMode()</strong> method is corrected.</li>
<li><strong>SMSLib API</strong> [<font color="#00aa00">Enhancement</font>]: Removed the calls to "flush()" method of the output stream (CSerialDriver.java). The "flush" call seemed to create trouble on virtual comm ports when RxTx is used. It seems that without the "flush()" forced call, RxTx can now be used on virtual comm ports (on Win32 installations) without throwing any exceptions.</li>
</ul>
<br/>
<strong>Version 1.0.1 - April 13, 2006</strong>
<ul>
<li>Added SMSServer application. SMSServer application is the port of the older jSMSServer.</li>
</ul>
<br/>
<strong>Version 1.0 - First Public Release.</strong>
<br/><br/><br/>
<font size = "-2" color="blue">
For your convinience, here are the release notes of the latest jSMSEngine API. SMSLib project is based on jSMSEngine API.<br/><br/>
<strong>Version 2.1.0 (Compiled packages with JDK 1.5.x)</strong>
<ul>
<li><strong>jSMSEngine API</strong>: Java Documentation remarks have been removed from the code. I am preparing a new set of them. For the moment, consult the examples which have been enriched with extra comments.</li>
<li><strong>jSMSEngine API</strong>: Thanks to Martin Sulak, jSMSEngine API can now handle CMTI indications. This has some implications:
<ul>
<li>The first and greatest thing is that the GSM device does not need to support the disabling of new message indications in order to work with jSMSEngine API. In fact, the disableIndications() is not called at all at modem initialization. Plus, the CannotDisableIndications exception does not exist any more. The methods to enable or disable indications are called when switching to new receive mode (Synchronous, Synchronous Poll, Synchronous CNMI) but even if they fail nothing bad happens. There are a couple of warning messages that get displayed in order to inform you, but the application will continue to work.</li>
<li>Asynchronous message reading has now two forms: a POLLing one and a CNMI-aware one. The POLL method works like it used to. The CNMI method is actually a POLL method which is called not only when the time interval lapses but also when a message arrives. This is done by intercepting the CMTI modem responses and activating the callback function, just like when the POLL time lapses. Look at the ReadMessagesAsyncXXX examples for more info.</li>
</ul>
<li><strong>jSMSEngine API</strong>: Minor changes in regexp strings for getManufacturer(), getModel(), etc. to better handle incompatible responses.</li>
<li><strong>jSMSEngine API</strong>: Added small delay after "+++" command.</li>
<li><strong>jSMSEngine API</strong>: Modified CSerialBuffer.clearBuffer() which could cause infinent loops under some circumstances.</li>
<li><strong>jSMSEngine API</strong>: Added delay before retrying message sending when CMS errors appear.</li>
<li><strong>jSMSEngine API</strong>: Added code to remove extra blank lines returned by some GSM models.</li>
<li><strong>jSMSEngine API</strong>: Modified CSerialDriver class for faster parsing of responses.</li>
<li><strong>jSMSEngine API</strong>: Now using custom logger class. A new runtime property has been introduced: <strong>-Djsmsengine.debug.output=path-to-file</strong>. When used, all logger activity will be redirected to file "path-to-file". If not used, logger activity will be shown on stderr stream.</li>
</ul>
<br><br>
<strong>Version 2.0.9 (Compiled packages with JDK 1.5.x)</strong>
<ul>
<li><strong>jSMSEngine API</strong>: Code cleanup.</li>
<li><strong>jSMSEngine API</strong>: Added extra thread which calls isAlive() in regular intervals. This is done in order not to allow the physical comm connection to timeout and force a disconnection.</li>
<li><strong>jSMSEngine API</strong>: All method in AT Handlers now synced.</li>
<li><strong>jSMSEngine API</strong>: Fixed delay in disconnection.</li>
<li><strong>jSMSEngine API</strong>: Removed the reset() code (AT+CFUN) from all handlers except Wavecom. It seems it has created many problems.</li>
<li><strong>jSMSEngine API</strong>: Fixed incorrect parsing of Status Report messages (<a href="http://jsmsengine.org/forum/index.php?action=vthread&forum=4&topic=43">Bug Report</a>).</li>
<li><strong>jSMSEngine API</strong>: Added small delay after sending data to GSM device, to allow time for response.</li>
<li><strong>jSMSEngine API</strong>: Complete redesign of GSM Alphabet handling and character encoding routines. Graved and other special characters should work ok. Source code compilation should be smooth in all operating systems, with no need to remove code.</li>
<li><strong>jSMSEngine API</strong>: A new field is added in CMessage, RefNo. RefNo is the SMSC Reference Number which is returned on succesfull dispatch of a message. This value is stored in refNo field (accessed by public method CMessage.getRefNo()). Outgoing messages will set their refNo to the Reference Number returned by your SMSC. Status Report messages will set their refNo to the refNo of the original message sent. This way, a status report message can be matched with a previously dispatched message. Reference Number is not unique, as its values cycle between 1 and 255, but if you combine it with the recipient's number you will get a better "key" information to use in matching a status report message with its appropriate sent message.
<li><strong>jSMSEngine API</strong>: Bug in AT Handler decision code. This affected modem specific AT handlers.</li>
<li><strong>jSMSEngine API</strong>: Classes CMessage, CIncomingMessage, COutgoingMessage, CStatusReportMessage now implement the Serializable interface. <strong>Use this feature with care! There is no guarantee that these classes will not be modified in a future release.</strong></li>
</ul>
<br><br>
<strong>Version 2.0.8 (Compiled packages with JDK 1.5.x)</strong>
<ul>
<li><strong>jSMSEngine API</strong>: The CService code for selecting the appropriate AT handler has changed from the arcane if-then structure to a more elegant solution based on reflection. Code contributed by Alessandro A. Garbagnati.</li>
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?