Arbitrary number of objects, each with a unique name.

[providence]

I need to generate an arbitrary number of objects, and each one has to have a unique name. There has to be a better way of doing this than creating a massive arraylist of objects, all typed out by hand... There could potentially be a hundred!
It doesn't seem like there is any way of assigning the value of a String variable to the Object variable name, I'm quite stuck here...

[Fubarable]

Why do the objects need to have a "name"? What is the basis for this requirement? why not just have an ArrayList of your class of object?

[providence]

Hmm, Perhaps I should have used the word 'instance'? I'm not sure. What I am trying to do is create a notification for each item in a resultset by calling a custom method that creates and displays notifications based on the Notification class. Some notification class methods are not static, so the importan part of this notification producing method looks like:

 

//stuff...


while (resultset.hasNext() {
    createNotification(resultset.getString(1));
}

private void createNotification(String string) {
   //stuff

    Notification note = new Notification();
    note.setTitle(string);
    note.setText(string + " has returned a result");

    NotificationManager.display(note);
}

the issue is that I need to assign a new variable for Notification each time, else NotificationManager overwrites the old one.

[Fubarable]

I'm not familiar with your Notification class -- is it one that you've created or is it part of the core Java API? If you want to create a bunch of objects and associate them with a String, and retrieve them based on this String (perhaps the String passed into your createNotification method), then perhaps you could use a HashMap<String, Notification>, and put the String as key and Notification object as value in the map.

[providence]

Yes, using a hashmap is an option that I've explored, however that requires creating the maximum potential number of objects and placing them all in the map. What I was looking for was a way to create them on a need basis. The issue is that I cannot find a way to assign the value of a String variable as the variable name for the new object. Below is an example of what I want to do, this code won't actually work though..

  public void someMethod() {

//stuff

  while (resultset.hasNext()) {
    createNotification(resultset.getString(1));
  }
}

private void createNotification(String objName) {
  Notification (get the value of objName) = new Notification();
  
  (the value of objName).setText("some text");

  //etc...
}

After looking into the matter some more, I realised that this is fundamentally impossible because of the way the parser/lexar work. So now I'm wondering if there is a way to instruct the parser to evaluate, back up, and use the result of the evaluation as the variable to assign as the name of the Notification instance on the level of the Java code.

[Junky]

Since you create the Notification object inside the createNotification method it is only accessible inside that method and gets GC when you leave you can call it whatever you like. Unless you store it in a data structure but if you do that there is no need for a "name". Either way I feel you are working towards a solution that does not have a problem.

[providence]

That would usually be the case, but I'm working with android, and because the notification is displayed outside of any one application, (on the home screen), it is preserved and spared gc-ing, which is the root of my problem. Although hopefully, the case is that I am looking to tackle a problem at the root that can be taken from the stem.

[gcalvin]

Yes, using a hashmap is an option that I've explored, however that requires creating the maximum potential number of objects and placing them all in the map. What I was looking for was a way to create them on a need basis.

I'm not sure why you think a HashMap would require any such thing. You can certainly create your instances as you need them, associate them with a String, and store them in a HashMap as you go. I would strongly encourage you to reconsider this option, and if you run into roadblocks, bring them to us for help. From what you've described, a HashMap would seem to be ideal.

-Gary-

[providence]

Yes, sorry, you're right. HashMap would seem to be ideal in fact. I didn't see the bigger picture there.