I'm working on a GWT project which calls the server via RPC. A typical RPC calls the Server and passes some information and then recieves the answer as an ArrayList.Now we noticed that with a growing database we should use pagination to not overcharge the client with to many objects.
The problem is that there are at the moment many existing methods which are using RPC and each of them would must be modified to provide the necessary information for pagination (Count of Objects,Current Position ) . If i would change every method i would have to edit the Synchronous Interface,the Asynchronous Interface, and the Server and Client class which are using/implementing them.
I tried to create a generic Wrapper class, but i couldn't make it suitable for out project,because each object must be casted back in the original type. Is there a way with less effort to provide pagination without editing many methods?
Related
I am looking at MVVM with Knockout.js. One of the things I would like to achieve is to "easily" get my code behind MVVM POCO to the client as a corresponding JS object.
The idea being that:
a) If I change the C# POCO it will also reflect in the JS Object
b) Changing a value in the POCO will result in the necessary interaction with the client to update the JS object
I am guessing this is when you would use SignalR (http://signalr.net/) to do this? And then use the mapping plugin from KO (http://knockoutjs.com/documentation/plugins-mapping.html) to turn this into observables.
So my questions are:
Are my assumptions correct in terms of getting the POCO server
side data to KO via SignalR
Is there another way to achieve 1.?
Yes, you can use SignalR to push real-time changes to the POCO representation of your object to the client. I mean, it won't be automatic in terms of you change a property, it magically sends a message. You would have to build some plumbing to ensure you send a specific SignalR message when a particular object changed. You could choose to resend the entire representation of that object again (e.g. all current values) or you could send only the values that you know were changed for more efficiency.
From there you would need to update the corresponding JS representation of the object which, if you're using Knockout, would result in the proper notifications to all observers of said object. You could also do this in the other direction by observing a change on the JS object and sending a message back to the server.
Obviously the key will be that each object must have some kind of unique identity so that you can correlate the messages to/from the proper JS/POCO objects.
When one player makes a move that is sent to the server. And that move is pushed by the server to the second player. As far as I know, the server pushing the move to the second player goes against being a RESTful api.
From what little I know about backbone.js it is meant really for RESTful setups. Is there a way to use backbone.js with websockets to allow the server to push data down to the clients at any time?
Is there even an idiomatic way of implementing chess with backbone.js and websockets? And if not then what would be the correct way to implement chess?
You can definitely do it. Instead of fetching your collection/model, you will just set or update/reset the json data from the websocket into the proper model or collection.
Somewhat pseudo-code example:
var board = new Backbone.Collection(); // this would probably be your own extended Collection instead.
function boardChange(jsonFromServer){
// Take the json array from server,
// and update the collection with it.
// This would trigger 'change' events in each model in the collection (if changed).
board.update(jsonFromServer);
}
Implementing a chess app doesn't really require a Backbone architecture. As long as your server supports Asynchronous API, WebSockets, or even long-polling (anything real-time), it's possible. There's tons of APIs out there on the web already that does this (ie FireBase) as well as frameworks (ie, Meteor) comes into mind.
Also check out Socket IO if you're using Node JS for your server-side. There's tons of open source projects on GitHub that takes advantage of some of these web technologies already, Backbone in particular. Backbone with Socket IO. Backbone.ioBind also looks like a promising project with code samples that you can look at.
To make it work with Backbone, the data API just needs to notify any client-side listeners that an update has been made on the server which in turn triggers a change event on your Backbone Model.
You can even set a timer that performs a request to the server every n amount of time just to test out your code prototypes.
You could overload the Backbone.sync method to use websockets. The de-facto To-Do example (http://addyosmani.github.com/todomvc/) does this to use localstorage instead of a RESTful datastore, and you could do the same for web sockets. In fact if you look around Github/Google you may be able to find someone who's already done it.
I am new to GWT and am able to work around with GWT RPC but have problem in understanding how the control flow takes place internally. How it gets translated to AJAX?
Can we use new() instead of GWT.create(someService.class) to make an RPC call?
Why does Google not just use Async version instead of creating 2 interfaces?
What happens internally when we use
TaskService Async = GWT.create(TaskService.class);
I have read that it chooses the browser specific hashname.js file but am not understanding the complete control flow. Also How is the Callback Object used.
Can someone explain the control flow by pointing out the essentials?
UPDATE : #Thomas Broyer, Everything I understood... Just confirming that in case GWT.create() there is a .rpc file in the client side which helps in the deferred(late/runtime) binding. Is that correct?
GWT.create() will in this case call a GWT generator; it'll generate a class implementing the Async interface (and that's why you only have to declare an interface and you never implement it yourself).
See RPC Plumbing Diagram.
Using a generator (or selecting a specific implementation, but in the case of GWT-RPC, a generator is used) is called deferred binding.
So, no, you cannot use new.
As to why there are 2 interfaces, this is so that GWT can check that your server-side code (synchronous) is consistent with your client-side code (async). The reason you call GWT.create on the synchronous interface and it returns an implementation of the async one is legacy. I bet they wouldn't do it that way, were they to re-implement GWT-RPC from scratch.
The generated class will be responsible of serializing the call (method name and arguments) and make an AJAX request (using a RequestBuilder); and then deserialize the response (either of the type declared, or an exception)
Because calls are asynchronous, the callback is used to, well, call your code back when the server responds, after deserialization takes place (so either calling onSuccess with the decoded object, or onFailure with the decoded exception).
See Getting Used to Asynchronous Calls
Background:
I am in the early stages of an an iPhone App and REST WebService product. Basically, I have a database on the a server and have written some REST APIs to access this database. I have a companion iphone app that will consume these REST APIs.
Questions:
What is the best approach to place the code for accessing the REST Apis? Should I create a separate subclass of NSObject and place the interface and implementation details there? I would like to reduce the amount of code duplication throughout the application in the various ViewControllers that would interact with the REST API.
For Example:
My app would start up and make a REST API call to determine the current state of local information on the device by comparing the value returned from the API vs local. Then I would initiate an update request from the API to refresh the local datastore.
Now if I have all of this logic in the start-up ViewController I have multiple calls using NSURLConnection which only has on delegate. I don't know how to make these separate calls in the same ViewController.
What are some approaches to solving this problem?
I generally create custom objects which use ASIHTTPRequest (using composition, not subclassing) which can be initialised with any required parameters, and use that to manage requests to the RESTful service. The custom object will provide a delegate protocol for handling success, failure and other custom notifications so that I can use this feedback to update the application UI while the request is performed asynchronously.
If you need to parse large amount of data returned from a request, make sure you launch a separate thread to do this, rather than doing it in your HTTP request success callback, otherwise this will keep the network activity spinner active longer than it actually should be.
If you need to manage multiple requests of the same type, you could add a "tag" property to your custom request, so that when your success/failure delegate response is called, you can easily identify which request it belongs to without having to keep an instance variable to the original request.
Not even sure if the title is correct, however, what I'm trying to do is use the standard NSURLConnection class to handle responses from calling my webservice. I am using the POST method to update a database and the GET method to retrieve rows from the database. The problem I have is that these 2 actions may occur simultaneously so that the methods to handle the request may step on each other. In other words in my "connection didReceiveData" method I have 2 paths through the code depending on whether I'm handling a response from a GET or POST request.
I keep track on which request in being processed by an instance variable called requestType. The problem is that since the requests are being executed simultaneously the instance variable is being changed from GET to POST before the GET completes (or vice-versa). My question is how do I maintain 2 separate requests in this scenario? Do I synchronize the requests? Is there a way for threads to work here? Do I create 2 separate objects for each of the requests and have the logic in "didRecieveData" query for which object is being processed? Any help would be much appreciated!!
Dealt with a similar issue in one of our apps. The solution involved creating a class that represents a webservice call, responsible for calling its own url, loading its own data, etc. The call class had a delegate that would handle parsing the responses (in our case, a web service controller). Wound up getting rather complicated, but prevented the issue of NSURLConnections stepping on each other.
Seems like you've created a messy problem by having a class that tries to do too many things. I would suggest taking one of the following three approaches:
1) Write two classes, one for updates and one for retrievals. Each class creates it's own private NSURLConnection object and acts as the delegate for the async notifications received from the NSURLConnection. The classes could possible share some utility parsing code or extend a base object that has that parsing code in it. But the key being that the code calling these classes would instantiate one of them, make the call, and then release it. This will keep your code cleaner and will insure that the event notifications don't get intermingled.
2) Create a single class that, depending on initialization, does either a post or a get with it's own private instance of NSURLConnection. When a call needs to be made, instantiate the class, get the results, and then release the class.
3) Write your connection handling classes so they use the synchronous NSURLConnection method and call that call that class in a background thread.
Either way, clean code and clear object orientation will prevent messy scenarios like the one you're describing.
Create separate objects that handle the calls. If you want to issue multiple requests at once I would strongly recommend looking at NSOperationQueue, and making these objects subclasses of NSOperation... much nicer way to deal with multiple background requests.
A good example is here:
http://www.cimgf.com/2008/02/16/cocoa-tutorial-nsoperation-and-nsoperationqueue/
The idea there is that you use the non-asyncronous web calls, in operations that are run on separate threads. You can still use asynch calls in NSOperation as well, but doing so is a little trickier and for simple calls you probably do not need to.