We Keep Coding

Is it unwise to create and fill large arrays in my onCreate() method?

I'm planning to create an app that basically asks a lot of questions (for the purpose of study). I haven't started it yet, I'm still planning how I will carry it out.
I'm thinking of creating a class called Question and then storing multiple objects of that class in different arrays. I could end up having thousands of Question objects. I would do this in my onCreate() method, so as to have all the questions ready by the time the app starts.
Would doing so much in the onCreate() method slow down/cripple my program?
What makes this worse is that if the user exits the app and then reopens it, the questions would be added again.
Is there a better way of having large amount of objects in my app?
As someone fairly new to android development and programming in general, I appreciate any help.

It would be better to do the loading on a background thread (using an AsyncTask or other threading library) and to display some sort of loading progress bar to the user while it loads. In the onPostExecute method of your AsyncTask (or similar) then you can turn off the progress bar and turn on the relevant UI elements.
If you want the questions to persist between different activities, you could store the data in a singleton so it persists during the app session at least.

Is there a way for fuzzing Swing applications?

Back in the old days, PalmOS had an emulator that could generate random events ("tap here, enter garbage in that text field, ...") for testing how applications would handle them (called "Gremlins"). This is a bit like fuzzing, but for a GUI. Is there an easy (existing) way to do that in a Java Swing application?
Edit:
Please note that I don't want to be able to specify, which events are fired. I'd like some code to automatically generate and fire random (as in "Math.random()") events. The probability that the events do something useful or find a bug is pretty small. But that is offset by firing many events.

Try FEST. It simplifies the process of functional-testing Swing GUIs by allowing to access Swing components by name and then interacting with them.
An example from FEST site:
dialog.comboBox("domain").select("Users");
dialog.textBox("username").enterText("alex.ruiz");
dialog.button("ok").click();
dialog.optionPane().requireErrorMessage()
.requireMessage("Please enter your password");
Edit:
Alternatively, what you are trying to achieve, should be really straightforward using Math.random(), a loop, findBomponentAt(int, int) and Robot class. Especially Robot class mitght be of use, as it has methods for spoofing mouse and keyboard events

rJava startMainLoop() function kills Java operations

I've developed an interface that allows a user to load and manipulate data. The GUI is developed in Java and all the computational stuff is done in the background by R, linking the two with jri. The idea is that the user doesn't have to have any knowledge of R to use it, it's all options and buttons. However, i'd like to give the user the option to write some code if necessary. So here is my problem:
If I use the following code to start the Rengine and not let the user interact via console, everything works fine:
Rengine re=new Rengine(null, false, new TextConsole());
But if I use this:
Rengine re=new Rengine(null, true, new TextConsole());
The functionality of the gui doesnt work. I tried using the
re.startMainLoop();
function after the data was loaded. I was able to manipulate the data from the comand line in R, for example I could make a new variable from a column of the data loaded:
newVariable<-data$column1
But yet again, I couldn't use the gui anymore. Has anyone got any ideas or explainations as to why this is?
Thanks in advance,
Aran

Fundamentally, if REPL is not running, R is simply used via eval calls from your code. You have control at all times, except during the actual evaluation. That is the most common use, because you can do pretty much anything that way.
The moment you enable the event loop (REPL), you have to implement the callback methods that are used by the loop. By design R surrenders the control only by calling the rReadConsole callback which you have to implement. The example TextConsole works only as a demo, it uses blocking call (readLine()) to wait so you definitely don't want to use that in your GUI. You'll have to implement all callbacks correspondingly to react to your GUI's elements (wait in ReadConsole for your GUI to wake it up from a separate thread, dispatch WriteConsole to your elements etc.). You can have a look at JGR how it's done properly. Unless you are really building a general purpose R GUI, I wouldn't go into that trouble ...
(PS: please use stats-rosuda-devel mailing list for rJava/JRI questions - you get answers much faster)

Questions: controlling a Swing GUI from an external class and separating logic from user interface

UPDATE: I'm using Netbeans and Matise and it's possible that it could be Matise causing the problems I describe below.
UPDATE 2: Thanks to those who offered constructive suggestions. After rewriting the code without Matise's help, the answer offered by ignis worked as he described. I'm still not sure how the code the Netbeans code generator interfered.
Though I've been programming in Java for awhile I've never done any GUI programming until now. I would like to control a certain part of my program externally (updating a jTextArea field with output from an external source) without requiring any user action to trigger the display of this output in the jTextArea.
Specifically, I want this output to begin displaying on startup and to start and stop depending on external conditions that have nothing to do with the GUI or what the user is doing. From what I understand so far you can trigger such events through action listeners, but these action listeners assume they are listening for user activity. If I must use action listeners, is there a way to trick the GUI into thinking user interaction has happened or is there a more straightforward way to achieve what I want to do?
Also, I'd really like to know more about best practices for separating GUI code from the application logic. From the docs I've come across, it seems that GUI development demands more of a messy integration of logic and user interface than, say, a web application where one can achieve complete separation. I'd be very interested in any leads in this area.

