How would you go about implementing a "dayDidChange" method?
I have a dateLabel, that needs updating, when the day changes.
I already had 2 solutions implemented. But gave up on them.
1st, on viewWillAppear, I would set my label. Chances for date changing when the user is viewing the VC are VERY small ... and it wouldn't really introduce any "errors" to execution But still, it's not perfect.
2nd, I also implemented an NSTimer with intervals of 1 second. Works great. But I'm not too found of the idea of having a method being called if there is a chance that I don't need to do it.
Are there any other options? I need to update that label, when the day changes. Also, is it possible to use NSNotificationCenter with this?
In your appliciation delegate, implement the following method: -(void)applicationSignificantTimeChange:(UIApplication *)application
This method is called when the day changes, or if the device's time has been changed in the background for whatever reason (such as changes to time zone).
hope it helps. happy coding :)
You can calculate the time left on the day and set a timer to it. You can also listen to UIApplicationSignificantTimeChangeNotification. Note that this notification will be fired not only when the date changes, but for timezone adjustments and other changes. Keep in mind also that the firing of the notification will be triggered only if your app is not in an inactive state.
There are many ways to do so, and I can elaborate more on them if needed.
But here is a nice quick trick
use this code in your app delegate
it will listen to time changes (when the date or time changes dramatically) and when that happens - run a test and update the label if needed.
read me about this here: https://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIApplication_Class/Reference/Reference.html
It's just a quick simple way of doing it without timers.
- (void)applicationSignificantTimeChange:(UIApplication *)application {
NSLog(#"Time has changed, do a test and update the label if needed");
// [yourViewController runTimeTestAndUpdateFunction];
}
Related
In many of my UIViewControllers, I update certain controls based on the state of my data. For example, I might have an edit button on a UITableViewController that should only be enabled when there is one or more items. Or perhaps I want to limit the number of items that can be added, and disable the 'add' button otherwise.
Every time I add or delete an item (or take any other action that can add/remove items), I have to remember to update any controls that might need enabling/disabling. This is trivial for the most part, but doesn't feel comfortable - there is a lot of repetition, and I have to remember to add the calls to updateControlEnabled (or whatever) whenever I add new functionality that might affect the data.
And then I noticed NSManagedObjectContextObjectsDidChangeNotification. Reading the docs, it looks like I can receive a notification whenever something changes in my managed object context. This seems ideal, but I have a few questions:
Is this an appropriate use of
NSManagedObjectContextObjectsDidChangeNotification?
Should I anticipate any performance impact if a controller
subscribes to these and parses each one to see if it needs to update
the UI? I will be checking the userInfo for every change, instead of
only those that I know I will care about.
Where should I subscribe to the notifications? My UIViewController has a
reference to the context, which helps, but I don't know where to
subscribe (loadView? viewDidLoad? init?) such that the view
controller will always have one and only one subscription.
The view controller will continue to receive and process notifications
when it's offscreen - enabling and disabling controls as the
data model is affected from elsewhere. Is this ok?
I guess I'm mostly just wondering if anyone else uses this approach and if so, what their experience is.
Q) Is this an appropriate use of NSManagedObjectContextObjectsDidChangeNotification?
A) Yes - I used it on OSX for a similar purpose.
Q) Should I anticipate any performance impact if a controller subscribes to these and parses each one to see if it needs to update the UI? I will be checking the userInfo for every change, instead of only those that I know I will care about.
A) NO - it will normally be a very small set of objects - ones that were directly changed.
Q) Where should I subscribe to the notifications? My UIViewController has a reference to the context, which helps, but I don't know where to subscribe (loadView? viewDidLoad? init?) such that the view controller will always have one and only one subscription.
A) Well, you cannot affect the UI til the view shows - so probably viewDidLoad or viewWillAppear. The problem with the later is you may get it a few times depending on push/pops, so maybe I'd do it in viewDidLoad.
Q) The view controller will continue to receive and process notifications when it's offscreen - enabling and disabling controls as the data model is affected from elsewhere. Is this ok?
A) Sure - when the view reappears all the elements will be setup correctly.
What you want to do is a classical use of that notification. Just check the thread it comes in on - if its not the mainThread then you want to make all your changes in a block posted to the mainThread.
I have a situation where my UIPickerView is getting "starved" by a computation task; in other words, the UIPickerView is never updated -- and hence, never sends messages -- because a very heavy compute task is happening. The picker controls aspects of the computation, so the two have to play nice.
I thought of running the computation in a separate thread. Seems like that would leave the picker free to update. However, it'd be a massive undertaking to make my computation multithread-able, so I'd like to find another solution.
Is it possible for a picker (or other UI controls) to "preempt" the execution of a block of code? The computation is in a loop; the number of iterations is what makes it heavy. If the picker could even set a flag somewhere, the loop could break itself, which would work with the flow of the program.
If the loop could poll the picker, that would also work. But, I haven't found a way to do that.
Ideas?
(ps. I posted a similar question yesterday, but didn't really ask it correctly -- didn't quite know what the problem was at that time!)
I assume you mean by flag that if the picker is moved, set a flag. If so you can do this - look at the picker delegates, and when any or all of them get called, set a flag. If your computation is done by another class or classes, then create a new property on those classes "cancelled", the picker can set it, and when set the computation ends.
Before you start another computation you would clear that cancel flag, then kick off the computation.
You can also put a simple toolbar above the picker (common practice) where you have controls that could start the computation, show progress, and cancel it.
EDIT: if the issue is the picker is stuttering when the user is trying to manipulate it, then subclass UIPicker, intercept touch events, and while the picker is being touched, cancel all computations. The only complication is that if the user "spins" the picker, you'd want to wait til it settles, but you would not know how long to wait. Depending on the last touch message, you would have to use a heuristic to wait for didSelectRow: or a timeout before restarting the computation.
For the sake of learning i'm making a timer. Used an NSTimer but it appears this stops
when going to the background.
Thought of using NSDate instead. Does this work in the background?
Do i compare current time to a set time to get the timer running properly?
Some thoughts would be greatly appreciated!
If you are looking for something to handle time based events in the background, have a look at UILocalNotification. With a local notification, the OS will alert the user at the appointed time whether the app that scheduled the notification is running or not.
If you are looking for something to happen when the app starts, you can use NSUserDefaults and store a value containing the current timestamp. Fire this off when in the AppDelegate inside applicationWillResignActive method. You can then check this value in the applicationDidBecomeActive.
I have a simple query but don't know how to do it.
This is what I am trying to achieve:
1) I have a UILabel with todays date i.e. "29/04/12"
2) At midnight I want that label to update by itself to "30/04/12" without needing to change view or press anything.
It's step 2 that I don't know how to do. I have idea's of how it would be done such as potentially getting a system notification of the date change (if this is even possible) or using some sort of timer as a trigger.
Any help would be greatly appreciated, thanks in advance.
If you are only interested in being notified when midnight arrives (or a couple other cases), then you can override UIApplicationDelegate's - (void)applicationSignificantTimeChange:(UIApplication *)application method so that it causes your labels to update. Of course, you'll also want to update the labels whenever the application re-enters the foreground, since this method won't be called if your app is in the background when the date changes.
I'm having some fun with objective c. As a simple program I wanted to write a clock application.
Basically, a UITextField needs to show the current time and update every second.
My initial thought was to use delegation and let UITextField call back a class when the 'Value Changed' event occurs. By 'bootstrapping' an initial value change (e.g. by setting the time at application startup) I thought I could trigger the 'Value Changed' event continuously afterwards (the UITextField would continuously change itself, hence triggering the delegate method). I tried many things, but this never worked. I even tried creating a button that would set UITextField to an arbitrary text value (as opposed to setting UITextField at startup) in the hope that the delegated method would be called, but this did not either. To prove that my code was correct, the time was updated when I'd use other actions like 'Touch Down' for example: I would get the time on every click in the UITextField.
I eventually found out that i could use a callback every second by using [self performSelector ...] and that worked.
Is there a fundamental reason my delegation using the 'Value Changed' action never worked ?
The value changed event only fires in response to a user event-- that is, you setting your textField.text = "something" doesn't fire it, by design.
And it's a good job it doesn't, because by the sounds of it you were trying to get your application into an infinite loop. If the 'value changed' event did actually fire when you set the text in the box, the program would ask the delegate again, which would set the text again, which would ask the delegate again..... you get the picture. This is called an infinite loop, and it has the effect of causing the program to hang, and then crash, since there's no way for the program execution to exit this loop.
Anyway, in order to do what you're saying, you've got two options
you can set up an NSTimer object to call your time update method every second. It's quite easy, check out the documentation.
performSelector:withObject:afterDelay:. It sounds like you might have already got the hang of this one. It's not as neat as using an NSTimer, but it will do the job.