nxtcommand-developers

[Nxtcommand-developers] Making Icommand ready for different NXTCOMM implementations

[Peter J. <ptg...@ch...>]

I am making changes to make Icommand ready for different NXTCOMM
implementations: RXTX, BlueZ, ...

Changes to properties file:

	/* Type of NXTCOMM implementation; defaulting to 'rxtx' */
	private static final String PROP_NXTCOMM_TYPE = "nxtcomm.type";
	
	private static final String PROP_RXTX_PORT    = "rxtx.port";

	/* Changed property name from 'nxtcomm' to 'rxtx.port';
	 *  still supporting the old property name.
	 */
	private static final String PROP_RXTX_PORT_OLD = "nxtcomm";
	
	private static final String PROP_BLUEZ_DEVID  = "bluez.devid";
	

Any comments ?

Peter Joosten.
  

[Nxtcommand-developers] Making Icommand ready for different NXTCOMM implementations

[Peter J. <ptg...@ch...>]

We should separate API (for end users) from implementation.

At this moment from the icommand.nxtcomm package the NXTCommand class is
part of the API (method close()).

package icommand.nxtcomm should NOT be part of the API

Proposal:

Make an interface NXTCommand in the package icommand.platform.nxt
with open() and close() methods.

Change access modifiers in icommand.nxtcomm to package (= no access
modifier) as much as possible to prohibit access by end users. 

In the distribution Javadoc of package icommand.nxtcomm will not be
included, since it is no longer part of the API.

Peter Joosten.

Re: [Nxtcommand-developers] Making Icommand ready for differentNXTCOMMimplementations

[Brian B. <bba...@mt...>]

>> Puttng the NXTComm interface in package 'icommand' would even be better.
>> I need  this interface to support multiple implementations.
>>
>> Then I do not need an Interface NXTCommand.
>>
>> This would however mean a "bigger" change in the API.
>>
>> NXTComm.open() and NXTComm.close() instead of NXTCommand.close()
>
> That's fine. Makes more sense really, since you are opening/closing the
> communications link.

But what package would NXTComm reside in, and we still need to make those 
for Bluez etc... don't we? i.e. BluezNXTComm, RXTXNXTComm... We need to give 
the user one singleton class they can use to access methods.

- Brian 

Re: [Nxtcommand-developers] Making Icommand ready for different NXTCOMM implementations

[Peter J. <ptg...@ch...>]

Brian, other developers,

My mails of yesterday were written a little late.
As a result I was not that clear in my mind.

At this moment I have changed the sources in my eclipse workspace.
I have come up with the following proposal.
If you agree, than I will continue testing, and then commit my changes.

in package icommand.nxt:

I have an interface NXTComm, and 2 implementation classes NXTCommRXTX
and NXTCommBluez. I had to remove the 'static' modifier of the methods
in NXTCommRXTX in order to use the interface NXTComm.

I have added NXTComm.open() to the API. So at start of the program
NXTCommand.open() should be called, and at the end NXTCommand.close();

When I started programming I did think that I needed NXTCommand.open()
to be in the API for technical reasons. But there is no technical
reason. I you prefer I can remove this API change. Personally I prefer
to put it in the API, because to me it looks "strange" to see a close()
statement, without a preceding open() statement. Make your choice! 
 
I still want to make icommand.nxt a non-API package someday, but for the
moment I want to leave it as is.

My 2nd goal was to remove static methods where they where not really
needed. Personally I think the static modifier is OK for defining
constants (public static final String GREET = "Hello") an so-called
utility classes (e.g. java.lang.Math). I have also removed the 'static'
modifier in the methods from NXTCommand as much as possible.

The methods open() close() and setVerify(...) I did leave static,
because they are part of the "static Lejos API".

I did make the NXTCommand class a singleton, so that it can easily
be accessed by the static Lejos API. When I say singleton, I mean
the singleton design pattern, not static methods. (There is a
difference).

In the example below you can see how the singleton is accessed
from the classes in the package icommand.patform.nxt 

public class Battery implements NXTProtocol {
	
	private static final NXTCommand nxtCommand = NXTCommand.getSingleton();
	
	// Ensure no one tries to instantiate this.
	private Battery() {}
		
