Develop Reference

What action should a client application take after executing a command?

Background
This question is best illustrated using an example. Say I have a client application (e.g. desktop application, mobile app, etc.) that consumes information from a web service. One of the screens has a list of products that are queried from the web service when the client application starts up and are bound to the UI element. Now, the user creates a new product. This causes the client application to send a command to the web service to add that product to a database.
Question
In the client application, what should happen after the command is issued and is successful? Do you:
Query the full product list from the service and refresh the entire product list in the client application?
Query just the two newly added products and add them to the product list?
Don't query, and instead just use the information available in the client application to create the new products in the GUI, and then add them to the list?
The same questions apply to update too. If you update a product, do you get confirmation of a successful update on the service, and then just let the GUI update the product without further requests to the service?
Edit - Additional details added
From initial feedback, the takeaway appears to be go with the simplest approach unless this:
Leads to performance concerns
Negatively impacts user experience
There is a major/significant portion of my application where the main way to interact with the application is to drag grid records between a number of different grids. For example, dragging a product onto another grid would create a new order, which would need to be sent to the service. Some of these grids are more complex than your standard grid. Records can be grouped, and each group can be collapsed/expanded (see here). In this case, while the grid can be refreshed from the service very quickly, this would probably lead to usability concerns. When a grid is refreshed with all new data, if the user had any groups expanded/collapsed, this would be lost.
So, while most grids in my application could probably just all be refreshed at once, the more complex ones will need to be updated more carefully. I would think this would lend to option 1 or 2 (at least for creating new records). One thought I had was that the client application could create GUIDs for new records to be sent with the application. That way, no follow-up query would need to be made to the service, as the client application would already have the unique ID. Then, the client application would just wait for a successful response from the service prior to showing the user the new record.

Get the whole list
I guess it depends how costly the request/response are. If possible and efficient, I would always choose your first option (get the whole list) until there is a performance concern.
As the saying goes:
The First Rule of Program Optimization: Don't do it.
The Second Rule of Program Optimization – For experts only: Don't do it yet.
There is simply less scenarios to cover, less code to write, less code to maintain since you'll need the "get the whole list" service no matter what.
It also returns the "most up to date list of products" in case another client added products simultaneously.
Only pros, until there is a performance concern, in my opinion. These last 3 words would imply that this question will only lead to opinions and should be closed...

I don't think there's any definitive right answer; these kinds of questions need to be thought of on a case by case basis. #3 by itself is often not an option - for example, if you need the client to have a database-generated field like an ID, it's gotta get from point A to point B somehow. You also need to think about how you're exposing any errors to your user, because it's a terrible experience if you make it appear that everything succeeded, but you actually had an error and the product didn't really save.
Beyond that, I'd look at usability as my next criteria. What's the experience like for your users if you refresh the list versus adding just a couple of products? Is there a significant difference? A lot comes down to your specific application, and also the workflow being done. If adding products is something that is the main part of someone's job, where they may spend hours a day doing this, shaving even a second off the time is a real win for your users, while if it's an uncommon workflow that people do from time to time, the performance expectations are somewhat lower.
And last I'd look at code maintenance and complexity. If two paths are giving relatively similar experiences, pick the one that's easier to build and maintain.
There are other options, too. You can go with a hybrid approach - for example, maybe on the client you add the data to the product list immediately (perhaps showing some kind of "saving" indicator), while also asynchronously querying the database so you can refresh the product listing and report any errors. Such approaches tend to be the most complex, but you might go down that route if usability demands it.

MIDP: Get or track the currently focused Item

I'm adding in some functionality to a MIDP-based app which requires me to track whether or not an Item has focus. I'm only really concerned with field-style Items and need to determine when the user has finished inputting data into the Item.
I'm aware that CustomItem has the traverse() callback, but I can't find anything similar for classes like DateField, TextField and ChoiceGroup.
I'm also aware of Display.setCurrentItem() but for some strange reason there doesn't seem to be a Display.getCurrentItem() method.
Implementing all the controls as CustomItems isn't really an option as it's a pre-existing app and there are quite a lot of controls to deal with. I can't believe that nobody has run into this issue before, but I've searched on here and google to no avail. Hopefully I'm just missing something obvious in the API, but if there isn't a definite answer then creative solutions are welcome!

