I'm just starting off on my first attempt at the MVP architecture in GWT.
My understanding is that the job of PlaceTokenizer.getPlace(String) is to take the token in the URL after the hash, parse it, and return a Place with the object to which that token refers.
In my application, I have a resource (say, a video), which I tokenize by the video's unique id. Then my getPlace method ought to take this id, and retrieve the video information from the server. Is this the right approach?
As far as how to execute this, the only way that I could figure out would be to have my RemoteService right on the PlaceTokenizer, and make the call right in that getPlace method. Something about this made me hesitate. It seems like the call would be better suited for the Activity or somewhere else.
Is this how it's done? If not, is there a better way?
Your Place doesn't need to download the video. It could just contain the video's id.
Your Activity will receive the Place, which has the video id, and now the Activity can do the downloading or whatever heavy lifting you want.
So: Your PlaceTokenizer only needs to know enough to store the video id in the Place. Let the Activity do the work after that. The only function of getPlace is to turn a String into a Place.
It helped me to mentally rename Place to PlaceTag. The place objects really do not represent places - they represent tags or pointers to places. The actual place is represented by, terribly, the Activity.
if i may help clarifying the place signification a little more. Your place object is a serializable representation of the state of your client. it will help the activity restoring the screen to its former state by containing all the information you need to build it back.
Related
I'm working on an app that needs to be able to upload an array (can contain a mix of UIImage or a custom struct that contains a local file URL and some data). I've seen Operations and OperationQueues as a possible starting point but I don't know if I'm looking in the right direction.
Hopefully, this image can provide some clarity regarding what I need to accomplish. Basically, each ProgressViewController can have its own "uploadable" array and I also need to track the progress for each upload. I know I need to use the URLSessionDelegate methods for tracking progress, but are Operations, OperationQueues and a singleton "UploadManager" of sorts the way to go?
Thanks for your help guys!
Assume a page that shows a complex data structure (for example, an article with many details). This view will be reused from time to time by rebinding it to different articles.
Now, I noticed that the ODataModel keeps all used article entities in memory (also if they are no longer bound to any control).
This will lead to two issues:
Memory consumption increases over time (if application will not be reloaded).
If the application forces a refresh of the data model, all entities will be loaded (also not used).
The second issue seems to be the bigger problem. It slows down the speed of the application.
I have not found a solution for that problem. If I use refresh(true, true) it seems all data will be reloaded.
Is there an way to clean the model?
Edit
Lets say you have a list of thousands of articles. User can click on one of the articles and will navigate to a detailed screen of that article.
The OData model in client side will cache this. To see it, do something like:
var oModel = this.getModel("modelName");
look with the debugger into oModel.oData.
If the user now navigates back and chooses the next article, this will be cached as well.
If user does this 1000 times, all articles are now in the model.
If you trigger a oModel.refresh(true);, all these data (of 1000 articles) will be reloaded not only the one bound to the view.
Now my application is not about showing article information. It's a more complex structure with subitems. Each time user is visiting this page, more data will be cached (and re-fetched in case of a refresh call on the model).
Edit 2
The function updateBindings(bForceUpdate?) seems to help a little bit.
Anyhow, the data accumulation is still there in the ODataModel class.
That means: Each visited data path will stay in memory since the next reload (F5) of the full page. If someone uses such an application over a day, the data accumulates and a refresh call on the model will read all data again, if still bound to a view or not.
Try deleteCreatedEntry(oContext). Even though this is not the supposed use case for this method it might work to delete an entity from the model without triggering a backend request.
You could also try if updateBindings(bForceUpdate?) only triggers an update on actually bound entities.
1) I do not really understand your problem here. What is it exactly that you do? OData always holds the result of your request plus a queue of changes to that request. If you create lots of entries while your application is running, of course the memory consumption will increase. If you want to revert back to the original request you can use resetChanges(). THis way the used memory should decrease again. But you lose all your changes to the model.
2) Maybe you should look into Odata filtering (http://www.odata.org/getting-started/basic-tutorial/) so that you only load the entities you really want. If you only want a part of the entity loaded then you should maybe redesign your entities to avoid a lot of overhead.
It is hard to speculate what your exact problem is.
Well, if you know exactly what are you doing, you can try something like this:
this.getModel("modelname").aBindings = []
Better solution would be go through the aBindings array and remove redundant bindings.
I am using a custom AuthAttribute to determine whether a user can access a controller and/or actions. The problem is I have to duplicate information and EFx connections in the attribute that already exist on the class that is being adorned.
My question is whether there is a way to access the fields on the adorned class from the custom AuthAttribute? I am trying to avoid having to re-architect the software in a way that would provide a single point of access since that would open up a different can of worms.
I believe I have found an answer that works. I welcome all comments on this solution.
Rather than have the attribute gain access to the properties and fields on the controller it adorns you can share values between them in a thread-safe way through the common HttpContext object. So if you are being extreme like I am and are trying to cut down on duplicate calls to your database in both the authattribute and the adorned controller action then pass the results forward. What that means is the authattribute will be called first and you can stash the retrieved values in the "Items" collection off the HttpContext object passed into the AuthorizeCore(..) method. You can then retrieve the same value in a THREAD-SAFE way through the HttpContext object in the controller.
example to save value within the AuthorizeCore(..) override of the AuthAttribute:
httpContext.Items.Add("fester", "bester");
example to retrieve value inside the subsequent call to the Controller/Action:
this.HttpContext.ApplicationInstance.Context.Items["fester"];
I have to warn you this is only a possible implementation that appears to work in simple testing. Personally it feels like a hack and there has to be a better way. I would also state this is in pursuit of a dubious performance benefit. It should cut down on the number of database and/or network calls by cache'ing retrieved data in the HttpContext so you don't have to repeat the calls in both the authattribute and the adorned Controller/Action. If you don't have a web site that gets a huge volume of calls then I would warn you against this.
I hope someone recommends something better on this page. I will keep an eye on how this works on my web site and let y'all know if it behaves and is truly thread-safe.
I have an application which must save client instances of com.smartgwt.client.widgets.Canvas to a disk on the server, and then restore them.
My solution is to serialize the canvases, send them to the server to be saved, save them, load them, send them back to the client, and then deserialize.
Currently, the network transfer code is all in place. The only thing left is serializing the canvases. However, I want to know if doing so is even possible? If not, any workarounds? Clues?
Thanks,
Ian
I would suggest that you do not serialize the Canvases themselves, but instead save their state. Depending on what the canvases contain, this can be easier or harder, but in most cases makes better sense than trying to save the objects themselves. SmartGWT provides API calls to save the state of some complex object, e.g. ListGrids . For simpler objects you can come up with a way to store their view state, e.g by using a JSON object that holds of what is important to your case.
I've not found a answer to this question anywhere, but this seems like a typical problem:
I would like to send some POST-Requests (with ASIHTTPRequest, what I already do), but if something goes wrong, ther user can decide to "Try Later", that means, the task should be put on a queue and this queue should be read next time the application starts. So, that's my question: how to "save" the queue, so that the app can read it next time it starts? Is it possible to "read" the queue and try sending this POST-Request again, let's say, 10 min later, even if the application is not running?
What kind of documentation should I read in order to be able to do this?
I would be very glad to hear any answers. Thanks in advance.
P.S.: Another Idea I have: as I just have to Upload Photos, I could have a folder with all the Photos that still need to be uploaded, and when the App starts, the app looks at this folder and try to send all the photos in this folder. Does it make sense?
My approach for this issue would be like this:
Whenever you fail to send details - write content of the array to a file using '[NSArray writeToFile:]' you can use serialization if array contain any data which is custom defined (if your array contain standard cocoa objects(NSString,NSData etc) they already implemented with serialization )
When app launches; load the content from file directly to an array object ('[NSArray arrayWithContentsOfFile:]')
then construct http request and try sending. In application the data(in your case array) is stored/serialized not the request, you need to reconstruct the http request when you want to try one more time.(don't try serializing ASIHTTPRequest, you have reconstruct it)
I'm going to assume you've already looked at NSOperationQueue and NSOperation. AFAIK there is no built-in support for serializing NSOperation, but you could very easily write your own serialization mechanism for an NSOperation subclass that you use for posting data and write the an NSOperationQueue's operations to disk if something goes wrong.
Without knowing too many details it's hard to give a precise answer. There are many ways to write data to disk and load it again later, the direction you take will be largely dependent on your situation.