I have checked the restorable option on my NSWindow
When I move my application and change its size and close/reopen my application it sets the window size and position to the last size and position
but this doesn't happen on every computer where i test it. it only happens to a few computers
they don't have special settings regarding the resume.
Does anybody have any experience with this?
But this doesn't happen on every computer where I test it. It only
happens to a few computers. They don't have special settings regarding
the resume.
Actually, they do. Take a look into the System Preferences > General pane. There should be an option named “Close windows when quitting an application” which is responsible for the restoration behavior. Additionally, in OS X Mountain Lion, Apple changed default behavior and now the app restores its state only when you quit using Command-Option-Q.
So, you probably should check which OS X version is installed on another Mac, and which preference is selected in the General pane. Hope this helps!
One thing you should know is that checking the "Restorable" option in IB only changes a window property. The actual restoring and saving is in your hands.
First, you have to conform to the NSWindowDelegate protocol and implement the
-window:willEncodeRestorableState:state and -window:didDecodeRestorableState:
methods that encode and decode your window properties (For example your windows frame, which you obviously get by calling [myWindow frame]).
You also need to conform to the NSWindowRestoration protocol and implement +restoreWindowWithIdentifier:state:completionHandler:. (make sure you set your class to restoration class, with the setRestorationClass method)
For additional, more in depth, information, you can visit this Apple Documentation document here.
If all you want is to restore the window's frame use setFrameAutosaveName:.
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/WinPanel/Tasks/SavingWindowPosition.html
Related
Context:
OS X Application implemented in Cocoa/ObjC
Xcode 6.1
Base SDK: 10.0
Deployment Target: 10.8+
Question:
In my app, I have a custom NSView subclass which implements NSDraggingSource. I'm using the new NSDraggingSession-based API (not the old deprecated one).
I have my dragging source fully implemented, no problems.
I am already implementing:
-[NSDraggingSource draggingSession:movedToPoint:]
I would like to additionally do some hit detection within this method and depending on the results of that hit test, possibly cancel the current drag session programmatically.
So: What is the best way to cancel/terminate the current NSDraggingSession programmatically? (preferably from -[NSDraggingSource draggingSession:movedToPoint:])
It might be nice to also be able to specify the NSDragOperation upon termination too.
Notes:
I've tried calling -[NSResponder cancelOperation:] on my custom view, thinking this might have something to do with dragging sessions, but that doesn't work. I get an exception with unrecognized selector.
I DO NOT need help doing hit detection.
I DO NOT need help implementing NSDraggingSource in general.
My app is using a 2nd UIWindow to show a special screen if iOS wants to take a screenshot of the app.
By accident I used [UIWindow makeKeyWindow:] on my main window if I wanted to remove the 2nd window again. This really should be makeKeyAndVisible: instead but I'm wondering why it worked at all.
I mean: most of the time (99%), my 2nd window was removed as expected and my main window became visible.
I'm asking because I'm wondering if I have really found the problem or if there might still be something else?
Or could it be that the method was incorrectly bound in (previous) MonoTouch versions?
Each method maps to the selector of the same name makeKeyAndVisible and makeKeyWindow.
Or could it be that the method was incorrectly bound in (previous) MonoTouch versions?
GIT history shows (me ;-) that both never changed since they were first added (more than two years ago).
Documentation about the former states:
You can also hide and reveal a window using the inherited hidden property of UIView.
Maybe this happens in your code (or even within the iOS code).
I'm working on implementing Resume in my formerly Snow Leopard app. For my app's main window, I checked the Restorable checkbox in Interface Builder, and everything's working fine. Its delegate has -window:willEncodeRestorableState:state and -window:didDecodeRestorableState: called on it, just fine. Everything works.
I have another window that is also going to sometimes be open when the user quits. I checked Restorable for it, and implemented the two methods above. ..willEncode.. gets called when I quit with the window open, but ..didDecode.. never gets called, and the window doesn't get restored. I've read through the documentation and it seemed like I may want to create a restoration class, but the docs weren't particularly clear on how to do so.
I tried implementing the <NSWindowRestoration> protocol in my AppDelegate, and in my second restorable window's delegate, but the +restoreWindowWithIdentifier:state:completionHandler: method never got called for either of them.
What am I missing? Am I on the right track with NSWindowRestoration but not doing it right? The way the docs talked about the restoration class, it sounded like there would only be one. Do I need to specify it in the app's plist or something?
What the above linked Resume documentation neglects to mention is NSWindow's -restorationClass property. If you set this property in code (to a class that implements <NSWindowRestoration>, then that class is responsible for creating the window.
I have a general question for Xcode programming and the usage of the Xcode tools.
I am quite new (4 months) in iOS development and I almost never used the Interface Builder for my purposes. I always created instances programatically. My question is basically if you think i should get used to work with IB or should/can i proceed like i do now?
If you are fine with defining your UI programmatically, then I do not see any issues with that.
Interface Builder allows you to "graphically" define your interface, and this can be an invaluable tool for playing with your UI prototypes, but apart from that there is nothing that you can do in IB that you cannot do programmatically.
In my case, I see that it depends on the kind of UI that I design. When I need a pretty basic UI, the IB is unbeatable for me. On the other hand, when my UI tries to be a bit custom, then I prefer doing everything programmatically.
An interesting point is that you could use IB to design your UI, deciding on sizes and positions of your elements, and the create it programmatically.
Yes you should use IB, basically xcode having IB for ease of development, no need to setting controlls by using coordinates and each time see their visibility by running the app.
just drag and drop and at the time of making the views, you can see hows your screen going to look.
Also using IB is not a typical task so,start development using IB.
My App is a view-based application. At the beginning I show my logo and after a delay of a few seconds it changes into another view. from then on the user can switch to a lot of different views.
Sooooo.. My Problem: The thing is, when I restart my App. [..well closing and reopen by touching the icon..] the app itself doesnt restart in the sence of jumping to the very first view. to the contrary: at restart the user just returns to the last view that was open.
So I dont know why this is.
Is it normal to somehow manually tell the app to return to the very first view after restart? And if so, how do I have to do that?
PS.
I have so no idea what to do.. Maybe my problem has to do with the timer i used in the first view to change after a delay of time?
Please, is there anyone, who can help me?
Your problem is that, as of iPhone 4, returning to the home screen does not terminate your app. It's just made inactive, so opening it again reactivates it. In most cases, this is a good thing. If it doesn't work for your app, you can add the UIApplicationExitsOnSuspend key to your Info.plist with a value of YES.
(As I said, you should only do this if it really helps usability. If it's just about getting your splash screen shown again, most users and possibly Apple will frown upon it.)
iOS 4.0 and greater have a fast-start thing that allows apps to restart back from where they were upon restarting. There are several ways to deal with this:
1.) your App Delegate receives info about being but into the background and resumed. - (void)applicationDidBecomeActive:(UIApplication *)application and - (void)applicationDidEnterBackground:(UIApplication *)application are the relevant functions here. Check the docs.
2.) You can also disable the background, inactive state completely by including UIApplicationExitsOnSuspend in you Info.plist as Chuck already pointed out.
Overall, you should check the application state docs on Apple's Side.