In MIDP 2 lcdui API, the only field-style Items are, well, interactive subclasses of Item: TextField, DateField, Gauge.
For above items the closest match to what you are asking about seem to be provided by ItemStateListener (take a look at API javadocs here if you're interested).
...used by applications which need to receive events that indicate changes in the internal state of the interactive items...For implementations that have the concept of an input focus, the listener should be called no later than when the focus moves away from an item whose state has been changed.
If you plan to use this API, carefully check the docs to verify that it indeed gives you what you want - there are some subtle limitations there. If it turns out that you need greater control than that, your options are either to use low level UI (Canvas, events) or 3rd party library like LWUIT, J2ME Polish...

Writing a program that will automate searches on finra.org for brokers

So I have two possible solutions that I want to implement. Firstly I will state my problem. The task I have been assigned to requires me to go to a website called finra.org and do broker checks to see if the brokers in my excel sheet(which gives the name and company among other things) still work A, and if they do work do they still work for the company in the excel sheet. If they do move on to the next one, and if they don't delete them from the sheet. The issue lies in that I have 37k names to check. I calculated this and to do it individually, which is annoying and takes the whole day allows me to do a maximum of 1400 a day. That is on a productive day when I dont have other things to do. So I figured a better use of my time ( I am an intern) would be to write a program which (here are my two suggested solutions:)
1.) Automatically through minimal key strokes copies the data and pastes it into the search box on the page. Ill still have to click and search but at least I would eliminate copying and pasting and switching between screens which takes the majority of the time.
2.) Completely automate the process. I was thinking of copying the names into a text file and then somehow writing a program that takes each name and submits a query to this website which would then show me the result. Perhaps sends the result text to a text file and then i could just GREP the text file for the data that i need.
Any idea if any of this is possible?
Thanks,
Kevin

Definitely possible. I'm doing something similar with a database and an Excel spreadsheet of values using AutoHotKey to automate queries, Chrome console commands and Javascript bookmarklets to scrape data into the clipboard, and Ruby/Nokogiri with more complex and/or structured parsing tasks.
Either of your methods will work - if you have little programming background, I would suggest starting with AutoHotKey since it mimics keyboard and mouse commands, so the programming is much more straightforward and easier to understand. If you have some object-oriented programming skills, learning Ruby/Nokogiri might be your solution, depending on how FINRA's page is structued.

"Quick find" for an SWT Table

I have a table that displays the output from a database, this can often be up to or over 10,000 rows. I'm looking to implement a 'quick find' function that will allow the user to easily scroll to a row with the value for which they search.
The idea is for this to be very similar to Chrome or Firefox's quick find. So:
User hits 'CTRL+F'
A box pops up:
The user can then quickly skim through the table pushing / or /\ to each matching value
My question is, does such a table already exist? I have looked at NatTable and XViewer but they both seem like rather large additions for a relatively minor change.
Another library I've looked at that is close to fitting the billl is Lucene TableSearcher unfortunately this is designed for filtering rather than highlighting. However it may be an avenue worth investigating.

It's not quite the same, but JFace does have support for filtering views. You type in a text box and view contents shrink to what matches the filter. It's basically another way to present search/find functionality to the user.
You can see this in action in Eclipse Preferences (the filter text field about the navigation tree in the dialog). See org.eclipse.ui.dialogs.FilteredTree class. I don't believe there is a FilteredTable or equivalent, but underlying facilities are pretty generic, so it shouldn't take much work to put one together. Take a look at FilteredTree source and go from there.