There is no need to use listeners. GUI objects are just like any other objects in the program, so actually
you can use the listener pattern in any part of the program, even if it is unrelated to the GUI
you can invoke methods of objects of the GUI whenever you want during the program execution, even if you do not attach any listeners to the objects in the GUI.
The main "rule" you must follow is that every method invocation performed on objects of the GUI must be run on the AWT Event Dispatch Thread (yes, that's true for Swing also).
http://download.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html
So you must wrap code accessing the GUI objects, into either
javax.swing.SwingUtilities.invokeLater( new Runnable() { ... } )
or
javax.swing.SwingUtilities.invokeAndWait( new Runnable() { ... } )
http://download.oracle.com/javase/6/docs/api/javax/swing/SwingUtilities.html
About "separating GUI code from the application logic": google "MVC" or "model view controller". This is the "standard" way of separating these things. It consists in making the GUI code (the "view") just a "facade" for the contents (the "model"). Another part of the application (the "controller") creates and invokes the model and the view as needed (it "controls" program execution, or it should do that, so it is named "controller"), and connects them with each other.
http://download.oracle.com/javase/tutorial/uiswing/components/model.html
For example, a JFoo class in the javax.swing package, that defines a Swing component, acts as the view for one or more FooModel class or interface defined either under javax.swing or one of its subpackages. You program will be the "controller" which instantiates the view and an implementation of the model properly (which may be one of the default implementations found under those packages I mentioned, or a custom implementation defined among your custom packages in the program).
http://download.oracle.com/javase/1.4.2/docs/api/javax/swing/package-summary.html

That's a really good question, IMHO... one I asked a couple of years ago on Sun's Java Forums (now basically defunct, thanx to Oracle, the half-witted pack of febrile fiscal fascists).
On the front of bringing order to kaos that is your typical "first cut" of an GUI, Google for Swing MVC. The first article I read on the topic was JavaWorld's "MVC meets Swing". I got lucky, because it explains the PROBLEMS as well as proposes sane solutions (with examples). Read through it, and google yourself for "extended reading" and hit us with any specific questions arrising from that.
On the "simulated user activity" front you've got nothing to worry about really... you need only observe your external conditions, say you detect that a local-file has been updated (for instance) and in turn "raise" a notification to registered listener(s)... the only difference being that in this case you're implementing both the "talker" and the "listener". Swings Listener interface may be re-used for the messaging (or not, at your distretion). Nothing tricky here.
"Raising" an "event" is totally straight forward. Basically you'd just invoke the "EventHappened" method on each of the listeners which is currently registered. The only tricky bit is dealing with "multithreaded-ness" innate to all non-trivial Swing apps... otherwise they'd run like three-legged-dogs, coz the EDT (google it) is constantly off doing everything, instead of just painting and message brokering (i.e. what it was designed for). (As said earlier by Ignis) The SwingUtilies class exposes a couple of handy invoke methods for "raising events" on the EDT.
There's nothing really special about Swing apps... Swing just has a pretty steep learning curve, that's all, especially multithreading... a topic which I had previously avoided like the plague, as "too complicated for a humble brain like mine". Needless to say that turned out to be a baseless fear. Even an old idiot like myself can understand it... it just takes longer, that's all.
Cheers. Keith.

This doesn't exactly answer your question, but you might be interested in using Netbeans for Java GUI development. You can use GUI in Netbeans to do Java GUI development.
Here's a good place to get started -
http://netbeans.org/kb/trails/matisse.html

java: any way to detect changes in display configuration?

One of my coworkers would like my Swing app to adapt correctly to the removal of a 2nd display monitor.
Is there any way to get notification of this, other than polling to repeatedly compute virtual bounds? (per the code sample in http://download.oracle.com/javase/6/docs/api/java/awt/GraphicsConfiguration.html)

Hum, tricky one. Because GraphicsConfiguration class won't give us any listeners, I'll have only a couple of alternatives:
(If Windows) Use a JNI interface to
Windows to detect display settings
change and forward them to Java.
This would be the
SystemEvents::DisplaySettingsChanged
Event.
Create a simple polling Thread -
timer that retrieves the result of
Toolkit.getDefaultToolkit().getScreenSize()
as you've already stated before.