\I have a view controller which starts a count down timer and updates a button label according to it.The problem is that when the user leaves the view and come back i do not want to restart the timer o continue from the paused time.What would be the best way to active it?
Making the timer in app delegate and post notification to the this view controller.Since the other view controllers do not need it they do not need to listen to any notification.The problem is that i have to make sure that the timer has run down to 0 to enable the button os it means when the view is loaded again i need to wait for the notification at least 1 second to make sure that he time is really up.The problem is what to show during this period on the button label.
If the view controller was a tab bar item i would be no problem but it is a pushedv view contller so it is released when the user taps on back.
Just create a singleton object for managing your timer(s). You can create it from appdelegate.
You can get remaining time from that object anytime you want (firedate - datenow). So you do not need to work with notifications. It is also not good idea to send a notification in every second, which is not used by your view, when it is not allocated. When your view is allocated / comes to screen can ask that object every second the remaining time and updates his label or some subviews etc. You can implement it easily with a NSTimer object.
You can also place a bool variable in that singleton object, which indicates, if firedate reached. Or check remaining time < 1 . So your view check the value of the variable while is allocating/showing then you can decide to activate or deactivate your button.
Related
I have a bunch of views (5) and a navigation controller the user can go through by pressing buttons that segue to the next view (each view has something the user does and sends data to the next one). My app is connected with a Firebase database, so I'm doing some stuff with that.
Anyway, the view I can't get to work is a TableViewController which works as a checklist, the user must select a certain number of cells, then clicks next and an array is sent through the prepareForSegue to the next view and this view should be display. It isn't. I have some code and some prints in the viewDidLoad that let met know that the view is supposedly loading, just not being displayed.
The screen freezes and the button just remains pressed. It doesn't crash, just stops.
My code has nothing special. It just has a performSegue in the first view and nothing really in the second one.
This is the way they're set up:
https://imgur.com/a/cyO47Pl
I've been told the problem is that there are too many push segues or something like that, could it be?
In Xcode I have a view which does a modal segue to tab bar controller, and the first view in the tab bar is a UIViewController. This view performs a task on a timed basis (every 15 seconds) using [self performSelector:#selector(blah:) withObject:nil afterDelay:15]. I have some delegate methods that take me back to the root view and calls [self dismissViewControllerAnimated] which in my mind would unload the tab bar controller which would in turn unload the view that is performing the selector every 15 seconds. While those views do disappear after I call dismissViewControllerAnimated, the selectors continue to run every 15 seconds (I see them logging messages in the Xcode console). Am I wrong in my logic that these selectors should cease since their viewcontroller has been unloaded?
Not always. It depends on your classes, if you have a strong reference to the controller or the timer somewhere it may not actually be released. It could also be that since the timer was never invalidated it's keeping the view controller from releasing. Timers are interesting in that they can cause behavior like this if not invalidated, it's always good practice to clean them up when you're done with them. If you're using recursion to call the timed method on itself every 15 seconds that could also keep the view from being released.
If you're using a timer you'll want to invalidate it when appropriate, on view disappear probably. If you want to run once after view disappear you'll need to set a bool so you know when the view disappeared so you can run it once more.
If you're using recursion, be really careful. Something like that can run on a background thread indefinitely. Again if you only want it to run while the view is the active view you can do a check to see which view is on top and only call the method recursively in that scenario, or set a bool on appear and disappear and check the bool when the method calls itself.
I am using MonoMac to build a desktop download manager for Mac in C#.
My XIB has a Table View, whose columns are bound to an NSArrayController. The array controller is connected to my Main Window Controller through an IBOutlet. The array holds a bunch of HttpDownload objects, which derive from NSObject. These HttpDownload objects contain properties such as TotalSize, TotalDownloaded, Bandwidth, etc. I have decorated these properties with an [Export] attribute.
In the controller I add some HttpDownload objects to the NSArrayController using the AddObject method. A background process, started with Task.Factory.StartNew() begins the download asynchronously and updates the bound properties such as TotalDownloaded and Bandwidth as data is received.
I can see these new values being reflected in the Table View, but only once I've "forced" a UI update, for instance by causing the window to lose focus, gain focus, or by clicking on a button within the window.
I have tried setting Continuously Updates Value in IB, but this makes no difference (and reading the docs, I didn't think it should).
Does anyone know to make the UI update the bound values in "real time", instead of only when a window event occurs?
I figured this out shortly after I posted this question.
It seems that we need to manually call WillChangeValue() and DidChangeValue() for at least one of the keys that are being updated, for instance, when I updated the total downloaded:
WillChangeValue("DownloadedBytes");
DownloadedBytes += bytesRead;
DidChangeValue("DownloadedBytes");
In my case, calling these methods for just one of the updated keys seems to be enough to force an update of all the bound values.
For reference, in Objective-C these selectors are called [self willChangeValueForKey:#"keyname"] and [self didChangeValueForKey:#"keyname"].
I have several panels that contain NSTextField controls bound to properties within the File's Owner object. If the user edits a field and then presses Tab, to move to the next field, it works as expected. However if the user doesn't press Tab and just presses the OK button, the new value is not set in the File's Owner object.
In order to workaround this I have set Updates Continuously in the binding, but this must be expensive (EDIT: or at least it's inelegant).
Is there a way to force the bind update when the OK button is pressed rather than using Updates Continuously?
You're right that you don't need to use the continuously updates value option.
If you're using bindings (which you are), then what you should be doing is calling the -commitEditing method of the NSController subclass that's managing the binding. You'd normally do this in your method that closes the sheet that you're displaying.
-commitEditing tells the controller to finish editing in the active control and commit the current edits to the bound object.
It's a good idea to call this whenever you are performing a persistence operation such as a save.
The solution to this is to 'end editing' in the action method that gets called by the OK button. As the pane is a subclass of NSWindowController, the NSWindow is easily accessible, however in your code you might have to get the NSWindow via a control you have bound to the controller; for example NSWindow *window = [_someControl window].
Below is the implementation of my okPressed action method.
In summary I believe this is a better solution to setting Updated Continuously in the bound controls.
- (IBAction)okPressed:(id)sender
{
NSWindow *window = [self window];
BOOL editingEnded = [window makeFirstResponder:window];
if (!editingEnded)
{
logwrn(#"Unable to end editing");
return;
}
if (_delegateRespondsToEditComplete)
{
[_delegate detailsEditComplete:&_mydetails];
}
}
Although this is really old, I absolutely disagree with the assumption that this question is based on.
Countinously updating the binding is absolutely not expensive. I guess you might think this updates the value continuously, understanding as "regularly based on some interval".
But this is not true. This just means it updates whenever you change the bound value. This means, when you type something in a textView, it would update as you write; this is what you'd want in this situation.
I'm a complete n00b with MacRuby and Cocoa, so keep that in mind when answering - I need lots of details and explanation. :)
I've set up a simple project that has 2 windows in it, both of which are built with Interface Builder. The first window is a simple list of accounts using a table view. It has a "+" button below the table. When I click the + button, I want to show an "Add New Account" window.
I also have an AccountsController < NSWindowController and a AddNewAccountController < NSWindowController class, set up as the delegates for these windows, with the appropriate button click methods wired up, and outlets to reference the needed windows.
When I click the "+" button in the Accounts window, I have this code fire:
#add_account.center
#add_account.display
#add_account.makeKeyAndOrderFront(nil)
#add_account.orderFrontRegardless
this works great the first time I click the + button. Everything shows up, I'm able to enter my data and have it bind to my model. however, when I close the add new account form, things start going bad.
if I set the add new account window to release on close, then the second time I click the + button, the window will still pop up but it's frozen. i can't click any buttons, enter any data, or even close the form. i assume this is because the form's code has been released, so there is no message loop processing the form... but i'm not entirely sure about this.
if i set the add new account window to not release on close, then the second time i click the + button, the window shows up fine and it is usable - but it still has all the data that i had previously entered... it's still bound to my previous Account class instance.
what am I doing wrong? what's the correct way to create a new instance of the Add New Account form, create a new Account model, bind that model to the form and show the form, when I click the + button on the Accounts form?
... this is all being done on OSX 10.6.6, 64bit, with XCode 3.2.4
The issue is that it doesn't create the window each time. Release on close is a bit of an annoying option and generally is only used if you know the window controller is also being released when the window closes. (Note I've never used MacRuby so I'll be giving code in Obj-C as I know that it is correct, hopefully you can convert it. I'll be assuming GC is on as it should be with MacRuby).
Now there are two ways to do this. I'm not entirely sure how your NIB/classes are set up as it could be one of two ways.
--
The first way to solve it is to use the outlets you use to reference the form elements to blank them out when you display the window again eg [myTextField setStringValue:#""]. If you're using cocoa bindings then it's a little trickier, but basically you have to make sure the bound object is blanked out. I would recommend against bindings though if you are new to Cocoa.
--
The second way is to make the AddNewAccountController class a subclass of NSWindowController. When you press the + button you would then create a new instance of it and display it (remember to store it in an ivar). The best way to do it would be as so:
if (!addAccountController) {
addAccountController = [[AddNewAccountController alloc] initWithWindowNibName:#"AddNewAccountController"];
[[addAccountController window] setDelegate:self];
}
[addAccountController showWindow:self];
This prevents a new instance being made if the window is already visible. You then need to implement the delegate:
- (void)windowWillClose:(NSNotification *)notification {
//If you don't create the account in the AddNewAccountController then do it here
addAccountController = nil;
}
Obviously you would need to move the window to a separate NIB called "AddNewAccountController". In this NIB make sure to set the class of the File's Owner to AddNewAccountController and then to connect the File's Owner's window outlet to the window.
When all this is set up, you will get a fresh controller/window each time. It also has the benefit of splitting up nibs and controllers into more focused units.
--
One last thing. While it is fine to do something like this in a window, you may want to eventually look at doing this via a sheet, as it would then prevent the possibility of the add account window getting hidden behind other windows.