I am new to Blackberry playbook native development, I feel some difference(in handling touch events) with existing platform like android, iPhone and nokia, in existing platforms we just register a callback with an event and callback got called as soon as there is some event and all that stuff is parallel where as in blackberry you have to query device if there is some event present or not and this is somewhat serialized and due to this users has to experience some delays for their input to work.
So to handle this scenerio I have decided to create a thread and in thread routine there would be an infinite loop that will keep on querying device and as soon there is some event available code will handle this.
Now I have two questions
1. Is this is the best way we can handle this scenerio, If No how could I efficiently handle this kind of scenerio.
2. If this method is right to cater this kind of scenerio then I am having trouble in getting screen events in child thread, I have created screen context, init egl and requested screen events in parent/main thread.
Please guide me
Regards
Ahsan
Related
Does anyone have and definitive information on how iOS handles a UINavigationController stack it the user is allow to keep drilling-down. Will it actually start to free up memory by saving the state of the previous controllers?
This has been asked on here before, but the answers have been contradictory, so if anyone really knows how this is handled that'd be very useful.
If not, does anyone know of a subclass that will handle this?
Basically, it depends on the implementation of your controllers.
When you keep pushing controller on to a navigation controller, eventually memory will get low. Controllers that you pushed on a navigation controller will not be released for you when memory gets low, though.
What happens is your controllers get a notification which is handled in your controllers' didReceiveMemoryWarning method. There you can release all the objects used in your controller that are not necessary anymore or can be recreated when the controller is popped back.
Memory is a critical resource in iOS, and view controllers provide built-in support for reducing their memory footprint at critical times. The UIViewController class provides some automatic handling of low-memory conditions through its didReceiveMemoryWarning method, which releases unneeded memory.
Prior to iOS 6, when a low-memory warning occurred, the UIViewController class purged its views if it knew it could reload or recreate them again later. If this happens, it also calls the viewWillUnload and viewDidUnload methods to give your code a chance to relinquish ownership of any objects that are associated with your view hierarchy, including objects loaded from the nib file, objects created in your viewDidLoad method, and objects created lazily at runtime and added to the view hierarchy. On iOS 6, views are never purged and these methods are never called. If your view controller needs to perform specific tasks when memory is low, it should override the didReceiveMemoryWarning method.
I've joined a project that uses Jax-RS (and originally there was quite a bit of Spring-based Controller code in there too, but all URL handlers use Jax-RS now). Now we want to be able to fill in a queue of tasks that should be run with a small delay between each of them. The delay can be specified in ms. I've avoided Thread.sleep, as I've heard you should not manage threads manually in Java EE. Before I came in there was already a busy wait loop implemented.
I would like to switch this to an asynchronous background task. I could of course let the client poll the server with the given delay, and just have an AsyncResponse that can be resumed. But can the same AsyncResponse be resumed/suspended multiple times? The resource does have state, so it would be possible to drop the asynchrony completely and just do client polling to handle all of it.
A lot of example code for showing off asynchronous tasks use Thread.sleep. How bad is it to do this in a background task on an ExecutorService or something similar?
The point of the delay is to simulate human interaction, and post a long list of JMS messages to a queue but ensure that two listeners don't pick up and handle messages that depend on one another.
Is it easier/better to handle this on the client side rather than the server side? Writing some JavaScript that handles all the polling would be quite simple, so if this seems like a bad idea for handling on the server side, it's not that big a deal.
The tool is only going to be used by a single user, as it's a developer testing tool. Therefore we went for solving this on the client side, pushing the messages onto the queue through AJAX calls. This works fine for our purposes, but if anyone has a solution that might help someone else. Feel free to drop a new answer.
Overview:
I am trying to create a PoC application that mimics WebIntents-like feature.
So, in my Qt application, I create two QWebviews launching two different webApps. Now let's call them apps A and B.
Scenario:
Main Application creates two QWebViews each launching an App i.e. AppA, AppB.
App A is programmed to fetch some data via AJAX, automatically.
App B also needs part of that data. AppB simply displays a button (HTML) called .
Note: Since, AppA already has that info, I would like the AppB to invoke a JavaScript API which was injected into it's(appB) DOM by means of addToJavaScriptWindowObject() method call when the QWebView was launched.
App-A completed the Ajax Call and indicates the completion in its WebView.
User clicks the button in AppB,
App B invokes that JavaScript API i.e. fetcData({source: "AppA");
Now the control is in the QT-world:
Question: the Control is in the context of AppB, How should I communicate with the WebView in AppA -- i.e. AppB asks AppA: hey AppA, please give me that data that you have fetched?
Can Signals and Slots help me here? Or should I use some other form of IPC.
I read this page: http://qt-project.org/doc/qt-4.8/qtwebkit-bridge.html, but I still didn't get a hint for a solution for my problem.
Another related question: Are QWebViews created in their own threads ?
Can't you just emit some sort of signal from AppB that basically says, "Hey, I finished fetching my data if anyone wants it" or am I missing something? It would happen at the end of AppB::fetchData().
All you have to do after that is connect any interested objects to that signal.
I have a childwindow with an associated VM that gets created each time I ask the child window to open. when the childwindow opens, it registers a listener for an MVVM Light message. After I close the window, I'm pretty sure that I'm releasing all references to it, but I don't actually call dispose because it does not implement IDisposeable.
When I instanciate another child window of the same type, and send it a different context, I know that I'm receiving the message from the previous instanciation of the VM... each time I use the window, more and more VM are listening, and the code repeats.
How can I be sure that my previous VM that registered to listen to a message, has actually been released and is no longer active. Is there a deterministic way to do this?
Whenever you register a message you should make sure that you unregister the message as well. To unregister you can use Cleanup method on classes deriving from ViewModelBase. In other cases, e.g. a view, you should implement a method hat is called when the view is unloaded - e.g by trapping and handling the unloaded event on a control or view. In this method you then call Messenger.Unregister(EventTarget).
This behaviour is a quirk in the current version of the toolkit, and Laurent is aware of it.
How have you coded the handler for the message in the VM? It sounds like you're probably pointing it to a method inside the same VM which is registering for the message. This causes the Messenger class to maintain a reference to the VM and prevent it's garbage collection (see here for discussion). There are two solutions: implement IDisposable and unregister all messages for your VM instance or simply unregister all messages from the VM instance when the child dialog closes. Personally I'd do both to ensure the entire object web is released.
You can use either the Cleanup method or manually unregister the message. For more details click here.
I am writing a custom Windows Workflow Foundation activity, that starts some process asynchronously, and then should wake up when an async event arrives.
All the samples I’ve found (e.g. this one by Kirk Evans) involve a custom workflow service, that does most of the work, and then posts an event to the activity-created queue. The main reason for that seems to be that the only method to post an event [that works from a non-WF thread] is WorkflowInstance.EnqueueItem, and the activities don’t have access to workflow instances, so they can't post events (from non-WF thread where I receive the result of async operation).
I don't like this design, as this splits functionality into two pieces, and requires adding a service to a host when a new activity type is added. Ugly.
So I wrote the following generic service that I call from the activity’s async event handler, and that can reused by various async activities (error handling omitted):
class WorkflowEnqueuerService : WorkflowRuntimeService
{
public void EnqueueItem(Guid workflowInstanceId, IComparable queueId, object item)
{
this.Runtime.GetWorkflow(workflowInstanceId).EnqueueItem(queueId, item, null, null);
}
}
Now in the activity code, I can obtain and store a reference to this service, start my async operation, an when it completes, use this service to post an event to my queue. The benefits of this - I keep all the activity-specific code inside activity, and I don't have to add new services for each activity types.
But seeing the official and internet samples doing it will specialized non-reusable services, I would like to check if this approach is OK, or I’m creating some problems here?
There is a potential problem here with regard to workflow persistence.
If you create long running worklfows that are persisted in a database to the runtime will be able to restart these workflows are not reloaded into memory until there is some external event that reloads them. As there they are responsible for triggering the event themselves but cannot until they are reloaded. And we have a catch 22 :-(
The proper way to do this is using an external service. And while this might feel like dividing the code into two places it really isn't. The reason is that the workflow is responsible for the big picture, IE what should be done. And the runtime service is responsible for the actual implementation or how it should be done. That way you can change the how without changing the why and when part.
A followup - regardless of all the reasons, why it "should be done" using a service, this will be directly supported by .NET 4.0, which provides a clean way for an activity to start an asynchronous work, while suspending the persistence of the activity.
See
http://msdn.microsoft.com/en-us/library/system.activities.codeactivitycontext.setupasyncoperationblock(VS.100).aspx
for details.