	/**
	 * The NXT uses 6 batteries of 1500 mV each.
	 * @return Battery voltage in mV. ~9000 = full.
	 */
	public static int getVoltageMilliVolt() {
		/*
	     * calculation from LEGO firmware
	     */
		int voltage = nxtCommand.getBatteryLevel();
		return voltage;
	}

	/**
	 * The NXT uses 6 batteries of 1.5 V each.
	 * @return Battery voltage in Volt. ~9V = full.
	 */
	public static float getVoltage() {
	   return (float)(getVoltageMilliVolt() * 0.001);
	}
}

Greetings,
Peter Joosten.



 

Re: [Nxtcommand-developers] Making Icommand ready for different NXTCOMM implementations

[Peter J. <ptg...@ch...>]

On Thu, 2006-11-09 at 02:21 +0100, Peter Joosten wrote:
> We should separate API (for end users) from implementation.
> 
> At this moment from the icommand.nxtcomm package the NXTCommand class is
> part of the API (method close()).
> 
> package icommand.nxtcomm should NOT be part of the API
> 
> Proposal:
> 
> Make an interface NXTCommand in the package icommand.platform.nxt
> with open() and close() methods.
> 

Putting the interface in the "icommand" package would be a good
(/better?) alternative !

> Change access modifiers in icommand.nxtcomm to package (= no access
> modifier) as much as possible to prohibit access by end users. 
> 
> In the distribution Javadoc of package icommand.nxtcomm will not be
> included, since it is no longer part of the API.
> 
> Peter Joosten.
> 
> 

Re: [Nxtcommand-developers] Making Icommand ready for different NXTCOMM implementations

[Peter J. <ptg...@ch...>]

Puttng the NXTComm interface in package 'icommand' would even be better.
I need  this interface to support multiple implementations.

Then I do not need an Interface NXTCommand.

This would however mean a "bigger" change in the API.

NXTComm.open() and NXTComm.close() instead of NXTCommand.close()

Peter.

On Thu, 2006-11-09 at 02:23 +0100, Peter Joosten wrote:
> On Thu, 2006-11-09 at 02:21 +0100, Peter Joosten wrote:
> > We should separate API (for end users) from implementation.
> > 
> > At this moment from the icommand.nxtcomm package the NXTCommand class is
> > part of the API (method close()).
> > 
> > package icommand.nxtcomm should NOT be part of the API
> > 
> > Proposal:
> > 
> > Make an interface NXTCommand in the package icommand.platform.nxt
> > with open() and close() methods.
> > 
> 
> Putting the interface in the "icommand" package would be a good
> (/better?) alternative !
> 
> > Change access modifiers in icommand.nxtcomm to package (= no access
> > modifier) as much as possible to prohibit access by end users. 
> > 
> > In the distribution Javadoc of package icommand.nxtcomm will not be
> > included, since it is no longer part of the API.
> > 
> > Peter Joosten.
> > 
> > 
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Nxtcommand-developers mailing list
> Nxt...@li...
> https://lists.sourceforge.net/lists/listinfo/nxtcommand-developers

Re: [Nxtcommand-developers] Making Icommand ready for different NXTCOMMimplementations

[Brian B. <bba...@mt...>]

> We should separate API (for end users) from implementation.
>
> At this moment from the icommand.nxtcomm package the NXTCommand class is
> part of the API (method close()).
>
> package icommand.nxtcomm should NOT be part of the API
>
> Proposal:
>
> Make an interface NXTCommand in the package icommand.platform.nxt
> with open() and close() methods.

Should we just call it NXT in keeping with the other physical objects 
(Motor, Speaker, etc...) - On second thought, see below.

> Change access modifiers in icommand.nxtcomm to package (= no access
> modifier) as much as possible to prohibit access by end users.
>
> In the distribution Javadoc of package icommand.nxtcomm will not be
> included, since it is no longer part of the API.

I agree with that. End users won't be using that.

> Puttng the NXTComm interface in package 'icommand' would even be better.
> I need  this interface to support multiple implementations.
>
> Then I do not need an Interface NXTCommand.
>
> This would however mean a "bigger" change in the API.
>
> NXTComm.open() and NXTComm.close() instead of NXTCommand.close()

That's fine. Makes more sense really, since you are opening/closing the 
communications link.

- Brian