Beginner programmer here, I'm using the Fabric TwitterKit in an XCode project (Objective C) to show some tweets, and I want to log when users interact with those tweets. I see from the documentation that TWTRNotificationConstants.h has some juicy stuff in it, and when I look at that file it includes a comment that "These are posted on the default notification center." I also see lots of potentially useful constants, but unfortunately I don't quite understand how to use the default notification center, nor how to use these constants to run certain code when, for example, a tweet is liked. What is the best way to run some code when a tweet is liked?
I finally figure this out and will answer my own question. TWTRNotificationConstants.h posts notification to the NSNotificationCenter. When you look in TWTRNotificationConstants.h it tells you the name of each notification. You can then set up an observer. For example, the observer below now lives in my FirstViewController.m file:
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(likeTweetNotification:) name:#"TWTRDidLikeTweetNotification" object:nil];
You then need to create a method with your selector name to do something when the notification is received. In this example, it might look like this:
- (void)likeTweetNotification:(NSNotification *) notification {
// do something
}
Also note that the notification carries some extra information in the userinfo dictionary that can be a part of NSNotifications. It seems to be the tweet's #username and text. You could access that dictionary by adding some lines to the above method like so:
- (void)likeTweetNotification:(NSNotification *) notification {
NSDictionary *tweetInfoDict = [notification userInfo];
NSLog(#"Dictionary: %#", [tweetInfoDict description]);
}
Related
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
How to know when the device is charging?
I am kind of a noob at Xcode so sorry if I make I fool out of my self. I am trying to make an app and one of the functions is to check if the iphone/ipod/ipad is charging or not. If not charging I want it to play a sound perhaps and flash LEDs. Also if it is charging, I want to make it display text such as "Device Charging :) " . By the way I am using the method with the FlipsideViewController, but these features will be in the MainView. I have looked at various examples and have seen the one below as well as many test applications, but I don't know how to use it. Thank you in advance!!
Code:
[[UIDevice currentDevice] setBatteryMonitoringEnabled:YES];
if ([[UIDevice currentDevice] batteryState] != UIDeviceBatteryStateUnplugged) {
//Device is connected (charging or fully charged)
}
It sounds like you might want to start with some tutorials on writing iPhone apps because the code above looks ok (though I haven't tried this specifically). If you don't understand how to do some of the things I describe below (or some of the terms are unfamiliar), I'd recommend getting a good book or checking out some tutorials:
Book: iOS 6 SDK Development (Amazon)
Tutorials: Ray Wenderlich has many good tutorials on his site
Apple Documentation is quite good
There's no point in just writing the code for you because you presumably want to learn how to program and you won't learn much if someone just does it for you.
Here are some pointers on how to think about this, though the behavior you desire isn't completely obvious from what you've said.
If I understand you you want two different actions to happen when the main view is displayed.
To start with, why not get it to set the text string in a field to match the state of charging / not charging?
So you'd add a UILabel to the main view .xib file in Xcode and add an outlet to it in the view controller so that you can set it's text at runtime.
Then you'll want to call the first line above somewhere once to start monitoring (parameter is: YES) and again with NO to stop monitoring once the view goes away. If you look at the documentation for UIViewController at developer.apple.com near the top you'll see a list of methods that UIViewController implements. In this case you probably want to override (create your own version of) viewWillAppear and viewWillDisappear and put the setBatteryMonitoringEnabled call with YES and NO into these two methods respectively.
So that takes care of enabling / disabling battery status monitoring. Now you need to test the state and take action (this is call to batteryState in your code above).
One question about design which isn't obvious from your description is if you want to do this once when the view appears or if you want it to continually monitor the state.
If you want to do it once, you could put the call to the above in viewDidAppear, say, and then use the outlet to the UILabel to set the message in the label to "Charging" or "Not Charging" based on the result from the batteryState method.
If you want something that watches for changes in the state of charging then you need to subscribe to the notification and put your code to change the UILabel (or whatever you finally do in response to a change) in the handler for that notification.
You figure this out by reading the documentation for UIDevice at developer.apple.com or in Xcode's Organizer window's Documentation section. If you read the documentation for the UIDevice method batteryMonitoringEnabled you can see that the "See Also" section includes two entries for the notifications you can subscribe to to find out when the Level or the State changes: UIDeviceBatteryLevelDidChangeNotification and UIDeviceBatteryStateDidChangeNotification. To learn how to subscribe to notifications you'll want to look at NSNotificationCenter documentation.
Then once you get this working you can add your fancier alerts (be careful about putting them up repeatedly!) and sounds (though playing a sound when the battery isn't charging will use battery which is somewhat questionable.. just make sure not to do it repeatedly perhaps).
good luck!
Add this to the appDelegate.m
- (void)applicationDidBecomeActive:(UIApplication *)application{
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(batteryStateDidChange:) name:UIDeviceBatteryStateDidChangeNotification object:nil];
[[UIDevice currentDevice] setBatteryMonitoringEnabled:YES];
}
- (void)applicationWillResignActive:(UIApplication *)application {
[[UIDevice currentDevice] setBatteryMonitoringEnabled:NO];
}
- (void)batteryStateDidChange(NSNotification*)notif {
// check the status here.
// See if it is charging, or not and respond to the change.
}
(edited to make code more explicit)
I am trying to use ScriptingBridge to write a small iTunes controller. The problem is to find an efficient way of getting notifyed whenever any changes occur. My first approch was to poll the input in a loop and just keep checking for differences. But I think there must be a more efficient way of getting notifyed about input!
Thanks in advance!
iTunes sends out a notification when something changes so just register for it in your init method of AppDelegate. Here's an example...
[[NSDistributedNotificationCenter defaultCenter] addObserver:self selector:#selector(receivediTunesNotification:) name:#"com.apple.iTunes.playerInfo" object:nil];
The actual notifcation object in your method "receivediTunesNotification:" will contain information about the changes.
OK, so Apple brought ARC to us, which is great. After refactoring my Application to ARC almost everything works fine and it is a lot easier now to develop and maintain.
There is just one problem I still can't figure out.
My job management program shows different detail information of proposals, orders and so on in their own windows. So I have a special class where WindowControllers gets allocated and initiated with initWithWindowNibName and then the window is shown with showWindow:
DetailWindowController *proposalWindowController = [[DetailWindowController alloc] initWithWindowNibName:#"ThePorposalWindow"];
[proposalWindowController showWindow:nil];
Before ARC the Instance of the WindowController did the release like shown in the documentation:
- (void)windowWillClose:(NSNotification *)notification
{
[self autorelease];
}
But now with ARC this is not possible anymore and what makes it even worse, in my special class where the WindowController is allocated and initiated, the same windowController is released by ARC because there is no pointer to the windowController.
My idea was to copy the windowController into an mutuable array:
[proposalWindowArray addObject:proposalWindowController];
[[proposalWindowArray lastObject] showWindow:nil];
And in the windowControllers delegate method windowWillClose I post a notification to my special class:
- (void)windowWillClose:(NSNotification *)notification
{
[[NSNotificationCenter defaultCenter] postNotificationName:#"ProposalWindowWillClose" object:[[self window] windowController] userInfo:nil];
}
In my special class I listen to the notification and remove the object from the array:
- (void) proposalWindowWasClosed: (NSNotification *) notification
{
[proposalWindowArray removeObjectIdenticalTo:[notification object]];
}
It works, but I still do not believe that this is the correct way.
Does anybody has the same problem or a tip to make it better?
I'd probably use a delegate approach rather than notifications. Generally it is better to have an external object that keeps track of the open windows. Self-retaining objects, like your old system, break the basic points of object ownership and make it hard to find things (such as "give me a list of open windows"). Non-Singletons that are just "floating" out there often come back to bite you in your architecture (I've had to fix this often enough).
That said, sometimes self-ownership is at least convenient, and at worst not-the-end-of-the-world. So self-own. The only difference is that you need to do it explicitly rather than matching a leak and an over-release (which is what your old code was doing).
Create a private strong property. Assign self to it. That will create a retain loop that will keep you around until you set the property to nil.
I think your alternative approach should be correct, but I don't think you need the second notification. You should be able to do:
- (void)windowWillClose:(NSNotification *)notification
{
[proposalWindowArray removeObjectIdenticalTo:self];
}
Assuming the "proposalWindowArray" is a static NSMutableArray.
Without hacks, there is no elegant way to keep an object retained other than having a strong reference to it in some other object. For example, you could keep a static NSMutableArray/NSMutableSet, add your controller there, and remove it in windowsWillClose:. This will be shorter than posting a notification. To make this reusable, create a WindowControllerRegistry singleton with an array, where you add controllers like this one, and which will automatically listen to NSWindowWillCloseNotification and remove them from its array thus releasing ownership.
As a quick workaround, you could perform retain/autorelease calls from non-ARC file:
my_retain(self);
my_autorelease(self);
// ArcDisabled.mm
void my_retain(id obj) { [obj retain]; }
void my_autorelease(id obj) { [obj autorelease]; }
I had this same issue when I switched to ARC. Your solution works, but you're making it too complicated. You can essentially do what you were doing before by having the window release itself when it closes, but in an ARC compatible manner.
The solution is to simply create a property of your class within the class itself. For your example, in DetailWindowController, you would add the following property:
#property (strong) DetailWindowController *theWindowController;
Then when you create the window with your code above, add one line like so:
DetailWindowController *proposalWindowController = [[DetailWindowController alloc] initWithWindowNibName:#"ThePorposalWindow"];
[preferenceController setTheWindowController:proposalWindowController];
[proposalWindowController showWindow:nil];
Then finally, to have ARC release the window when it is closed like you did with the autorelease pre-ARC, in the DetailWindowController class, simply do:
- (void)windowWillClose:(NSNotification *)notification
{
// Let ARC tear this down and clean it up
[self setTheWindowController:nil];
}
I have an ImageView which shows a lock, informing if an opened file is locked or not. I have 2 images for locked and unlocked cases. I want synchronize the displayed image with boolean value of my object representing an opened file.
To do this I want my ViewController to change the image in my ImageView depending on lock state of object. So both object and ViewController have a property "isLocked".
How can I synchronize them? It is easy in IB but I don't know how to do it programmatically. I tried in initialize method of my ViewController to use:
[ViewController bind:#"value" toObject:[ArrayController selection] withKeyPath:#"isLocked" options:nil];
But it doesn't work. In documentation it is said that I have to expose my binding before using it.
I try to put the following code in initializer method of my object:
[self exposeBinding:#"isLocked"];
But Xcode doesn't recognize this method.
Does somebody have experience with this kind of bindings establishing?
As #nick says, you want Key-Value-Observing.
[arrayController addObserver:self
forKeyPath:#"selection.isLocked"
options:NSKeyValueObservingOptionNew
context:#"this_context"]
Then when isLocked changes the -observeValueForKeyPath:ofObject:change:context: method that you have added to your viewController will be called (as long as you only manipulate isLocked in a KVC compliant way).
The options parameter lets you optionally tweak exactly what conditions will trigger the notification and what data is sent along with the notification. The context parameter is there to help you distinguish between notifications that you registered to receive and notifications your superclass registered to receive. It is optional.
Bindings seem like they might be useful to keep two values in sync. However, this is not what they do at all.
Yes, lots of things seem to give the impression that this is what they do, and there isn't much saying that this isn't what they do, also lots of people believe that this is what they do - but no, you cannot use them for this.
Only a handful of classes support bindings (they are listed here) and then, and this is the important bit, those classes only support binding their named bindings, and these bindings are not instance variables. eg NSTextField has a 'fontFamilyName' binding yet NSTextField does not have a 'fontFamilyName' property or instance variable, even a derived one. NSTextField does have a 'isBordered' property but not a binding - so you cannot bind 'isBordered'.
It does not mean anything to 'bind' an arbitrary property of an arbitrary Class.
Yes, you can bind two arbitrary values, the following code works just fine:
#import <Cocoa/Cocoa.h>
#interface SomeObject : NSObject
#property (retain,nonatomic) id someValue;
#end
#implementation SomeObject
#end
int main()
{
SomeObject *source=[SomeObject new];
SomeObject *target=[SomeObject new];
[target bind:#"someValue" toObject:source withKeyPath:#"someValue" options:0];
[source bind:#"someValue" toObject:target withKeyPath:#"someValue" options:0];
[source setSomeValue:#(42)];
NSLog(#"target: %#",[target someValue]);
[target setSomeValue:#(22)];
NSLog(#"source: %#",[source someValue]);
return 0;
}
As far as I can tell, the problem is the bit [ArrayController selection]. The first problem is that ArrayController is (or should be) a class, and getting the class's selection is probably pointless. The other problem is that even if this were an instance, you would be binding to the selection at the time of the call, which is almost certainly not what you want. You want to track the current selection as it changes.
So what you want is probably something like the following:
[myViewController bind:#"value" toObject:myArrayController withKeyPath:#"selection.isLocked" options:nil];
I am trying to update another windows when the one becomes visible. So I found the NSWindowDidExposeNotification and tried to work with it, so I wrote in my awakeFromNib:
// MyClass.m
- (void)awakeFromNib {
NSNotificationCenter *nc = [NSNotificationCenter defaultCenter];
[nc addObserver:self
selector:#selector(mentionsWindowDidExpose:)
name:NSWindowDidExposeNotification
object:nil];
}
and implemented the method
// MyClass.h
- (void)mentionsWindowDidExpose:(id)sender;
// MyClass.m
- (void)mentionsWindowDidExpose:(id)sender {
NSLog(#"test");
}
But it never gets called which is odd. What do I do wrong here?
Generally speaking, you would set up your controller as the window's delegate in order to receive these notifications, like so:
// MyClass.m
- (void)awakeFromNib {
// note: this step can also be done in IB by dragging a connection
// from the window's "delegate" property to your `MyClass` object
[window setDelegate:self];
}
- (void)windowDidExpose:(NSNotification *)notification {
NSLog(#"test");
}
Although, after reading here and here, windowDidExpose may not be your best bet. I would recommend trying the windowDidBecomeKey delegate method instead. That one is posted whenever your window gains "focus" (starts responding to user input) which may be the right time to show your second window.
Update: (in response to comments)
Apple's documentation (quoted below) indicates that NSWindowDidExposeNotification is only valid for nonretained windows, which, according to the posts that I linked above, are quite uncommon.
NSWindowDidExposeNotification
Posted whenever a portion of a nonretained NSWindow object is exposed, whether by being ordered in front of other windows or by other windows being removed from in front of it.
The notification object is the NSWindow object that has been exposed. The userInfo dictionary contains ... the rectangle that has been exposed.
On a higher level, NSNotification objects are simply packages of data that get passed around between Cocoa classes and NSNotificationCenter objects. NSNotificationCenter objects are controllers that manage these packages of data and send them out to observers as required. There is usually no need to trap notifications directly. You can simply use KVC/KVO or pre-defined delegates in your classes and Cocoa handles all of the dirty details behind the scenes.
See Notification Programming Topics and Key Value Coding Programming Guide if you want to know more.