TagMemory - Revision history

Kyle: /* Historical Notes */

2008-05-09T18:36:59Z

‎Historical Notes

Kyle at 17:59, 29 November 2007

2007-11-29T17:59:14Z

Kyle at 21:45, 8 November 2007

2007-11-08T21:45:12Z

Kyle: New page: =Purpose= The tag memory serves as a data structure that handles tags in a reader specific way. Each time that the Radio's scan method is called, it will call the TagMemory's u...

2007-11-08T21:44:26Z

New page: =Purpose= The tag memory serves as a data structure that handles tags in a reader specific way. Each time that the Radio's scan method is called, it will call the TagMemory's u...

New page

=Purpose=

The tag memory serves as a data structure that handles tags in a reader specific way. Each time that the [[Radio|Radio's]] scan method is called, it will call the TagMemory's updateMemory() method, passing in the list of tags that it has seen. It is the TagMemory's job to determine how these tags should be added, and if any tags should be removed.

=Historical Notes=
The TagMemory was an interface located in the emulator, however, the only thing that implemented it was the GenericTagMemory that was actually alien specific. In addition, the TagMemory has been seen as a collection with an addTag() and a removeTag() method, which the radio would call when tags were added or removed. However, in order keep the radio simpler and more generic, there is only one updateTagMemory() method. This way the radio does not have to know about any kind of business logic about when tags should be added or removed from the tag memory.

It turns out that every reader has a different enough memory model that it is difficult to write a generic TagMemory. So with the introduction of the new radio, each Reader should implement NewTagMemory. In the mean time, The TagMemory interface is an empty interface, and the NewTagMemory interface implements the old TagMemory interface. This is so that changes will not have to be made to the SharedResources which require that a class which implements TagMemory be passed in at construct time.

=Implementation=

The most important methods in the NewTagMemory interface are the updateTagMemory() method and the getTagReport() method

The updateTagMemory method will be called by the radio, which will pass in a collection of [[RifidiTag|RifidiTags]]. These tags represent the tags that are currently on the reader. It is the TagMemory's job to figure out when and how tags should be removed from the internal lists that it keeps.

The getTagReport() method is the main way that other parts of the program (such as the handler methods) access the tags. Again, like the updateTagMemory() method, it should be implemented in a way that makes sense for the reader whose memory model you are trying to emulate.

Generally before you are able to put things into and get things out of a tagmemory, you should have to enable it. The enable_TagBuffer() and disable_TagBuffer() should be called in the reader's power state's, so that when a reader is suspended, nothing can accidentally be put into the tag buffer.

The last thing to remember is that a tagMemory should also increment the read count of tags that it sees. This used to be a part of the scan() method in the Radio, but is not anymore.

← Older revision		Revision as of 17:59, 29 November 2007
Line 1:		Line 1:
−	[[category:developerDoc]][[category:~~engineDoc~~]][[category:engineImplementation]]	+	[[category:developerDoc]][[category:EmulatorDoc]][[category:engineImplementation]]
	=Purpose=		=Purpose=

← Older revision		Revision as of 21:45, 8 November 2007
Line 1:		Line 1:
		+	[[category:developerDoc]][[category:engineDoc]][[category:engineImplementation]]
	=Purpose=		=Purpose=

@@ Line 7: / Line 7: @@
 The TagMemory was an interface located in the emulator, however, the only thing that implemented it was the GenericTagMemory that was actually alien specific.  In addition, the TagMemory has been seen as a collection with an addTag() and a removeTag() method, which the radio would call when tags were added or removed.  However, in order keep the radio simpler and more generic, there is only one updateTagMemory() method.  This way the radio does not have to know about any kind of business logic about when tags should be added or removed from the tag memory.
-It turns out that every reader has a different enough memory model that it is difficult to write a generic TagMemory. So with the introduction of the new radio, each Reader should implement NewTagMemory.  In the mean time, The TagMemory interface is an empty interface, and the NewTagMemory interface implements the old TagMemory interface.  This is so that changes will not have to be made to the SharedResources which require that a class which implements TagMemory be passed in at construct time.
+It turns out that every reader has a different enough memory model that it is difficult to write a generic TagMemory. So each Reader should implement the TagMemory interface.
 =Implementation=