Background:
I currently have a NSTimer running in my AppDel class (I also have a method to calculate the amount of time my app spends in the background and adds it to the total, in case anyone brings this up).
The timer is checked at different intervals to see if it has reached 12 hours, at 12 hours the app needs to refresh its data from the server.
When this occurs, I need to display a UIAlert which when its button is pressed:
• Pops off view controllers to the first view controller.
This “refresh” should only be able to occur on 3 (specific)view controllers out of 7 within my app.
The Question(s):
Is NSNotifcationCenter sufficient for my requirements?
Where I would add an observer only to the view controllers I want this to occur on?
Is there a better approach I should be taking?
ya you can implement the NSNotifcationCenter approach but best alternative is to use custom delegate approach .By this way your app will work according to apple guidelines and memory utilisation of app is also less.
Using NSNotificationCenter is a good approach when you need to send information about some event (for example need of refreshing app) and you want to make as few changes as possible, without redesign all app architecture. I recommend you https://github.com/AllinMobile/AIMObservers because is created to facilitate the work with NSNotificationCenter and NSNotification.
Related
Lately I have been playing around with the bluetooth framework and grew a strong enough knowledge to start building an application. The only problem is that all the examples I found and all the practice I have made consist in putting the core bluetooth core code inside the same file as the UIView with which the user is interacting.
I would like my future application to have multiple views in which the BLE scan occurs on the background. I initially thought about creating an object with a name similar to bleDeviceFinder and pass this object through each view. However, after thinking about it I realised that if I want something to happen in the current view I need the function didDiscoverPeripheral to have direct access to the UIView objects which it is supposed to affect.
I know it is probably a stupid question, what would be the best way to do so? I was thinking maybe to set and alert and subscribe every view to that alert; is this a good solution?
A quasi singleton BTLEManager that you pass around in the app. It sends NSNotifications for events like discovery, and your ViewControllers observe these notifications. The truth (i.e. list of discovered devices) stays in BTLEManager. Once a viewController has received such a notification it asks the BTLEManager for the list of current devices and then the viewController changes your views accordingly. The Views should never talk to the BTLEManager directly.
That's how I would do it.
I used to disable current view while a method is running in the background(may be an API Call) asynchrnolsly.But as per the Human Interface Guidline I understood that disabling the View while a method runs in the BG, is not a right way.So If I need to avoid user accessing different IBActions while some thing performs in the back ground what is the best method?
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 recently started to learn Obj-C, and I try to write my first "bigger" app.
I want to have application that's structured similarly to Facebook, as in:
First thing user sees is login/register screen,
if he's logged in correctly, he sees main app screen, which can do many not-so-directly-related things.
I don't know how to structure that app TheRightWay.
First thing that comes to mind is setting subclassed UINavigationController as initial view controller, with one segue to 'log in' flow, and second to 'logged in' flow.
But that creates different problem: since (at least from my understanding), I shouldn't use modal segues to transition between different parts of app, would I need to use a chain of UINaviationController over and over? That seems like the 'easy way', but I'm pretty sure that's the wrong way.
This is question is as much about your development workflow as structure.
The structure of iOS applications is tightly coupled with the user-interface - so that should be your starting point.
Since you're using iOS 5, created a story-board - which captures the user interaction through a series of views - is what you do first.
Associated with each view is a ViewController - which is instantiated by the framework as required. In most cases, the structure of your application is going to hang beneath this.
I wonder what the optimal way is to respond to notifications sent out by the notification centers.
Here is an example:
I have a model which receives updates from the server.
Whenever new information is received a notification is generated and posted though the NSNotificationCenter.
There is a view controller with lots of (partially nested) subviews; depending on the type of information received I have to update a particular subview.
For me, there are currently two solutions:
The view controller becomes observer and tells a particular view to update based on the notification name. [subviewx pleaseUpdate];
Each view registers an a observer and depending on the notification name.
The downside of 1 is that the vc has to deal with all notifications although he is not really affected.
Is there any proposed way to do this? Should the responsible view controller deal with all notifications or is it ok for a UILabel, for instance, to become an observer and be somewhat independent.
Thanks for your opinion!
An interesting question - technically, both approaches produce the same result.
However, personally I'd lean towards keeping your notification handling in the view controller, because that's closer to the model-view-controller (MVC) pattern in iOS.
The other advantage of having your notification in the view controller is that you may want to reuse your views elsewhere in your app, and you don't want adverse side effects happening when views start responding to notifications they weren't intended to receive. Collating all your notifications in the view controller will also make handling them much easier - don't forget you need to remove your notification observers when you're done with the view, and having all your removeObserver statements in one place is arguably far better than spread across multiple classes.