If I init additional CLLocaitonManager instance that track user location, is It will increase the load? Or Should I using one CLLocaitonManager instance between classes?
Creating too many CLLocationManager or increasing the update intervals of the Core location services severely drains battery. So creating too many instances is not advised. Dont see a need for this.
A good practice is to init one CLLocationManager in a viewController. If moving to another viewController, then stopUpdates on the current CLLocationManager & create a new manager in the new viewController. This is one pattern.
Another pattern is to create a CLLocationManager in app delegate & make it available throughout your app. This is like a global variable. But generally avoid global declaration of this variable because it continuously consumes your battery life.
So basically if all your classes are part of only one viewController then create only one CLLocationManager & share the location updates. If not then create one for each viewController.
Location services require the presence of specific hardware on the given device. So thats why ,its doesn't matter how many instance of CLLocationManager are created. Generally avoid global declaration of this variable because it continuously consumes your battery life. Another wise stop and start each time when ever you need to finding user location.
Related
I am new to IOS and I am following CS193p Stanford's lecture to learn about Core Data and in the demo the Professor used a category with somehow similar to what actually to if we check core data application checkbox while creating application and it puts the core data stuff in appDelegate. That's what professor did in demo he created managedObjectContext in AppDelegate and used a Notification to Pass the Context to controller. Now for Assignment he asked to use UIManagedDocument but I am confused about where to put it. Should I declare it in the View Controller or in AppDelegate and pass context using Notification Centre. So I just want to know which one is better for UIManagedDocument. S
Best way I found is create a new project (just as a sample), check 'Use Core Data' when asked, and look inside the AppDelegate. Use that to see how it's done and possibly, copy the appropriate parts (some adjustments will be needed of course). But mostly, use it to learn how Apple recommends it to be used.
Create a custom class with a shared instance that has managedObjectContext property.
In your application didFinishLaunchingWithOptions in AppDelegate, create your sharedInstance and pass it the 'managedObjectContext`.
MyDataManager *dataManager = [MyDataManager sharedInstance];
dataManager.managedObjectContext = self.managedObjectContext;
Notice also that if you terminate the app by hitting the 'Stop' in Xcode, the data won't be saved (since it's done, as it should, when the AppDelegate is about to close the app properly).
Make sure to also have [self saveContext]; in applicationDidEnterBackground, it supposed to be inside applicationWillTerminate as well. It is a good practice to write the database to memory only when needed (and not at every change). In the AppDelegate, it also ask if the data has changed before committing.
Of course, you can also save manually if you have the managedObjectContext instance.
If you made changes to the database you might have to delete the app from the simulator before running again (otherwise app will crash since the older DB won't match the new one).
Edit: I can't remember where I read it, but the professor does not use CoreData as a database pre-se, only to manage data (images etc.).
You can initialize your UIManagedDocument where ever you want to initiate access to your database. When I did the assignment (last year), I put in the AppDelegate. In glancing back now I see there are two ViewControllers in a UITabBarController and they both need the context. So I used the NSNotification mechanism like Paul did in lecture.
The reasons he gives for using UIManagedDocument over "User Core Data" checkbox (when creating the project) was:
It was simpler for him to explain (UIManagedDocument takes care of lots of complexities)
UIManagedDocument puts you on a fast track to using iCloud
I was just reviewing this as well. If you want to hear from Paul, he talks about it in Lecture 12 (Fall 2013-14) at 14 minutes and 25 seconds (UIManagedContext) and at 14:50 he starts talking about the two ways to get the UIManagedContext -- being UIManagedDocument or the "Use Core Data" checkbox.
Here us a link to the course on iTunes: https://itunes.apple.com/us/course/developing-ios-7-apps-for/id733644550
I am new to iPhone development, i am creating a location based app. i have searched lot related to location and came to knew that use one object ( singleton pattern ) of CLLocationManager through out app, in my app i have to update user's location to server using web service,
UPDATE
as discussion with Umer i came to knew that i can use one object in appdelegate of CLLocationManager and implement delegate methods in that, and update user location to server in app delegate ,
So, is it good to do in appDelegate ??
please help.
Your locationservices will run both in foreground and background, but to allow it to run in background (when the app is open and minimized), you need to declare a special background mode in your projects "Plist" file, if I'm not wrong.
The method didUpdateToLocation will give you updates every time there is a significant movement, which you can define and adjust through various settings, such as CLLocationAccuracy (locationManager.desiredAccuracy and locationManager.distanceFilter).
Depending on what desired accuracy you ask, battery main drain quicker or not.
I don't understand what you mean with "web service". These are not web-related, they're native functionalities of iOS.
You can just call the delegate method of locationManager StartUpdatingLocation when user moves to significant distance & also call the web-service for updating User's Location.
Both Task are done in Background mode.
UPDATED ANSWER
SOURCE CODE
I implemented background location tracking using standard location services, and it works fine. However, since this implementation uses a lot of power, I decided to switch to significant location changes monitoring. Basically, I just changed all the calls to startUpdatingLocation to startMonitoringSignificantLocationChanges and reused the CLLocationManagerDelegate methods I have implemented before.
The problem is that after switching to significant location changes monitoring, the delegate method locationManager:didUpdateToLocation:fromLocation only gets called once when I start monitoring, and is never called again afterwards. I have moved around the phone for a couple of kilometers, and tried riding a train with it, but still the method never gets called. Am I missing something here? Are there settings I need to enable or special code I need to write in order for this to work?
Thanks!
The significant location change requires cell phone towers in order to operate. If you don't have cell phone reception you will not get any results. You can also call CLLocationManager's significantLocationChangeMonitoringAvailable method to see if it is available.
I have an timer in viewDidLoad, but I want to pass variable seconds assigned by slider, so what should I do for this for such implementation?
I think I have to restart app, so is there any other solution, or how can I restart my app?
a) Keep your timer as an instance variable in your appdelegate or somewhere else, and update its interval whenever the slider moves.
b) From the user's perspective you wouldn't want to restart the app for simple things such as these.
c) You can't restart an iPhone app or in any way play around with its lifecycle.
EDIT:
If you are planning to have an instance of the timer available across the app, there are twp ways you can do that.
put is as an instance variable in the appdelegate class, the one which xcode would have created for you, with the projectnameAppDelegate. You will then be able to access it using
[UIApplication sharedApplication].delegate
from which you can get the instance of the NSTimer
Or you can implement a common Singleton class, and put the timer in it. This is a much more accepted approach described here and scroll down to the bottom of the page.
For more info, search on ways to create a global object(although creating a global object is not a good idea), and follow the instructions.
Been researching how to send data from one child view to another child view. The application has several views, where one is kind of real-time Settings view. Changes in settings should effect stuff inside other views.
NSUserDefaults seems to be popular, but I don't want persistent data nor automatic saving into database/file. Looks like potential slowdown, which I want to avoid.
Second popular thing is passing a reference to some common top level object into each child view. Just haven't found any tutorial, which would show me in detail how to do this... Most likely so easy, no tutorial is needed - after you figure it out once! Would appreciate, if you can point me to right direction (URL)!
Question: I'm thinking about using one "singleton object" to store "global data", access it from everywhere anytime. What could wrong with this? If I create it at e.g. appDelegate.m it should exist before anyone tries to access it, right?
I'm looking at this sample code.
I would recommend using delegates and/or notifications.
Instead of creating a new singleton in the app delegate, add the necessary data (or, even better, references to the data) in the app delegate and have the views have references to the app delegate.
You can also set up notifications so that your views can keep track of changes to the data that they display.
The beauty of a singleton is that it is automatically created when you first access it via some [singletonClass sharedInstance]. So you don't need to "create" it while launching. If it is global data that needs to be accessed from any view singleton might be the right way of doing this.