I'm looking to control a motion controller with a joystick. Should I place the Joystick in the same thread as the motion controller or place it in its own thread?
Currently I have a UI that send requests to a thread containing the motion controller's request manager. I use a system of queues to safely transfer data.
In the past I have made an application where all the devices had their own thread. The project quickly became clunky and messy. I am new to working with hardware. I would greatly appreciate any references or books suggestions.
Related
I have recently created a custom framework that is planned to be re-used for multiple projects. The catch is, this is for a plugin, and knowing that we can't simply embed the framework within the plugin's bundle, due to symbol collisions and what-not, I'm thinking of simply embedding it with the plugin's XPC. On a side-note, this framework will be used to launch custom interfaces, such as a view controller, views, and use some delegates slapped inside it that the plugin will have to take ownership (which I am hoping). Which brings me to my question: is it possible for a different process to take ownership of objects instantiated in the XPC? I am quite new to using frameworks, so I've spent hours trying to jerry-rig stuff together in XCode based on tutorials I've found online, sadly to no avail.
A framework is a bundle of code and resources that can be used, and reused, by multiple applications. It can be embedded within your application, be part of the operating system (the entirety of Cocoa is actually a collection of frameworks), or dynamically located and programmatically loaded at runtime. Once loaded, the framework's code, classes, and resources appear to the application as if they had been compiled directly into the host app. The key is that the code executes directly, in your process's memory space.
XPC is an inter-process communications facility. It allows one process to send and receive messages with a different process. It cannot be used to communicate with itself.
You cannot "take ownership" of an object using XPC. All XPC messages serialize ("archive" in Cocoa-speak) any object and de-serialize that object on the receiving end. The second process now how a replica of the original object; it is not a reference to the original object and is constrained to the boundaries of its process.
If your second process needs to display something, you have (basically) three options:
(1) Make the second process its own application. The second process can be a full-fledged Cocoa app with windows and so forth. You can make it an "accessory" app, so it does not have a menubar or appear in the dock. See LSUIPresentationMode Info.plist property and/or NSApplication.activationPolicy.
(2) The advanced technique is to use an IOSurface. An IOSurface is, essentially, a method by which a second process (your XPC Service) can draw directly into a window of your application. Again, the drawing objects still exist—and are completely isolated in—the second process; but what they draw will appear in your application as if they were local view objects. (This is how Safari works; every browser page is rendered by an isolated background process drawing into a surface.)
(3) Use a poor-man's IOSurface: send your data to the second process, have it render the results into something (pixel array, TIFF, PNG, ...) that can be serialized and drawn by the host app, then use XPC to send that rendered image back to the host app for display.
Daemons and Services Programming Guide
IOSurface
I am trying to collect GPS location every 5 seconds from a smart phone by using socket.io.
I notice that when users pick up a phone call, socket.io will stop emitting messages. When users switching tabs in the browser, socket.io will stop emitting messages too.
Does anyone know how to solve this problem?
Thanks very much!
Your best bet would be to package the website in a native app. Use a service such as http://build.phonegap.com or Intel XDK. There are configuration options to keep your app alive in the background. As for it disconnecting during phone calls, this is a carrier limitation. If the user was connected to WIFI, most phones will that for data while simultaneously on a call.
Some networks (such as Verizon) do not have the capability to do voice and data at the same time. Thus, when a call is made, data is suspended until the call is finished. AT&T does not have this limitation.
The operation of background tabs will vary by mobile browser and is likely done for battery conservation reasons. It is unlikely there is a work-around to keep the background tab running (because that would defeat the whole battery management purpose).
I’m working on an application for a motion tracking device and have discovered some odd behavior that got me curious. The device SDK consists of three DLLs, one of them (the main referenced DLL being used in the application) non-native, and the other two native.
The application has three main actors, the Controller (connection between device and application), Listener (receives tracking information) and an endless stream of Frame objects (the data the Listener receives). All these items are disposable, in turn I believe they use unmanaged resources.
If I do not remove the listener from the controller and then dispose of the controller, the application will crash on subsequent startup. This behavior is sporadic, it might happened at the second, third or later startup.
Although I am making sure I am disposing the objects, I’m still very curious what logic or lack of logic can cause this type of behavior. Because I expect all objects to be disposed when an executable stops running.
Could the device drivers hold onto a reference? And what would be the best way to troubleshoot this?
So the question is not how to dispose, but what would/could cause this, and why- and how can I Sherlock Holmes this.
More information:
No exceptions
Attaching a debugger doesn't provide more information
I have an app which needs almost no user interaction, but requires Geofences. Can I run this entirely within a background service?
There will be an Activity when the service is first run. This Activity will start a service and register a BroadcastReceiver for BOOT_COMPLETED, so the service will start at boot. It's unlikely that this Activity will ever be run again.
The service will set an Alarm to go off periodically, which will cause an IntentService to download a list of locations from the network. This IntentService will then set up Geofences around those locations, and create PendingIntents which will fire when the locations are approached. In turn, those PendingIntents will cause another IntentService to take some action.
All this needs to happen in the background, with no user interaction apart from starting the Activity for the first time after installation. Hence, the Activity will not interact with LocationClient or any location services.
I've actually got this set up with proximityAlerts, but wish to move to the new Geofencing API for battery life reasons. However, I have heard that there can be a few problems with using LocationClient from within a service. Specifically, what I've heard (sorry, no references, just hearsay claims):
location client relies on ui availability for error handling
when called from background thread, LocationClient.connect() assumes that it is called from main ui thread (or other thread with event looper), so connection callback is never called, if we call this method from service running in background thread
When I've investigated, I can't see any reason why this would be the case, or why it would stop my doing what I want. I was hoping it would be almost a drop-in replacement for proximityAlerts...
Can anyone shed some light on things here?
The best thing would be to just try it out, right? Your strategy seems sound.
when called from background thread, LocationClient.connect() assumes that it is called from main ui thread (or other thread with event looper), so connection callback is never called, if we call this method from service running in background thread.
I know this to be not true. I have a Service that is started from an Activity, and the connection callback is called.
I dont know about proximity alerts; but I cant seem to find an API to list my GeoFences. I am worried that my database (sqlite) and the actual fences might get out of sync. That is a design flaw in my opinion.
The reason LocationClient needs UI, is that the device may not have Google Play Services installed. Google has deviced a cunning and complex mechanism that allows your app to prompt the user to download it. The whole thing is horrible and awful in my opinion. Its all "what-if what-if" programming.
(They rushed a lot of stuff out the door for google IO 2013. Not all of it are well documented, and some of it seems a bit "rough around the edges").
We have a system where there are typically two processes running on the same system. One process handles the GUI and the other runs like a service (although for historical reasons, it's not a service, just an exe with no visible window).
The two processes undertake IPC mainly via registered messages asynchronously - i.e. we use RegisterWindowMessage() in both processes to define a large'ish set of messages that effectively form the API to the server process.
I have written a "hands-free" monitoring application that uses SetWindowsHookEx() to monitor and display the message queues of both processes and provide some level of decoding of the way the API is being utilised and how notifications are being propagated to the GUI process (each individual window can subscribe to notifications from the server directly).
So, there are a large number of messages in both directions so I have filtering and summary counts etc. so I can focus on particular activity. All this can be done without affecting the live code, which is good.
This all works well, but it now would be very useful to be able to "tag" a message originating in the GUI so I can trace the same message when it's processed by the server. This would be enormously useful for debugging and diagnosing system issues, but I can't find a clean way (actually I can't find any way!) of doing this without adding such support to our registered message API, which would be a lot of work and involves more risk than I'm comfortable with at the moment. It gets further complicated by the fact that the server pre-processes some messages and then does a PostMessage() back to itself to perform the action, so the originating message can get "lost".
Has anyone here tackled this type of problem? If so, can you give me some pointers? If not, then are there any documented or undocumented ways of adding a small block of data to a Windows message and retrieving it later? I've looked at SetMessageExtraInfo() but that seems to be per-queue rather than per-message.
FindWindow or FindWindowEx will give you the details of the GUI Window. Compare the details with message intercepted