Is there a way to update a complication directly from the iPhone app? - apple-watch

I'd like to allow the user to be able to bypass the watch app altogether if possible.
I've tried importing ClockKit on my ViewController to create an instance of CLKComplicationServer. I get the "No such module" error.
Is there a way to communicate directly with the complication from the iOS app?

CLKComplicationServer is part of ClockKit that is available only watchOS2.
You can send data for complication from iOS using [WCSession transferCurrentComplicationUserInfo:]. Not like [WCSession transferUserInfo:] It will awake watchOS App, and deliver your message as soon as possible.
It will awake your watchOS App, and call -(void)session:(WCSession *)session didReceiveUserInfo:(NSDictionary<NSString *,id> *)userInfo of Watch side WCSession's delegate. In this delegate, you can use ComplicationServer like this:
CLKComplicationServer* server = [CLKComplicationServer sharedInstance];
[server.activeComplications enumerateObjectsUsingBlock:^(CLKComplication * _Nonnull each, NSUInteger idx, BOOL * _Nonnull stop) {
[server reloadTimelineForComplication: each];
}];
finally it will invoke your ComplicationController.

Related

is it possible to track location even if application is not running

In an iPhone application, is it possible to track location and send it to the server even if the application that has permission to location is not running in the background.
This is possible — see this document for multitasking in general and this section of the Location Awareness Programming Guide for "Getting Location Events in the Background". Of course, all these talk about all of the various ways an iOS device can get your location (cell tower triangulation, Skyhook-style wifi network observation and GPS), not exclusive GPS.
In short, from reading those docs: add the UIBackgroundModes key into your info.plist, which is an array, and put the value 'location' into it. You'll then receive CLLocationManager updates even when in the background.
However, if you want to be nice to the battery then you're better off using the startMonitoringSignificantLocationChanges method on a CLLocationManager. Then you get suitably significant location updates even when in the background without being a full on background app. Other parts of the documentation state that a significant change is any change from one cell tower to another.
If the App is in the background, you can add a key-value pair in info.plist. The key is UIBackgroundModes and the value is like below :
Then do something in the background :
- (void)applicationDidEnterBackground:(UIApplication *)application
{
// Use this method to release shared resources, save user data, invalidate timers, and store enough application state information to restore your application to its current state in case it is terminated later.
// If your application supports background execution, this method is called instead of applicationWillTerminate: when the user quits.
UIDevice *device = [UIDevicecurrentDevice];
BOOL backgroundSupported = NO;
if ([device respondsToSelector:#selector(isMultitaskingSupported)]) {
backgroundSupported = YES;
}
__blockUIBackgroundTaskIdentifier bgTaskId = [application beginBackgroundTaskWithExpirationHandler:^{
[application endBackgroundTask:bgTaskId];
bgTaskId = UIBackgroundTaskInvalid;
}];
if (backgroundSupported) {
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
//
});
}
}
But if the app is not even in the background, viz, not in the memory, then what can the app do? The CPU would not run a line of code of the app.

Capture incoming Callevent using coretelephony?

