NSNotifications & background apps?
NSNotifications & background apps?
- Subject: NSNotifications & background apps?
- From: dream cat7 <email@hidden>
- Date: Sat, 14 Jun 2008 20:52:05 +0100
Hi,
Seeing notifications from outside:
==========================
There was a great logging tool called "Meow" for the nsnotifications
but i cannot seem to find that anymore. I had hoped to write a D-Trace
probe to give a similar output as "Meow" but support for cocoa objects
like NSString. In instruments it is not showing the obj-c data passed
in the function parameters, only the names of the obj-c function which
appears on the stack. I wish i had kept a copy of Meow tool. Sometimes
it is useful to see the nsnotification communications separately from
xcode. Sometimes 2 process are communicating And one of them is
launching / closing multiple times during the session (e.g. sending
kill message as NSNotification).
Wish to Improve usage of notifications:
==============================
Like many others, i have a split implementation consisting of a UI-app
and a helper application which runs in the background. Currently the
way i have it at the moment is a shared preferences file and whenever
one of them writes to it an NSNotification is also sent out to tell
the other one to re-read the plist.
This is clearly far from ideal, but i just didnt want to send
everything across in NSNotificatiion messages because then they can
easily been seen by anyone else. For example what if i had a lisence
key and wanted to send across to the daemon process to enable the
app ? On the other hand it also seems a waste to have to re-read
everything just because the user flicked one option in a checkbox.
Indeed I am not shifting around any large volumes of data at the
moment, it is maybe 10 or so application preferences settings, with a
2-3 of data objects which are archived with NSCoding/NSArchiver
protocol. However as my application becomes more enhanced, there may
be significantly more such "medium size" data object.
So i am thinking maybe a better scheme would be to send only the
changed object(s) tagged in the userinfo field of the NSNotification.
And say call it "ApplicationDataChanged". This might be represented as
an NSDistionary containing 1 item whose key was the keyPath of the
object changed. (this is assuming that bore apps are sharing the same
variable names internally for those data. A really sophisticated
version would also want to cache the changed data before writing it to
disk. Maybe that is something already supported by core data but i
didnt want to write my data model as a core data app because it will
tie my data model code heavily into the Mac OSX Desktop platform ?
I was also wondering if anyone ever think to encrypt their
NSNotification data? At some point I may wish to write in a lisence
key activation system to my app. Then i would need to send to the
helper-app a copy of the user's liscence key (to remove activation
lock). Clearly if said key was non-revokable type then I would not
want it to be easily seen outside of my application's code.
Notifications to daemon process:
=========================
I am also considering converting my background Cocoa app (which is
hidden user a login item), into an installable launchd daemon. And yes
- i have already seen the ADC article about daemons and background
processes.
Reading previously archives I also understand that some developers
have used a lower-level communications with sockets or Mach Ports. So
these might be worth investigating also. But I am not interested in
writing lots and lots of code if NSnotifications are already a
reasonable solution. But a launchd daemon that cannot use
nsnotificationCentre in the same way as a regular Cocoa app when the
windowserver isnt loaded yet. I think somebody said that a daemon can
before user login do some registering for the NSNotification centre
with the CFNotification but only after the loginscreen is up? (And
possible because NSDistributedNotificationCentre is in foundation but
not appkit?)
A daemon might be loaded running in the background from boot time. I
would not need the daemon to be listening for or sending notifications
until after the loginwindow and the user has logged themselves in to
the machine. Then at that point it will need to be connected to the
notification centre so that it can communicate with the UI-app,
allowing the user to change settings, etc...
With a launchd - administered process they can be started at any
time. But is it reasonable to believe that the daemon can start
running before the NSNotification centre and then some time after it
started that it can register with the notification centre when it
becomes available ?
i am hoping that if i were to call [NSDistributedNotificationCentre
defaultCenter] when it is not running then Foundation.framework would
just return nil value ? (rather than just crash or return an invalid
memory).
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden