Is it possible to manually create WebDataSource objects and then set the created object to be the datasource of a webFrame object? I can't seem to find a method on WebFrame class that allows the setting of datasource. The goal is to asynchronously pre-load webpages without having to render them in a web view all at once.
Just use an offscreen WebView. It'll load the resources for you and not waste time drawing itself.
(I gather this is a follow-up to the question I answered a little while ago?)
As I alluded to in my comment on that question, you use one of the -[WebFrame load...] methods to load content. When you issue the load request the WebView instantiates a -provisionalDataSource which in turn becomes the -dataSource (so much for clear naming!). As the class documentation summarizes:
The provisional data source transitions to a committed data source
once any data is received.
Unless you are extending WebKit, I don't think there is usually a reason to create WebDataSource instances directly. Let WebFrame do it for you.
Related
I have a Xamarin.Form app, using Prism for MVVM, navigation, DI.
In a Page I download a dataobject from a WS, and I need to maintain it along with other dataobjects downloaded along the way (along with states, flags that doesn not really fit to be stored in Settings/Preferences), to be used in other pages of my application, so how can I pass it around?
I can collect all this data that must be used in various pages in a single "GlobalData" object, but what are the pros and cons of each possibile solution, of the following ones.
I excluded:
passing it as a NavigationParameter, because I see it as impractical to have to include the object each time I navigate to, I prefer the object to be available or instantiated everytime a page is created
I experimented with:
1 storing and retrieving from SQLite and LiteDB
2 storing and retrieving from MonkeyCache and Akavache
3 storing and retrieving from a global App object
4 injecting the object with Prism DI in each page
All the solutions work on my tests, starting from the easiest to implement, I would use 3, then 4, then 2, then 1.
Using a glboal App object is by far the easiest, I know the pros but what are the cons?
I just want to understand if there's something fundamentally wrong in each of the approach.
Thanks!
You missed the most obvious option - passing the data around during navigation.
INavigationService.NavigateAsync takes a parameter of type INavigationParameters which can store abitrary data. The same instance then shows up in the view model that's navigated to (if it implements INavigationAware).
I have found it useful to maintain singleton models for my view models to access. Some care needs to be taken to manage this data. I clear the data when it is not relevant. Since my workflow is fairly linear I populate it at key points in the workflow. Typically the models contain just DTOs and collections with initialization and clear methods.
Most of the article's talk about how to work with the forms like <form:form> Spring tags just with one bean(entity), but in my web app I have more then one bean(actually 3 of them, wich is mirror to my data model in DB(MySql)). What I want is to put values for all of the properties in my entities classes from one form(it may be a jsp or xhtml or html, whatever).
So, I'm kinda new in Spring MVC and as far as I know it has backing object which comes with <commandName> tag in <form:form> tag and I suppose to think that it may be just one commandName backing object for each form??
Q: - Could you please tell me how to easily(or direct me to any example's) to fulfil my pleasant headache.
Q: - It also may have something to get attributes in one controller class but by different methods. Do I have to store them in session or request? I'm thinking to have ModelAndView class for store multiple attributes in map and after store them in ModelAndView (in model). What you suggest?
hope you are having a wonderful day!
I'd suggest you investigate the technique detailed here:
http://forum.springsource.org/showthread.php?58993-Need-to-Populate-Form-data-into-multiple-java-beans
Also, I'm wondering if there could be a terminology issue here. Do you mean you actually want to have just one form on your UI, with a lot of inputs, or do you really mean you want it all on one SCREEN or page? I say that as its also possible to have multiple forms on one UI screen and go that route... which in fact might be easier, as you could then break up your processing into multiple controllers.
Another consideration on the above relates to screen design... if you are going to be populating the data for several beans from one screen, potentially that could be a LOT of data and your screen could get very cluttered and hard to read. So from that standpoint it might also be better to consider breaking your input controls up into multiple (related) screens. There is a little more about that at the bottom of the article I linked above.
You can refer: https://stackoverflow.com/a/4986410/1882833
One approach would be to have a seperate class which encapsules the required objects. And then use it as a command to set and get the data.
I need to instantiate some properties with the content of the saved document. Since theses properties are used by my interface, I would like to instantiate them before the NIB is loaded.
At which point of my initialization can I access the data of the loaded document ?
If possible, I would like to access it not from the initFromURL method. Indeed, when I create a document, I also create this data. So, if it is possible, I would like to put the instanciation at only one point, that will work for both the creation and the opening of a document.
So, is there an accessible point after the initFromURL and initWithType methods but before the windowControllerDidLoadNib.
Thanks !
Easy !
-windowControllerWillLoadNib
I have few classes for my Blackberry application right now. Now what I am doing is to create one screen for user to enter their information, store it inside the persistent storage, so that when they click Back on the navigation button, all the information they typed will be displayed on a list view.
My question is, I cannot create a class that extends MainScreen and implements Persistable at the same time because it will give me error.
How to solve this problem?
To make it easier for you guys to see, this is the fragment of the class that I have.
inMenu.add(new MenuItem ("Save",110,10)
{
public void run()
{
synchronized(uv.store)
{
Vector _data = (Vector) UserVector.store.getContents();
if (_data == null)
{
_data = new Vector();
UserVector.store.setContents(_data);
}
UserVector newRec = new UserVector();
newRec.setElement(UserVector.TITLE,titleLabel.getText());
newRec.setElement(UserVector.VENUE,venueLabel.getText());
newRec.setElement(UserVector.DESCRIPTION,descriptionLabel.getText());
_data.addElement(newRec);
UserVector.store.commit();
}
Dialog.inform("Information Saved!");
}
});
You are witnessing true proof of BlackBerry programming not being Java: the fact that an interface (Persistable) is not inherited.
In BlackBerry, if you want to persist a class, marking it as Persistable isn't enough. The entire class hierarchy upwards should be persistable. At the same time, marking a class Persistable would make you think that a subclass will inherit persistable, but it doesn't. You'll have to explicitly mark the subclass as Persistable. (I know, at this point you are probably thinking about this being an heresy, an atrocity, an ..., well, BlackBerry programming is full of tricky things like this). Think of Persistable as a marker interface which is not inherited.
In your case, you have a Runtime error telling you that in order to persist your screen, you'd have to make MainScreen implement Persistable, which of course you can't because you don't have access to the source code. Even if you could, there's another caveat: every field, collection, container in your screen should also be Persistable for the thing to work, otherwise you'd get an exception. So you are completely out of luck here because neither Field or its subclasses do implement Persistable.
But in any case, even if it were possible, it is not advisable to save an entire View (with its many nested objects) just for convenience. Instead, save the content of the fields and screen state in an small container object (implementing Persistable) and restore the screen when entering the app. This approach allows you to reuse your container object in case new Fields are added or removed from the GUI (otherwise you'd have to clean simulator memory each time you change the GUI design to avoid ClassCastException loading the screen from persistence). Because you are decoupling GUI from persistence, it also allows you to choose which fields are saved and which ones don't need to.
A MainScreen is a very complex class with many user interface elements in it. Even if you could persist an entire MainScreen I can't imagine why you would want to. The MVC pattern suggests that you keep the model (your persistent store) separate from your view and controllers.
It is probably easies to combine the view and controller in the MainScreen, but you can separate them out.
Another argument for not putting extraneous stuff in your persistent store, is every time you change it you have to either provide for migrating the old format storage to the new format, or force your users to re-enter the data again.
From the looks of it your UserVector class should implement Persistable and should have static methods for storing and retrieving a UserVector object from persistent memory.
Check out http://docs.blackberry.com/en/developers/deliverables/7693/Persistent_data_storage_509562_11.jsp for a good introduction to persistent storage.
Persistent memory is a bit like the Windows registry. You can lookup objects using a unique key, manipulate them, then save them back there as long as they are serializable (persistable). Do not try to save anything to do with your UI into persistent memory, only save data.
Also, if you are saving many user data, you might be better off looking at an SQLite database for storage.
I have two classes that each need an instance of each other to function. Ordinarily if an object needs another object to run, I like to pass it in the constructor. But I can't do that in this case, because one object has to be instantiated before the other, and so therefore the second object does not exist to be passed to the first object's constructor.
I can resolve this by passing the first object to the second object's constructor, then calling a setter on the first object to pass the second object to it, but that seems a little clunky, and I'm wondering if there's a better way:
backend = new Backend();
panel = new Panel(backend);
backend.setPanel();
I've never put any study into MVC; I suppose I'm dealing with a model here (the Backend), and a view or a controller (the Panel). Any insights here I can gain from MVC?
It's time to take a look at MVC. :-) When you have a model-view-controller situation, the consensus is that the model shouldn't be aware of the view-controller (MVC often plays out as M-VC), but the view is invariably aware of the model.
If the model needs to tell the view something, it does so by notifying its listeners, of which it may have multiples. Your view should be one of them.
In a circular construction scenario I'd use a factory class/factory method. I would normally make the construction logic private to the factory (using friend construct, package level protection or similar), to en sure that no-one could construct instances without using the factory.
The use of setter/constructor is really a part of the contract between the two classes and the factory, so I'd just use whichever's convenient.
As has been pointed out, you really should try to find a non-circular solution.
First of all, contrary to what others has said here, there's no inherent problem with circular references. For example, an Order object would be expected to have a reference to the Customer object of the person who placed the Order. Similarly, it would be natural for the Customer object to have a list of Orders he has placed.
In a refernce-based language (like Java or C#) there's no problem, at all. In a value-based language (like C++), you have to take care in designing them.
That said, you design of:
backend = new Backend();
panel = new Panel(backend);
backend.setPanel(panel);
It pretty much the only way to do it.
It's better to avoid circular references. I would personally try to rethink my objects.
panel = new Panel(backend);
You do this in this routine something like
Public Sub Panel(ByVal BackEnd as BackEnd)
Me.MyBackEnd = BackEnd
BackEnd.MyPanel = Me
End Sub
You don't need BackEnd.SetPanel
It is better to use Proxies. A proxy links one object to another through raising a Event. The parent hands the child a proxy. When the child needs the parent it calls a GetRef method on the proxy. The proxy then raises a event which the parent uses to return itself to the proxy which then hands it to the child.
The use of the Event/Delegate mechanism avoids any circular reference problems.
So you have (assuming that the backend is the 'parent' here)
Public Sub Panel(ByVal BackEnd as BackEnd)
Me.MyBackEnd = BackEnd.Proxy
BackEnd.MyPanel = Me
End Sub
Public Property MyBackEnd() as BackEnd
Set (ByVal Value as BackEnd)
priBackEndProxy = BackEnd.Proxy
End Set
Get
Return priBackEndProxy.GetRef
End Get
End Property
Here is a fuller discussion on the problem of circular references. Although it is focused on fixing it in Visual Basic 6.0.
Dynamic Memory Allocation
Also another solution is aggregating Panel and BackEnd into another object. This is common if both elements are UI Controls and need to behave in a coordinated manner.
Finally as far as MVC goes I recommend using a a Model View Presenter approach instead.
Basically you have your Form Implement a IPanelForm interface. It registers itself with a class called Panel which does all the UI logic. BackEnd should have events that Panel can hook into for when the model changes. Panel handles the event and updates the form through the IPanelForm interface.
User clicks a button
The form passes to Panel that the user clicked a button
Panel handles the button and retrieves the data from the backend
Panel formats the data.
Panel uses IPanelForm Interface to show the data on the Form.
I've been delaying implementing the lessons learned here, giving me plenty of time to think about the exact right way to do it. As other people said, having a clear separation where the backend objects have listeners for when their properties change is definitely the way to go. Not only will it resolve the specific issue I was asking about in this question, it is going to make a lot of other bad design smells in this code look better. There are actually a lot of different Backend classes (going by the generic class names I used in my example), each with their own corresponding Panel class. And there's even a couple of places where some things can be moved around to separate other pairs of classes into Backend/Panel pairs following the same pattern and reducing a lot of passing junk around as parameters.
The rest of this answer is going to get language specific, as I am using Java.
I've not worried a whole lot about "JavaBeans," but I have found that following basic JavaBean conventions has been very helpful for me in the past: basically, using standard getters and setters for properties. Turns out there's a JavaBean convention I was unaware of which is really going to help here: bound properties. Bound properties are properties available through standard getters and setters which fire PropertyChangeEvents when they change. [I don't know for sure, but the JavaBeans standard may specify that all properties are supposed to be "bound properties." Not relevant to me, at this point. Be aware also that "standard" getters and setters can be very non-standard through the use of BeanInfo classes to define a JavaBean's exact interface, but I never use that, either.] (The main other JavaBean convention that I choose to follow or not as appropriate in each situation is a no-argument constructor; I'm already following it in this project because each of these Backend objects has to be serializable.)
I've found this blog entry, which was very helpful in cluing me into the bound properties/PropertyChangeEvents issue and helping me construct a plan for how I'm going to rework this code.
Right now all of my backend objects inherit from a common class called Model, which provides a couple of things every backend in this system needs including serialization support. I'm going to create an additional class JavaBean as a superclass of Model which will provide the PropertyChangeEvent support that I need, inherited by every Model. I'll update the setters in each Model to fire a PropertyChangeEvent when called. I may also have JavaBean inherited by a couple of classes which aren't technically Models in the same sense as these but which could also benefit from having other classes registered as listeners for them. The JavaBean class may not fully implement the JavaBean spec; as I've said, there are several details I don't care about. But it's good enough for this project. It sounds like I could get all this by inheriting from java.awt.Component, but these aren't components in any sense that I can justify, so I don't want to do that. (I also don't know what overhead it might entail.)
Once every Model is a JavaBean, complete with PropertyChangeEvent support, I'll do a lot of code cleanup: Models that are currently keeping references to Panels will be updated and the Panels will register themselves as listeners. So much cleaner! The Model won't have to know (and shouldn't have known in the first place) what methods the Panel should call on itself when the property updates.