I have an app written in Qt that has many widgets, including lists, tables, trees, line edits, etc. As the user progresses through the app, they may need to save the current state, leave, and come back later to pick up where they left off. I do not have a the data separate from the GUI (all data is stored in the widgets themselves). I have found a way to loop through all the widgets and save the current state, but it takes a significant amount of time. Is there a faster or built in way to save the current state of the GUI? I am trying to avoid re-writing the code to have a data model that is only represented by the GUI due to limited time available.
Is Qt's session management what you're looking for?
You can save every param on its actual change, or when user leaves the page, not on exit. And don't try to save every parameter of every widget, use smarter algorithm
As a good crossplatform and flexible way to save state of your GUI is to use Qt's mechanism -- QSettings (official documentation).
But, really, there are re-writing moments, which you can't avoid.
Related
Lets try this explanation again...
I'm new to polymer (and getting back into web dev after a relatively long absence), and I'm wondering what the recommended approach might be to more closely manage object state while employing 2 way databinding. I am currently consuming rest API (json) objects. My question is if polymer keeps a copy of the original object before initiating updates to the bound object's properties/attributes...so one might be able to easily undo the changes? While allowing 2 way databinding to work its magic is often desired, there are cases where I'd like to prevent / delay changes to the object / DOM until the user approves the changes (say via the paper-dialog component for instance). I suppose one could make a temporary copy of the object and bind fields to that version, and then only persist the changes back to the source object upon user approval. In any case, I'd be interested to hear thoughts and see an example or two of recommended approaches (especially if I am off-track with my ideas!)
I suppose one could make a temporary copy of the object and bind
fields to that version, and then only persist the changes back to the
source object upon user approval
This.
Consider that view-models are essentially different from pure data-models (sometimes called business-data). Frequently, the differences are irrelevant and one can use them interchangeably. However, be aware of scenarios where the view-model is distinct (uncommitted user edits are a good example).
The notion of a field editor that requires approval from the user is purely UI/View oriented. Whatever data is managed in that modality is purely in the domain of the view, and fetches/commits to the business-data should be discrete.
I'm trying to find memory leaks in a fairly large Flex application and I'm tired of using the paltry tools Flash Builder makes available.
Specifically, I want to analyse the relationships of objects in memory, using the same information Flash Builder's tools appear to have access to. I.e. which objects are in memory, and which objects they have references to, and have references to them. Given that information, I want to construct a directed graph whose nodes are live objects and whose edges are references from one object to another. From there I want to search for dominators, which should be a good indication of which objects are leaking.
I believe Eclipse does something similar for Java.
Unfortunately, Flash Builder only allows the export of its captured profiling data in a binary form that's only parsable by Flash Builder. Rather than try to reverse engineer their output I decided to try to capture the data myself, since they make their profiling API available in the flash.sampler.* package.
So far I've managed to collect the objects that are currently live in memory, get their allocation traces, and references to the objects that I can inspect, which is most of what I need. But I can't figure out how the FB profiler traces back-references to the GC root. The only way I can see to do it is to inspect every object in memory, and for each object inspect each of its properties, and so on, until I find a chain to an object classified as "root" level. But since I can only follow references on publicly visible properties, it's entirely possible I'll miss lots of references that prevent garbage collection.
How does the Flash Builder profiler do it?
My suspicion is that it doesn't just use the sampler.* API to capture information, but supplements that with queries performed through a debugger connection, which is probably out of scope for my work. But in the absence of any way to verify that, I'm hoping it's possible using only the sampler API.
Actually in IMHO if Flash (Flex) Builder's memory / performance tooling is paltry then you aren't using it right. The key to understanding the tooling you have available - has been available since the 4.0 SDK and and I've been using it for every project I've been assigned to as the 'runtime-analysis-guy'.
Live View:
We all know about this one, it gives you a "live" view of what's currently available. While the current instance count is useful, what's even more useful is the cumulative. This helps track down the errant methods which create way too many objects.
Loitering Object View:
You probably aren't using this one, but trust me once you do, you won't go back. With this it helps to have clearly defined small screen / application states (eg. 1. A starting point, 2. The ability to create a dialog 3. A closing point which is the same state as 1). In your application, get to the place you want to test. Then click the memory snapshot function - the "colored lines icon." Now in your application, run through steps 2 and 3. Go back to the profiler, and click this again. Here you can now either terminate or pause your application. Select both memory profiles and click the loitering object function - "the green icon." In theory this list will be empty, but it won't. This shows you what objects have been marked for [sweep] but not [reap]'ed.
D-Click any object and this gives you a detail view with a list of every reference that still holds onto this object. I'll give you a hint right now, if you haven't created a deconstruction process in your application (eg IDestroyable interface), stop right now and go back and do this. You must assign null to every object that is not a complex primative. This means every class, every array, vector, eventlistener and so on.
The sampler package is the only thing the tool uses as far as I'm aware - after all the tool doesn't inject any code into your application at the time of invocation. It's a comparison of all objects with the NewObjectSample and the DeletedObjectSample, and looking at the getSavedThis() going back up the prototype chain (this should return an object where you can call the getSavedThis() on it and so on).
http://help.adobe.com/en_US/flashbuilder/using/WS6f97d7caa66ef6eb1e63e3d11b6c4d0d21-7edf.html
Hope this helps.
I created my App with iOS 2.0, first using the C library directly. Then I moved on to using FMDB (much easier on me). But today, it has become too much of a hassle to manage faulting, caching and prefetching of data. I'm pretty sure that using CoreData would make the app more responsive and lighter (memory-wise).
I'm prepared to go through a long and hard work redoing everything in CD, but I need to migrate existing data. I've considered creating a new model with new objects (CDTrack, CDTrackPoint, CDSegment etc) and then move the existing data that's in objects such as Track, TrackPoint Segment to this new store. But is it really a wise idea? Are there better ways to do it than duplicating the old graph one by one?
You're basically on the right track.
What I would probably do is to create an NSOperation for migration that runs when the app starts, if the data needs to be migrated.
Depending on your application, that operation might be able to run in the background (be mindful of Core Data threading rules!), communicating with a main thread NSManagedObjectContext using notifications.
If your app doesn't make any sense without this data migrated, maybe you put up a modal view with a progress indicator while the data is migrating, giving the user a better idea of how long they have left to wait.
Depending on how much data we're talking about, you might be surprised at how quickly Core Data and SQLite can do this sort of thing... The key is to keep the user informed, do it in the minimum amount of time possible and if your application design supports it, do it in the background. Make sure to do the work off the main thread to keep the UI responsive.
Have fun!
I am developing a flex application for collaborative data analysis. To present the data my application uses standard and custom components (grids, charts etc.).
I want to deliver the feature that allows users making notes over the GUI of my application. So, other users will see they notes late on.
At the moment my question is: How can be implemented mechanism that allows making notes over the GUI? All suggestions and examples are welcome?
There are a lot of ways to approach this. ( Check out Buzzword, MS Word, and Acrobat all for slightly different approaches of note taking on a document--I assume an application GUI could use any of the same approaches ).
I'd start by saying that the click event bubbles:
http://livedocs.adobe.com/flex/3/langref/flash/display/InteractiveObject.html#event:click
So, listen for the click event on every child of your main application file. When you receive that click event you can provide some business logic as to whether or not you want to add a comment /note on the component that was clicked. Then you just some "note" component for collecting and displaying the note data. You an position them based on the x, y values of the click event.
So, actually my problem is much easier then I expected (thank for great design of Flex).
I decided to utilize PopUpManager functionality for my task. It does everything I need at the moment.
I have a flex application that repeatedly polls a remote XML file to detect changes, but I've found that once the file hits a certain size, the poll blocks the UI and makes the page unresponsive for a short time.
Is there any way to ensure that the call made to the server or the event from the flash.utils.Timer class runs asynchronously to the main UI thread?
It sounds like the blocking is caused by Flash parsing the XML rather than the actual loading.
If that is the case then you can keep loading the file and just check the size of the raw data you get back - if it's bigger, parse it and take the parsing hit. Otherwise toss the data and wait for the next request.
There's no explicit way to do threading with Flash at this time. Certain tasks happen async naturally (network and pixelbender comes to mind) but that's it.
Branden's right -- the code we write essentially always happens on the main thread; while the network call itself does happen on a background thread, the handling of that call happens on the main one.
One thing to keep in mind is that the WebService and HTTPService classes will likely attempt to serialize your responses automatically, which could mean taking that processing hit unnecesarily. Using URLLoader, on the other hand, could give you more direct access to the response data, allowing you to work more directly with it without the unnecessary overhead of that built-in processing.
In that light, if you find you do have to process the entire XML file, you might consider breaking it up into chunks somehow, and distributing the processing of those chunks into separate functions, rather than handling everything within the scope of a single function. Just doing that might allow the player to continue updating the UI while you're processing that big bunch of text (processing a bit, exiting the function, rendering the UI, entering the next function, rendering, and so on); Oliver Goldman, an engineer on the AIR team, did a presentation on this concept at last year's MAX conference.
Hope it helps!
Like mentioned, AS3 is single threaded. But there are a couple of ways to handle your situation. Here are ur possible choices:
First,make sure you really need to parse entire XML when loaded and cant just keep the loaded xml nodes in memory as the data model (XML being a native data type now). Sometimes I create value objects by passing them an XMLNode and thats kept in memory till a node value is needed at which point I read it. This allows you to keep some of the parsing for later.
If you are using an ArrayCollection or similar structure to hold data, try using a primitive Array ( see http://www.arpitonline.com/blog/?p=114 for an issue I ran into)
See if you can creatively use callLater()(http://livedocs.adobe.com/flex/2/langref/mx/core/UIComponent.html#callLater())
Can you pass the data to the client in a native format like SWX or using Remoting
Can you use data paging? ArrayCollections and I am pretty sure XMLCollection support it
Side Note:
While AS3 is single threaded, Pixel Bender and I think Alchemy (http://labs.adobe.com/technologies/alchemy/) run on a different thread. There have been a couple of experiments on blogs using Pixel Bender to do calculations which dont slow the UI of the app (Example:http://elromdesign.com/blog/2009/02/09/using-pixel-bender-to-do-heavy-lifting-calculations-makes-flash-player-multi-thread/).
Also please vote on this feature enhancement ticket with Adobe if you feel the need for this feature enough:
https://bugs.adobe.com/jira/browse/ASC-3222