I want to create an application for jailbroken iphone (ios 4.0 or greater). I want my application to remain running and whenever my phone starts ringing (for an incoming call), my application should be able to capture that "call incoming" event and based on that i could perform some function e.g. lower speaker volume.
Can anyone guide me to the right direction, as to how can i capture such event, or if it is available in private coretelephony framework ?
Are you sure you want to monitor calls and not use
- (void)applicationWillResignActive:(UIApplication *)application
{
/*
Sent when the application is about to move from active to inactive state. This can occur for certain types of temporary interruptions (such as an incoming phone call or SMS message) or when the user quits the application and it begins the transition to the background state.
Use this method to pause ongoing tasks, disable timers, and throttle down OpenGL ES frame rates. Games should use this method to pause the game.
*/
}
which is even in default XCode4 template?
If you still want call monitoring - it's available in public part of Core Telephony on iOS 4+
#import <CoreTelephony/CTCall.h>
#import <CoreTelephony/CTCallCenter.h>
....
CTCallCenter *callCenter;//make it ivar if you are using ARC or handler will be auto-released
..
callCenter = [[CTCallCenter alloc] init];
callCenter.callEventHandler=^(CTCall* call)
{
NSLog(#"Call id:%#", call.callID);
[self callStateChange:call.callState andId:call.callID];
if (call.callState==CTCallStateDialing)
{
NSLog(#"Call state:dialing");
}
if (call.callState==CTCallStateIncoming)
{
NSLog(#"Call state:incoming");
//here you lower your speaking volume if you want
}
if (call.callState==CTCallStateConnected)
{
NSLog(#"Call state:connected");
}
if (call.callState==CTCallStateDisconnected)
{
NSLog(#"Call state:disconnected");
}
};

UILocalNotification fires after reinstalling the app

My app has an alarm function using UILocalNotification, and it works great. However, if the user uninstalls the app, then later REINSTALLS it, he would receive all the "in between" notifications at once.
I have tried to call:
[[UIApplication sharedApplication] cancelAllLocalNotifications];
if it's the first time the app is launched, but it doesn't help, because the notification is received even before application:didFinishLaunchingWithOptions: is called.
This was worse in 4.0 when the alarm was repeated even if the user has deleted the app, but at least that bug was fixed by Apple in later release. However now I'm stuck with this. Anyone has an idea?
According to Apple, this is not a bug (I filed a bug report). The system retains the UILocalNotifications for uninstalled apps for 24 hours just in case the user deleted the app by accident, and restores the said UILocalNotifications if the app is re-installed within that time frame.
The solution would be to remove all UILocalNotifications on first startup, like so:
- (BOOL) application: (UIApplication*) application
didFinishLaunchingWithOptions: (NSDictionary*) launchOptions
{
if (self.isFirstRun)
{
[[UIApplication sharedApplication] cancelAllLocalNotifications];
self.firstRun = NO;
}
/* Other code here */
...
}
of course, implement your own firstRun setter and getter to fetch/save into persistent storage, like NSUserDefaults.
This is actually a bug in iPhone. If you removed the application and install it later also, it will have same app id, so when the application is reinstalled all the past local notifications were fired even if you didn't open the app.

iOS 4: Remote controls for background audio

I'm currently attempting to set up background audio for an app I'm developing for iOS 4. The app doesn't have a dedicated music player viewController, however, unlike other background audio apps such as Pandora, which makes the task a bit more confusing.
I've set the appropriate Info.plist settings correctly and have an AVAudioPlayer object in my app delegate which is accessible from everywhere. When the user plays a song, I replace the AVAudioPlayer with a new one initialized with the song and play it. This all works great, except now I have no idea how to go about supporting remote control events.
Based on Apple's documentation, I have this:
- (void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
[[UIApplication sharedApplication] beginReceivingRemoteControlEvents];
[self becomeFirstResponder];
}
- (void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
[[UIApplication sharedApplication] endReceivingRemoteControlEvents];
[self resignFirstResponder];
}
- (BOOL)canBecomeFirstResponder {
return YES;
}
- (void)remoteControlReceivedWithEvent:(UIEvent *)event {
switch(event.subtype) {
case UIEventSubtypeRemoteControlTogglePlayPause:
if([iPhoneAppDelegate backgroundAudioPlayer].playing)
[iPhoneAppDelegate pauseBackgroundAudioPlayer];
else
[iPhoneAppDelegate playBackgroundAudioPlayer];
break;
}
}
The thing is, where do I put this? Apple's documentation seems to suggest this should go in some view controller somewhere, but my app has lots of view controllers and navigation controllers. Wherever I try to put this, for some reason tapping the Toggle Play/Pause button in the multitasking tray remote controls either causes the song to just pause for a moment and then unpause, or somehow causes the song to play twice.
The documentation examples are a bit misleading, but there is no need to subclass anything anywhere. The correct place to put remoteControlReceivedWithEvent: is in the application delegate, as it remains in the responder chain regardless of whether the app is in the foreground or not. Also the begin/end receiving remote control events should be based on whether you actually need the events, not on the visibility of some random view.
I found a couple of solutions to receiving global remote control events on the Apple Developer Forums after a bit of searching.
One way is to subclass UIWindow and override its remoteControlReceivedWithEvent:.
The second, perhaps nicer way is to subclass UIApplication and override sendEvent:. That way, you can intercept all the remote control events and handle them there globally, and not have any other responders handle them later in the responder chain.
- (void)sendEvent:(UIEvent *)event {
if (event.type == UIEventTypeRemoteControl) {
// Handle event
}
else
[super sendEvent:event];
}
The second method didn't work for me, sendEvent was never called. However the first method worked just nicely (subclassing UIWindow).
I struggled with this one for a while and none of the answers above worked. The bug in my code, and I hope that it will help someone reading this, was that I had the AudioSession set to mix with others. You want to be the foreground audio player to get Remote Control events. Check to see if you have INCORRECT code like this:
[[AVAudioSession sharedInstance] setDelegate: self];
[[AVAudioSession sharedInstance] setCategory: AVAudioSessionCategoryPlayback error: nil];
UInt32 doSetProperty = 0;
AudioSessionSetProperty (
kAudioSessionProperty_OverrideCategoryMixWithOthers,
sizeof (doSetProperty),
&doSetProperty
);
NSError *activationError = nil;
[[AVAudioSession sharedInstance] setActive: YES error: &activationError];
And remove the AudioSessionSetProperty, or change doSetProperty to 1.
No need to subclass Window or forward events. Simply handle it from your main view controller. See the Audio Mixer (MixerHost) example for details.
http://developer.apple.com/LIBRARY/IOS/#samplecode/MixerHost/Listings/Classes_MixerHostViewController_m.html
Documentation explains it very well.
https://developer.apple.com/library/ios/documentation/EventHandling/Conceptual/EventHandlingiPhoneOS/Remote-ControlEvents/Remote-ControlEvents.html
One thing that seems to influence this behavior is any category options you set for your AVAudioSession using setCategory:withOptions:error: instead of just setCategory:error:. In particular, from trial and error, it appears that if you set AVAudioSessionCategoryOptionMixWithOthers you will not get remote control events; the now playing controls will still control the iPod app. If you set AVAudioSessionCategoryOptionDuckOthers you will get remote control events, but it seems like there may be some ambiguity regarding which app is controlled. Setting the categoryOptions to 0 or just calling setCategory:error: works best.

Problem with applicationShouldTerminate on iPhone

I'm having a problem with applicationShouldTerminate.
What ever I do it seams that has no effect. Any help would be
appreciated.
I'm well versed in programing but this just gives me headache. Im going
over some basic tutorials for xcode , as I'm new to mac in general, and am currently looking at a simple flashlight app.
It exists but I would like to add a alert box here with option not to
quit.
(void)applicationWillTerminate:(UIApplication *)application
{
[application setIdleTimerDisabled:NO];
}
this has no effect, alert is closed even before its created.
(void)applicationWillTerminate:(UIApplication *)application
{
[application setIdleTimerDisabled:NO];
UIAlertView *alertTest = [[UIAlertView alloc]
initWithTitle:#"This is a Test"
message:#"This is the message contained
with a UIAlertView"
delegate:self
cancelButtonTitle:#"Button #1"
otherButtonTitles:nil];
[alertTest addButtonWithTitle:#"Button #2"];
[alertTest show];
[alertTest autorelease];
NSLog(#"Termination");
}
I did some reading online and found that it should be possible to do
this with
(NSApplicationTerminateReply)applicationShouldTerminate:(NSApplication*)sender
But no mater where I put that declaration I get error: syntax error
before NSApplicationTerminateReply.
There is no syntax error except that xcode seems not to recognize
NSApplicationTerminateReply as valid input.
Any sample code would be greatly appreciated.
I know this is a non-answer, but hopefully I can be helpful:
Displaying a "Really quit?"-type alert like this, even if you can pull it off technically (and I'm not sure you can), is a bad idea and is likely to either cause rejection from the App Store or, at best, an inconsistent user experience because no other apps do this.
The convention with iPhone apps is to save state if necessary, then yield control (for termination) as quickly as possible when the user hits the home button or switches apps.
To ensure a consistent experience, Apple probably has an aggressive timer in place to restrict what you can do in applicationWillTerminate. And even if they don't have a technical measure in place, they probably have an App Store approval policy to ensure that applications quit immediately when they're asked to.
applicationShouldTerminate and NSApplication do not exist on the iPhone. You have to use UIApplication.
The alert view is never shown because the 'show' method does not block, and therefore, the end of 'applicationWillTerminate' is reached immediately after you create the alert view and try to show it. I believe this is by design. You can't really begin asynchronous operations in 'applicationWillTerminate'.
With regards to the applicationShouldTerminate error, in case anyone's curious, NSApplicationTerminateReply and NSApplication seem to be deprecated...even though the OP's method is exactly how it appears in the docs!
Defining your method as the below should build with no errors:
-(BOOL)applicationShouldTerminate :(UIApplication *)application
I think I found the answer to what I wanted to do but will need to check it when I get back home.
Some directions were found here
http://blog.minus-zero.org/
The iPhone 2.0 software was recently released, and with it came the
ability for users to download native apps (i.e., not web sites)
directly to their phones from within the iPhone UI or via iTunes.
Developers (anyone who pays Apple 59GBP for the privilege) can then
write their own apps and have them available for purchase in the App
Store.
One limitation of the Apple-sanctioned SDK is that only one
application is allowed to be running at a time. This presents a
problem for apps such as IM clients, music players and other programs
whose functionality relies on being able to run in the background.
Another example (courtesy of James) would be an app that takes
advantage of the iPhone 3G's GPS chip to create a log of all the
places you visit.
However, there is a neat trick that I discovered: your app will only
get terminated if you switch away from it, and hitting the iPhone's
power button while your app is in the foreground doesn't count as
switching away. The upshot of this is you can create apps which
continue to run while the iPhone is in your pocket - perfect for the
GPS example.
Achieving this is as simple as implementing two methods in your
UIApplication delegate - applicationWillResignActive: and
applicationDidBecomeActive:. Here's a simple example to demonstrate
the effect.
In your UIApplication delegate header file, add a new ivar: BOOL
activeApp. Then, in your implementation, add the following three
methods:
- (void)applicationWillResignActive:(UIApplication *)application {
NSLog(#"resigning active status...");
activeApp = NO;
[self performSelector:#selector(sayHello) withObject:nil afterDelay:1.0];
}
- (void)applicationDidBecomeActive:(UIApplication *)application {
NSLog(#"becoming the active app...");
activeApp = YES;
}
- (void)sayHello {
NSLog(#"Hello!");
if (!activeApp)
[self performSelector:#selector(sayHello) withObject:nil afterDelay:1.0];
}