I'm in a bit of a pickle here. I have an app written for ios7.1 and we are now trying to make the same app support ios 8.1.
In this app we have several popovers. I've gone through the fix of having them show up properly as a popover in iOS8 but when I click on the popover it doesn't respond as expected.
Here's how it is being presented (all hooked up in storyboard):
in DashboardViewController:
if ([segue.identifier isEqualToString:#"showRHSMenu"]) {
_rightNavController = segue.destinationViewController;
_rightNavController.preferredContentSize = CGSizeMake(220, (_rightNavController.tableView.rowHeight * _rightNavController.dataArray.count));
_rightNavController.modalPresentationStyle = UIModalPresentationPopover;
UIPopoverPresentationController *popoverPresentationController = _rightNavController.popoverPresentationController;
popoverPresentationController.delegate = self;
}
in _rightNavController, a protocol is declared to communicate with DashboardViewController. this works and gets executed in ios7.1 using UIPopoverController but in iOS8.1 using UIPopoverPresentationController, it does not trigger.
I have confirmed that the user clicks register in the rightNavController but the protocol/delegate is not being executed.
Can anyone help please?
An old question, but hopefully this helps someone else.
I ran into the same problem today, and the solution was to declare the popover controller as an instance variable rather than a local variable. As a local variable, it gets garbage collected any time after the method returns, regardless of whether the popover view is still on screen. (Garbage collection seems to be a lot more aggressive/efficient in iOS8, so likely just exposed a bug that you already had.) Keep a handle to the view controller until the view is dismissed, and all the delegate methods should work fine.
Related
I have moved most of the core functionality of my non-document based macOS app to a custom, embedded framework.
The app code has a standard main storyboard with an initial window, and the window has a "window content" relationship/segue into a storyboard reference pointing to a storyboard inside the embedded framework. Therein lies a custom NSViewController subclass and a custom NSView subclass.
I want to group all the input event handling code inside the framework, which means implementing mouseDown(with:) on the custom NSView subclass, and --lo and behold-- it gets called when I click inside the app window. So far, so good.
Next, I implemented keyDown(with:) to similarly handle keyboard input. However, at runtime, it does not get called and instead, I hear the annoying beep (NSBeep).
I tried implementing keyDown(with:) on the view controller instead, but it's all the same.
Finally, I tried implementing the key handler on my NSWindowController subclass instead, and that does work.
So I could get around this by forwarding the event like so:
class WindowController: NSWindowController {
override func keyDown(with event: NSEvent) {
contentViewController?.view.keyDown(with: event)
}
}
, but it is very inelegant. I would prefer to not pollute the app code with input logic.
This doesn't seem to have anything to do with embedding frameworks, however. I put together a minimal project from the 'Cocoa App' template and confirmed that indeed keyDown(with:) only gets called if implemented on the window controller code, but not on the view or view controller side.
How can I get keyDown(with:) to be called on the view or view controller (not the window or window controller) in a storyboard-based app? (so I can move it from the main app to my embedded framework).
Edit: The question has been marked as duplicate. I tried the solutions pointed in answers to the other question (namely, override acceptsFirstResponder to return true). This solves the problem in my minimal demo project, but when I tried it on my full app, it still does not work (I did see that question and did try to override acceptsFirstResponder in my app before posting this question).
I will now try to modify my minimal poeject to see if I can reporduce the issue in the main app.
Edit 2: I have refactored the minimal project to:
Send the view controller to a separate storyboard,
Send the view controller's storyboard and represented classes (custom view, custom view controller) to a separate, embedded framework.
Now the basic setup mirrors that of my app in all that seems to matter, but still can not reproduce the issue in the minimal project. I will investiate further...
Edit 3: I haven't been able to reproduce the issue on the minimal project.
On my app's custom view, I implemented:
public override var acceptsFirstResponder: Bool {
return true
}
public override func performKeyEquivalent(with event: NSEvent) -> Bool {
let retVal = super.performKeyEquivalent(with: event)
return retVal
}
On startup, acceptsFirstResponder is called twice.
When hitting any key, performKeyEquivalent(with:) is called twice, too. Inspectig the intermediate variable retVal above reveals that the super class's implementation always returns false. After returning from this method, NSBeep() is called and keyDown(with:) isn't.
If instead of super.performKeyEquivalent(with:) I force-return true, I can avert the call to NSBeep() (but keyDown(with:) is still not called...)
Edit 4 (Final):
Out of desperation, I cleared the "Custom Class" field of the window controller's Identity Inspector in my app's main storyboard (to the default NSWindowController).
Suddenly, my custom view's keyDown(with:) starts getting called.
I reinstated the custom class to confirm.
It still works.
I clean the build folder and try again.
It still works.
Now I can no longer reproduce the issue even on my main app. I really don't know what to say...
Hello everyone,
I have a question concerning an app I'm developing for Mac OS X right now that uses a simple sqlite database. My question is how should I handle the datasource component into my app ?
Is there a simple way of making one datasource available from within different view controllers other than by using delegates that send messages to the AppDelegate ?
This might seem an odd question but the fact is that I have been developping on IOS only before and you only had to pass the objectcontext to the viewController to make it available to the view controller. On MacosX, I cannot figure out how to do the same...
Any help would be much appreciated...
How to pass the context from one view controller to another:
newViewController.managedObjectContext = self.managedObjectContext;
Alternatively, you can keep the context in the app delegate and override initWithCoder which should be called when a view controller is initialised from storyboard or xib:
AppDelegate *delegate = (AppDelegate*) [[NSApplication sharedApplication] delegate];
self.managedObjectContext = delegate.managedObjectContext;
I am working on a Mac & iOS App, with iCloud CoreData in between to synchronize the data.
When I update some thing from iOS App, and the updates are already migrated to the PersistentStore in Mac App while the Mac App is running. The problem is I cannot find an effective way to force the NSArrayController to reload all data from the store.
tried -(void) fetch:(id)sender; only can see the delete or added entity, but the updated model property not refreshed...
Please help. Thanks
If you see the latest data in the managed object context, but not in the array controller, you want:
[_yourManagedObjectContext processPendingChanges];
[_yourArrayController fetchWithRequest:nil merge:YES error:&error];
[_yourArrayController rearrangeObjects];
I use this in a Mac/iOS iCloud app to update the Mac app's data when the iCloud store changes.
Following is the reply from Apple's Developer Technical support. It worked for me. Thanks all for providing solutions.
For the OS X app, when reloadFetchResults is called, you can ask the NSManagedObjectContext to reset itself and perform the fetch again.
- (void)reloadFetchedResults:(NSNotification *)note
{
NSDictionary *userInfoDict = [note userInfo];
NSManagedObjectContext *moc = self.coreDataController.mainThreadContext;
// this only works if you used NSMainQueueConcurrencyType
// otherwise use a dispatch_async back to the main thread yourself
//
[moc performBlock:^{
[self mergeiCloudChanges:userInfoDict forContext:moc];
[moc reset];
[self.tableArrayController fetch:self];
}];
}
I've found that
[self.managedObjectContext reset];
[myArrayController fetch:self];
forces my NSTableView (with NSArrayController) to re-populate and display newly processed NSManagedObjects.
in case someone else finds this...
in my case, I was building the array from user interaction (not Core Data), and then trying to show the tableView when they were done (on the same window)... and of course... seeing nothing!
[arrayController rearrangeObjects];
just before I wanted to show the tableView fixed it for me.
I'm trying to use the new Mountain Lion NSUserNotificationCenter for my application (which isn't too hard actually). Posting notifications works like a charm via
NSUserNotification *userNotification = [[NSUserNotification alloc] init];
userNotification.title = #"Some title";
userNotification.informativeText = #"Some text";
[[NSUserNotificationCenter defaultUserNotificationCenter] deliverNotification:userNotification];
However, i'd like to dismiss all notifications that are on the screen once the app gains focus. E.g. like the new Messages app does it. When new messages are received in the background, notifications are shown. When the app becomes active again, these are dismissed automatically and vanish from the screen and from the Notification Center.
To replicate this, I've registered a method to the NSApplicationDidBecomeActiveNotification notification which also gets called succesfully. In there I call [NSUserNotificationCenter defaultUserNotificationCenter] removeAllDeliveredNotifications].
This, however, has the effect that notifications that have been collected in the Notification Center are removed while the corresponding "bubbles" that are displayed in the top right corner are still displayed.
Iterating all delivered notifications and removing them each on their own has the exactly same effect, as has using scheduleNotification instead of deliverNotification.
Am I the only one experiencing this, or am I missing something to dismiss the on-screen part and the Notification Center part of a notification programatically?
The Messages app is probably using the private NSUserNotificationCenter _removeAllDisplayedNotifications or _removeDisplayedNotification: method.
You can try to use these methods to test if this is what you are looking for. Just add this category interface to declare the methods:
#interface NSUserNotificationCenter (Private)
- (void)_removeAllDisplayedNotifications;
- (void)_removeDisplayedNotification:(NSUserNotification *)notification;
#end
Unfortunately, since these are undocumented methods, you can not use them in an app distributed through the App Store. If this is indeed what you are looking for, then you should file a bug and ask for these methods to become part of the public API.
As of 10.9, the following methods remove any displayed notifications:
// Clear a delivered notification from the notification center. If the
// notification is not in the delivered list, nothing happens.
- (void)removeDeliveredNotification:(NSUserNotification *)notification;
// Clear all delivered notifications for this application from the
// notification center.
- (void)removeAllDeliveredNotifications;
The behavior seems to have changed since 10.8, as any displayed notifications are removed as well when these methods are called (thanks #0xced for clarification).
removeDeliveredNotification is removing the displayed notification for me (on 10.11), the caveat being the identifier on the notification must be set.
Hmmm……
A question about UILocalNotification and the notificaton's alertLaunchImage.
My app uses UILocalNotifiaction(s) to get users' attention. As usual, an alert is presented with "Action" and "Close" buttons. When the user taps Action, the image specified by alertLaunchImage is presented. The alertLaunchImage is a screenshot of of one of the views of the app which is shown after the data is initialized when launched normally.
Here are the 3 cases when the notification is delivered:
App is running in foreground - no alert, no launchImage is shown as designed. No problems.
If my app is running in background when the notification is delivered, the launchImage works like a charm. No problems. The launchImage with no app-related data is shown and then the app fills up the data. This part works seamlessly.
However, if the app is not running when the notification is delivered, the sequence is confusing - or I missed something. The app gets launched and shows the alertLaunchImage instead of the Default image. Then is goes thru several other screens (as part of initialization and data processing) before the actual screen (live version of alertLaunchImage) is shown.
This can get very confusing to the user. My question comes in here. How can this be avoided?
R/-
Sam.!
you can try cleaning up the alert view settings in applicationWillTerminate:
According to the UIApplicationDelegate reference applicationWillTerminate::
"This method lets your application know
that it is about to be terminated and
purged from memory entirely. You
should use this method to perform any
final clean-up tasks for your
application, such as freeing shared
resources, saving user data,
invalidating timers, and storing
enough application state to
reconstitute your application’s
interface when it is relaunched"
HTH,
Oded
If your app is launched by a local notification, you will receive that notification in the options passed to -application:didFinishLaunchingWithOptions:. Based on that, you can write code that navigates to the correct screen without animations.
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
UILocalNotification *localNotification = [launchOptions valueForKey:UIApplicationLaunchOptionsLocalNotificationKey];
if (localNotification != nil) {
// startup by local notification
} else {
// normal startup
}
}