08-16-2011 02:59 PM
I am not asking for code in particualr(I won't say no though)
Just imagine this. I have a table that takes up half the screen. And a display area underneath the table taking up the rest of the screen. Now what I want to do is display more data on that particular cell in this display area. And when a different cell receives focus, the information below the table changes to correspond with the cell. So basically each cell has it's individual information to be displayed. What I want to know is how do I save that information(it's going to be a lot of information) and make it individual to the cell and then how do I update that Display area when another field receives focus. Any ideas? please?
08-16-2011 03:17 PM
You have some fields in those cells, don't you?
To associate any Object with a Field, use setCookie. To retrieve it, use getCookie.
To track the focus changes, use FocusChangeListener.
To modify some area of the screen, you can replace fields in there or simply change the contents of the fields: setText for all kinds of text fields, label fields, etc., setBitmap for BitmapFields - you get the idea.
08-16-2011 06:13 PM
08-16-2011 10:45 PM
Just create an array or a Vector of Objects you want to associate with those cells. When the focus moves within the table (by the way - what are you using for a table? GridFieldManager? TableLayoutManager?), check what cell has focus and find the corresponding item in the array/Vector.
08-17-2011 07:54 PM
08-17-2011 10:52 PM
Looks OK to me, but other people might have other opinions. You can serialize the objects (into XML or something similar) and save them on the file system instead - your choice.
08-20-2011 02:05 PM
08-20-2011 07:39 PM
Sorry I don't understand the question.
There is nothing stopping you adding methods to a Persistent Object. That works fine.
A Vector is Persistable, and so you can add your persistable objects to a Vector or add a Vector to your perishable Object, that will work fine.
Can you explain your problem again? Perhaps a small code sample will help? Please make it small and representative rather than your entire class.
08-20-2011 08:01 PM
08-20-2011 09:00 PM
That is unfortunately not what I meant.
You can have a Settings class that implements Persistable. it can have primitives in it. If it has any Objects in it, these must also implement Persistable. If it has any collections then the Collections should also be Persistable (I believe most are, certainly Vector and Hashtable which are the ones I use are Persistable). And any Objects that are added to a Collection that is part of a Persistable Object, must also be Persistable.
In addition, this Settings class can have any methods that you want.
There is not need to have a Wrapper Object, though to be honest, I usually do, to abstract the storage mechanism from the users of the data. As an example, say my Wrapper class is called Repository, then users will interact like this
String userName = Repository.getUserName()
The Wrapper Object actually manages both PersistentStore and RuntimeStore, so that the user does not know where the user name string came from, nor do they care how it was actually stored.
Specific answers to your quests are:
1. May be private, may not be. Depends on how you want tot do it. For me it is usually private.
2. Can be, if you want to abstract your interface to persistent objects. I typically do and I typically call this class Repository.
3. Depends on your implementation, but the answer is typically yes from me.