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
Related
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 am building an music player using Background audio player agent on WP7. I want to enable communication between the UI part and the agent part. Many guides suggest using isolate storage, but I think that is not a good way
Is there any way to enable inter-process communication in Windows Phone 7
In Windows Phone 8 SDK, we can now use system-wide Mutex object.
It seems the foreground App and Background Agent run as separate processes on the phone. So even when you instantiate the same class, each process has a different instance.
The best solution I know about so far is to have each process map the "shared" data structure to an Isolated Storage file, then use a system wide Mutex (named Mutex) to prevent one process from reading the file when the other is writing it. It'll be simpler if one process is always the writer of the data structure, so it never has to worry about merging in changes made by the other process asynchronously. If each process must be the writer of some portion of the data structure, the usual case, consider separating those portions into separate data structures and separate Isolated Storage files, with one process reading one file and writing the other and the other process writing the first and reading the second. (all reads and writes within mutex. Use same mutex for both files and both processes to avoid deadlocks.)
try this:
phoneApplicationPage.State
What is the purpose and usings of shared services in prism ?
What things can make me think that I have to use shared services instead of EventAggegator?
Looking at EventAggregator from an event subscriber point of view, it's good for getting notified about certain events that occur in the application. This way you're performing an operation passively, i.e. whenever someone else publishes an event. You'd like to use EventAggregator when you need to react to something happening in your application.
On the other hand, with shared services you can actively perform operations and request data. For example, you could have a shared service that exposes a GetData() method, and you could resolve this service and ask for the data actively, any time you need it.
I don't know how other using it but I used it a lot for modularity of my app. For example in Silverlight application for security reasons only OpenFileDialog could return Stream to file. So I just build an IOpenFileService service and plugged it in constructor to any ViewModel that need to open a stream to file. It's also suitable for various Loggers and even Database layer.
Another useful part of services is that they could be build and tested independently from other modules. MEF/Unity will provide all the glue to insert ready objects inside constructor or properties of other objects.
And don't forget that the service class itself could use MEF/Unity magic and insert other services to itself.
And for EventAgregator: You code could became overloaded with various Event definitions very quickly. For example Resize event. On Silverlight app initialization the PRISM Region controls is slow process so the Regions was attached to VisualTree very late and somehow they missing the initial Resize event . I provided the internal Resize event for Region (via EventAgregator) and then another Resize event that each Region control will send to it's children to resize themselves to Region control boundaries. It's 2 Event classes just for Resize...
We have used both, but generally use shared services when the functionality is more than just a simple notification - we also use EventAgregator from within our services in some cases.
For example we have a service for scanning in documents :
public interface IDocumentScannerService
{
}
public class DocumentScannerService : IDocumentScannerService
{
}
This would be a pretty bad design to try and implement this with EventAggregator.
Services are triggered in the context of an application. For example one service may richly format the text in paste board and paste it on the application that requested it.
Is it possible for the service to get reference to its parent's NSUndoManager and modify its undo history?
Services are triggered in the context of an application, conceptually, but they are not actually executed in that application's process.
Undo-ability is the responsibility of the target application. If a service is pasting something into an app, it's going to end up sending a -paste: message up the responder chain of the target app's front-most window. If an "endogenous" paste operation in the target app is undoable, I would expect the "exogenous" paste operation to also be undoable. Similarly, if the app doesn't support undo for paste operations then I wouldn't expect a service-sourced paste to be undoable.
Services are isolated from the target application by the pasteboard, as described here. They will not be able to get the NSUndoManager from the application (or any other object) -- think of what a huge, gaping security hole that would be! It is probably possible to send an AppleEvent to an application from a system service, but that's about it.
For a WP7 app I have managed to get a PeriodTask running as per some examples on msdn (sends out a toast message). Now looking to extend to do what I want.
The task is running in the background and I have no need for it to communicate with the foreground app if that is running. I am just a little unsure of what I am allowed to do within this background task, and what code I can access from it.
I would like to be able to access the database that I am using (Sterling) and then update a live tile. Presumably, since its running independently then I will need to open the database - do what I need to do re the tile and then close the database within this background process. This should be okay? And from within my ScheduledAgent class OnInvoke method I can call code that is defined on a class in my foreground project as long as I include a reference to that project in my ScheduledTask project. There are no issues with that code running inside my Background Periodic Task application?
thanks.
In a BackgroundAgent you can do anything apart from use the APIs in the unsupported list: http://msdn.microsoft.com/en-us/library/hh202962(v=vs.92).aspx
The "Marketplace Test Kit" will detect use of any unsupported APIs.
In my solution I added a small Data Model project where I created a class to represent the data/model.
From the main app I store that instantiated object to the isolated storage. In the scheduletaskproject you can then just retrieve that stored instance from isolated storage if you also reference the small Model project.
If I'm not mistaken there is also a 5mb memory limit. So using a DB inside the scheduletaskproject could be a problem ( reference: http://csainty.blogspot.com/2011/08/wp75-mangobackground-agents.html )