in my app I'm using the popular service Parse.com and I noticed that it is giving me some problems of energy impact ...
I did some tests and the problem of the energy (that we can all see in xcode in Debag Navigator) is displayed when I insert in AppDelegate the prompts to enter my account number and ID of the APP Parse.com ... Someone He has noticed this problem? why this strong consumption ?? you can 'do about it? I would find myself with memory and battery problems during the development of my app ...
I show you the code colpevo my strange energy impact (I only files in my app I just started so it is not even a big overage)
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// Override point for customization after application launch.
[Parse setApplicationId:PARSE_APP_ID
clientKey:PARSE_CLIENT_KEY];
return YES;
}
Related
I am adopting my iOS widget to my Mac app, and one thing I can't figure out is when I do a deep-link from the widget to the Mac app, where would that get detected? On iOS, it calls:
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation
But I can't find any equivalent method in the NSApplicationDelegate. The closest method is
- (void)application: (NSApplication *)application openURLs:(nonnull NSArray<NSURL *> *)urls
But this doesn't get invoked from the widget's Link.
Is there some other way to handle this on macOS? Do I need to configure something in particular for the openURLs method to be called?
EDIT:
After more testing, I've realized that the application: openURLs method should be called, whether through the widget Link or directly called using the URL scheme (as defined in the Info.plist). I verified this with another test app as well, where I can use [[NSWorkspace sharedWorkspace] openURL: testURL] to open the test app and the application: openURLs DOES get called. But it's not working for my main app for some reason, even though I've followed the same steps and defined the URL scheme in CFBundleURLTypes in the Info.plist file. The main app was created many years ago, whereas the test app was created just today.
Any ideas why the openURLs method isn't getting called in my main app?
I am calling scanForPeripheralsWithServices from didFinishLaunchingWithOptions callback of AppDelegate. The code looks like this:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{
NSLog(#"didFinishLaunchingWithOptions");
// Override point for customization after application launch.
cm = [[CBCentralManager alloc] initWithDelegate:self queue:nil];
[cm scanForPeripheralsWithServices:nil
options:nil];
}
- (void) centralManager:(CBCentralManager*)central didDiscoverPeripheral:(CBPeripheral*)peripheral advertisementData:(NSDictionary*)advertisementData RSSI:(NSNumber*)RSSI{
NSLog(#"Did discover peripheral %#", peripheral.name);
[cm stopScan];
}
Before upgrading to iOS 8 everything was working well, however after the upgrade (exactly the same code, no single line was changed) I am not getting any error, but also didDiscoverPeripheral is not being called.
I appears that the major change which has occurred with Core Bluetooth in iOS 8 is that the BLE stack isn't powered on until you try to connect (or possible issue some other command).
CBCentralManager *cbCentralManager;
[cbCentralManager scanForPeripheralsWithServices:...];
This call used to issue a warning visible in the Xcode debug log saying that the central manager needed to be powered-up before it could be used. However, this warning was always a catch-22 — the only way to power-on the central manager was to send it a message, and the only way for it to process a message was for it to be powered-on.
Apple seems to have resolved this problem by handling power-on a bit differently. Now, after issuing the above command the central manager tells its delegate that its state changed via centralManagerDidUpdateState:.
We resolved the problem you describe by responding to centralManagerDidUpdateState: by re-issuing the scanForPeripherals... message.
I tried to get my app ready for Push Notifications, I insert the following code in the app delegate but when I running the App on my Device (iPhone 3Gs - iOS 5.1.1) the app start's normal but whiteout the "Push Alert" how asks the user to allowed notifications!!!
Can someone help??
Best regards from Germany!
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
[application registerForRemoteNotificationTypes:UIRemoteNotificationTypeBadge|
UIRemoteNotificationTypeAlert|
UIRemoteNotificationTypeSound];
// Override point for customization after application launch.
return YES;
}
you have to create a new appID in the iOS Provisioning Portal (without a wild-card character) like
com.yourcompanyname.yourappname
and enable push notifications for this app id.
Then create a new provisioning profile which you use to build your app. It should work then!
Be sure to change you bundle id in your project settings too.
Hope this helps.
I have successfully enabled background processing for my Core Location app. In order to ensure I am on the right track here is a quick overview of how I implemented ENTERING background mode:
1: info.plist: Added key "Required background modes" with value "App registers for location updates"
2:
- (void)applicationDidEnterBackground:(UIApplication *)application
{
[self.locationManager stopUpdatingLocation];
[self.locationManager startMonitoringSignificantLocationChanges];
}
When EXITING background mode I did so with this code:
- (void)applicationWillEnterForeground:(UIApplication *)application
{
self.locationManager.delegate = self;
[self.locationManager stopMonitoringSignificantLocationChanges];
[self.locationManager startUpdatingLocation];
}
This seems to be working well as I am getting locations reported while my iPhone is off. Any advice on whether this approach is considered "best practice" would be appreciated.
My concern is that even when my app is explicitly terminated on the iPhone the Location Services arrow still shows on the status bar.
My question is: Is it possible to programatically enable/disable an application's background processing?
My reason for this is that if my user does not want to use the location awareness portion of my app, I would like to prevent the app from processing in the background, even if it is not receiving locations.
Thanks and much for any info!
Thank-you for your prompt answers. What seems to be happening is that even though I issue
[self.locationManager stopMonitoringSignificantLocationChanges];
and
[self.locationManager stopUpdatingLocation];
the Location Services arrow thingy on the status bar stays on, even when my app has exited. I have force terminated it as well, but the arrow stays on.
I also have no other apps that are running as suspended. I have looked in Settings > Location Services > MyApp and see that both myApp and the built-in Maps app indicate that they are currently using Location Services, however, neither is actually running.
Does anyone have any idea why this is happening? Could it be that I am not freeing up resources properly when my app either goes into the background or terminates?
All answers are much appreciated.
You could have a setting saved in NSUserDefaults and use that whether or not to enable your background location services.
NSUserDefaults *defaults = [NSUserDefaults standardDefaults];
someFlag = [defaults boolForKey:#"gpsOnOff"];
if (someFlag) {
// enable background services
}
Hmmm……
A question about UILocalNotification and the notificaton's alertLaunchImage.
My app uses UILocalNotifiaction(s) to get users' attention. As usual, an alert is presented with "Action" and "Close" buttons. When the user taps Action, the image specified by alertLaunchImage is presented. The alertLaunchImage is a screenshot of of one of the views of the app which is shown after the data is initialized when launched normally.
Here are the 3 cases when the notification is delivered:
App is running in foreground - no alert, no launchImage is shown as designed. No problems.
If my app is running in background when the notification is delivered, the launchImage works like a charm. No problems. The launchImage with no app-related data is shown and then the app fills up the data. This part works seamlessly.
However, if the app is not running when the notification is delivered, the sequence is confusing - or I missed something. The app gets launched and shows the alertLaunchImage instead of the Default image. Then is goes thru several other screens (as part of initialization and data processing) before the actual screen (live version of alertLaunchImage) is shown.
This can get very confusing to the user. My question comes in here. How can this be avoided?
R/-
Sam.!
you can try cleaning up the alert view settings in applicationWillTerminate:
According to the UIApplicationDelegate reference applicationWillTerminate::
"This method lets your application know
that it is about to be terminated and
purged from memory entirely. You
should use this method to perform any
final clean-up tasks for your
application, such as freeing shared
resources, saving user data,
invalidating timers, and storing
enough application state to
reconstitute your application’s
interface when it is relaunched"
HTH,
Oded
If your app is launched by a local notification, you will receive that notification in the options passed to -application:didFinishLaunchingWithOptions:. Based on that, you can write code that navigates to the correct screen without animations.
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
UILocalNotification *localNotification = [launchOptions valueForKey:UIApplicationLaunchOptionsLocalNotificationKey];
if (localNotification != nil) {
// startup by local notification
} else {
// normal startup
}
}