The solution I chose wasn't as simple as I'd hoped but has a satisfactory performance.
The tables involved are virtual tables that can be very large. So on top of this upon loading the dataset we start a thread to build an index in the form of a list. Because these tables can be very large (but aren't often) we set a 50mb limit to this list and stop indexing it when we hit it. For most cases this is perfectly acceptable but for the larger tables it means that whilst it may be slower, it is considerably more stable than other options.
The 'search' is a simple SWT textbox with ModifyListener that iterates over the list, performing a 'contains' on each entry. Upon a match the row and column are calculated from the index number (0=0,0, 1=0,1 ..).
It would have been nice to have a simple 'drop in' solution for this but all of the tables on offer had too many features.

Use FilteredItemsSelectionDialog dialog box

Best way to implement game playback?

I'm creating a grid based game in Java and I want to implement game recording and playback. I'm not sure how to do this, although I've considered 2 ideas:
Several times every second, I'd record the entire game state. To play it back, I write a renderer to read the states and try to create a visual representation. With this, however, I'd likely have a large save file, and any playback attempts would likely have noticeable lag.
I could also write every key press and mouse click into the save file. This would give me a smaller file, and could play back with less lag. However, the slightest error at the start of the game (For example, shooting 1 millisecond later) would result in a vastly different game state several minutes into the game.
What, then, is the best way to implement game playback?
Edit- I'm not sure exactly how deterministic my game is, so I'm not sure the entire game can be pieced together exactly by recording only keystrokes and mouse clicks.

A good playback mechanism is not something that can be simply added to a game without major difiiculties. The best would be do design the game infrastructure with it in mind. The command pattern can be used to achieve such a game infrastructure.
For example:
public interface Command{
void execute();
}
public class MoveRightCommand implements Command {
private Grid theGrid;
private Player thePlayer;
public MoveRightCommand(Player player, Grid grid){
this.theGrid = grid;
this.thePlayer = player;
}
public void execute(){
player.modifyPosition(0, 1, 0, 0);
}
}
And then the command can be pushed in an execution queue both when the user presses a keyboard button, moves the mouse or without a trigger with the playback mechanism. The command object can have a time-stamp value (relative to the beginning of the playback) for precise playback...

Shawn Hargreaves had a recent post on his blog about how they implemented replay in MotoGP. Goes over several different approaches and their pros and cons.
http://blogs.msdn.com/shawnhar/archive/2009/03/20/motogp-replays.aspx

Assuming that your game is deterministic, it might be sufficient if you recorded the inputs of the users (option 2). However, you would need to make sure that you are recognizing the correct and consistent times for these events, such as when it was recognized by the server. I'm not sure how you handle events in the grid.
My worry is that if you don't have a mechanism that can uniformly reference timed events, there might be a problem with the way your code handles distributed users.
Consider a game like Halo 3 on the XBOX 360 for example - each client records his view of the game, including server-based corrections.

Why not record several times a second and then compress your output, or perhaps do this:
recordInitialState();
...
runs 30 times a second:
recordChangeInState(previousState, currentState);
...
If you only record the change in state with a timestamp(and each change is small, and if there is no change, then record nothing), you should end up with reasonable file sizes.

There is no need to save everything in the scene for every frame. Save changes incrementally and use some good interpolation techniques. I would not really use a command pattern based approach, but rather make checks at a fixed rate for every game object and see if it has changed any attribute. If there is a change that change is recorded in some good encoding and the replay won't even become that big.

How you approach this will depend greatly on the language you are using for your game, but in general terms there are many approaches, depending on if you want to use a lot of storage or want some delay. It would be helpful if you could give some thoughts as to what sacrifices you are willing to make.
But, it would seem the best approach may be to just save the input from the user, as was mentioned, and either store the positions of all the actors/sprites in the game at the same time, which is as simple as just saving direction, velocity and tile x,y, or, if everything can be deterministic then ignore the actors/sprites as you can get their information.
How non-deterministic your game is would also be useful to give a better suggestion.
If there is a great deal of dynamic motion, such as a crash derby, then you may want to save information each frame, as you should be updating the players/actors at a certain framerate.

I would simply say that the best way to record a replay of a game depends entirely on the nature of the game. Being grid based isn't the issue; the issue is how predictable behaviour is following a state change, how often there are new inputs to the system, whether there is random data being injected at any point, etc, You can store an entire chess game just by recording each move in turn, but that wouldn't work for a first person shooter where there are no clear turns. You could store a first person shooter by noting the exact time of each input, but that won't work for an RPG where the result of an input might be modified by the result of a random dice roll. Even the seemingly foolproof idea of taking a snapshot as often as possible isn't good enough if important information appears instantaneously and doesn't persist in any capturable form.
Interestingly this is very similar to the problem you get with networking. How does one computer ensure that another computer is made aware of the game state, without having to send that entire game state at an impractically high frequency? The typical approach ends up being a bespoke mixture of event notifications and state updates, which is probably what you'll need here.

I did this once by borrowing an idea from video compression: keyframes and intermediate frames. Basically, every few seconds you save the complete state of the world. Then, once per game update, you save all the changes to the world state that have happened since the last game update. The details (how often do you save keyframes? What exactly counts as a 'change to the world state'?) will depend on what sort of game information you need to preserve.
In our case, the world consisted of many, many game objects, most of which were holding still at any given time, so this approach saved us a lot of time and memory in recording the positions of objects that weren't moving. In yours the tradeoffs might be different.