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?
Related
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.
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'd like to know which is the best way to setup an NSView.
The only method suitable for this purpose, seems to be viewDidMoveToSuperview.
In this method I can add subviews and inviewWillMoveToSuperview I can do geometry operation on frame etc.
But these are only my suppositions... I can't find a useful documentation that explain where is the better function to perform setup operations.
What do you think about that?
The reason you don't find any documentation on where to set up your NSViews is probably that you can set up views, add subviews, etc. in pretty much any method, as long as it is called on the main thread.
For simple apps, applicationDidFinishLaunching: of the application delegate is a useful place.
When the app grows, you might want to consider doing this lazily, when a new window is opened or when a view is added.
For normal apps, you won't need to do anything in viewWillMoveToSuperview/viewDidMoveToSuperview.
Here is a screenshot from Evernote. It appears to have (but i might be wrong) a custom UINavigationBar as well as a custom UITabBar.
A quick glance at the apps on my phone shows i could use a screenshot of Instagram, Path, DailyBooth, ...
From the docs:-
Because managing the navigation bar is
the responsibility of the navigation
controller, direct modification of the
navigation bar itself is considered
off limits for the most part.
Does Apple regard this kind of thing as grounds for AppStore refusal?
There's a distinction between "custom" navigation bars and using private methods.
Apple prevent you from directly modifying the navigation bar by make a lot of the required methods private or properties read-only. If you were to modify a read-only property or use a private undocumented method your application would be rejected (Apple automatically analyse code upon submission to detect for this sort of thing).
However, there's nothing to stop you from implementing your own UINavigationBar equivalent, or customising it using publicly available SDK methods. The issue then becomes whether your application strays too far from the Human Interface Guidelines: although to be honest, Apple are generally fairly flexible on that.
Whilst I wouldn't necessarily recommend this, I've worked on one app where we rolled our own navigation controller because we had some animation and transition requirements that we couldn't achieve with Apple's own class. As long as you're not calling anything untoward or drastically going against the HIGs, you're generally fine.
I'm relatively new to Objective-C and Cocoa... I've been trying to understand how to correctly implement the MVC pattern in Cocoa/Cocoa Touch for a long time now... I understand the idea behind it; it makes complete sense conceptually: a model holds the data, a view is what that the user sees and can interact with, and the controller acts as the bridge between the two. View can't talk to the model, model can't talk to the view. Got it.
What doesn't make sense to me is how to use MVC efficiently… if the user can only interact with the view, and does something to interact with it (i.e. for an iPhone app, the user clicks/drags within a subclass of UIView, triggering the "touchesBegan" and "touchesMoved" methods, etc.), how does the view communicate these events to the controller?
I've looked at countless examples and forums online, but have yet to find a simplified all-purpose way of achieving this… I know how to communicate with a controller through buttons, sliders, and other things that you can connect to an outlet, but for things that don't have a target-action mechanism, what's the best way to do it?
Thanks in advance for any suggestions regarding what to do, or where to look.
The standard way in Cocoa to do this is the delegate pattern (cf. UITableViewDelegate). Your view class would declare a delegate protocol and the controller sets itself as the view's delegate. The view then calls one of the delegate methods you defined whenever it wants to communicate something to the controller.
An alternative would be to implement the target-action mechanism for your view yourself. You get this more or less for free if you subclass from UIControl (just call sendActionsForControlEvents:) but it is quite easy to implement a system that works the same way for any custom class.
(Edit: I suppose a third way is to have the controller observe properties of the view (with KVO). This wouldn't work well to communicate touch events but it is a feasible way if you want to notify the controller about a state change or something like that.)