Encountering an issue with SKProductsRequest that is specific to iOS 4.0. The problematic code:
- (void)requestProductData
{
NSSet *productIdentifiers = [NSSet setWithObjects:kLimitedDaysUpgradeProductId, kUnlimitedUpgradeProductId, nil];
self.productsRequest = [[SKProductsRequest alloc] initWithProductIdentifiers:productIdentifiers];
self.productsRequest.delegate = self;
[self.productsRequest start];
}
- (void)productsRequest:(SKProductsRequest *)request didReceiveResponse:(SKProductsResponse *)response
{
NSLog(#"didReceiveResponse");
}
When [SKProductsRequest start] is invoked, the productsRequest:didReceiveResponse: delegate method is never invoked; further, the entire app hangs and is completely unresponsive to input. Obviously, this is a huge issue for our iOS 4.0 users as it not only breaks payments but makes the app completely unusable.
Some other things to note: this only happens on iOS 4.0; iOS 4.2, 3.x are fine. Also: if the delegate is not set on the SKProductsRequest (i.e. comment out the line "self.productsRequest.delegate = self;"), the app doesn't hang (but of course in that case we have no way of getting the product info). Also, the problem still reproduces with everything stripped out of the productsRequest:didReceiveResponse: callback (that method never actually gets called). Finally, if the productIdentifiers NSSet object is initialized to an empty set, the hang doesn't occur.
Has anybody else experienced this? Any ideas/thoughts on what could be going on here, and how we might be able to work around this?
have you tried implementing –request:didFailWithError: in your delegate, and seeing if that's getting called?
I had a similar problem to this today. No response to any of the delegate methods after I made a SKProductRequest.
Everything was working fine, I didn't make any changes to the IAP code yet it broke.
Finally found the problem. If you self reject the app, then the product ID's you made become invalid. We resolved it by resubmitting the app and creating new ID's. Everything started to work again after that.
Related
I have implemented the following code to do a Twitter Share. In my code I try to test for iOS 5 and if that does not work, I go back to the old way of sharing using ShareKit's Twitter code.
I showed the code to a co worker and he suggested that my code may have flaws and that I need to do two things:
Do a proper Run Time check?? (since it may crash on IOS 4 and earlier) EVEN though it did not.
Weak Link the Twitter frame work
Can someone kindly explain what a proper run time check would be? and Why Weak Link?
NSString *text = [NSString stringWithFormat:#"#Awesome chart: %#", self.titleLabel.text];
if ([TWTweetComposeViewController canSendTweet])
{
TWTweetComposeViewController *tweetComposeViewController = [[TWTweetComposeViewController alloc] init];
[tweetComposeViewController setInitialText:text];
[tweetComposeViewController addImage:image];
[tweetComposeViewController setCompletionHandler:^(TWTweetComposeViewControllerResult result){
dispatch_async(dispatch_get_main_queue(), ^{
[self dismissModalViewControllerAnimated:YES];
if (result == TWTweetComposeViewControllerResultDone)
{
NSLog(#"iOS 5 onwards Twitter share complete");
}
});
}];
[self presentViewController:tweetComposeViewController
animated:YES
completion:^{ }];
}
else
{
SHKItem *item = [SHKItem image:image title:text];
// Share the message.
[SHKTwitter shareItem:item];
NSLog(#"Device does not support Twitter library");
}
}
A weak link simply means the a framework is not required to be on the device. Or put another way, when you add frameworks to your project, the app will require that framework to be on the device. So if you require a framework to be there, and it isn't, then the app will crash. In your case, you would want to weak link the twitter framework if you want the app to run on iOS version prior to iOS 5 (ie iOS 4.x).
A proper run time check means you should load the app onto your device (running iOS 5 or later) and test the twitter feature of your app. If it crashes, then you know you have a problem.
I skimmed your code and everything looks fine. I didn't run it through my complier though so I can't speak for syntax errors and such. The one change I would make is:
if ([TWTweetComposeViewController canSendTweet])
to
Class twClass = NSClassFromString(#"TWTweetComposeViewController");
if (!twClass) // Framework not available, older iOS
return;
The reason why I use that is becuase that literally checks if the framework is on that device, while canSendTweet checks if the user is logged in. So I don't want to confuse a user not being logged in with a user whose device doesn't support Twitter with iOS 5.
Let me know if you need anymore help.
DETweetComposeViewController is another option. It's compatible with iOS 4 too.
I think you also leak the controller (as do most of the code samples I've seen).
On the other hand, you paid attention to the documentation about the completion handler, and correctly make sure you do UI work in the main thread. I need to go fix my implementation to do the same.
I have spent the last 2 days fighting trying to get in app purchases working! The app has not been approved by Apple (its not ready yet), so I just did the Developer Pulled Binary method. I added a non-consumable (and I am pretty sure my contracts are cleared) and called it com.MYAPP.MYAPPNAME.levelone
I am using the MKStoreKit 3.1 relevant
I just want to see that the item will appear in the NSLog for the app, so I have this in my App Delagate
- (void) applicationDidFinishLaunching:(UIApplication*)application
{
[MKStoreManager sharedManager];
[[MKStoreManager sharedManager] purchasableObjectsDescription];
...
When I run this it just tells me
Problem in iTunes connect configuration for product: com.mycompany.myapp.005
Problem in iTunes connect configuration for product: com.mycompany.myapp.featureA
This is a Cocos2d based game if it makes any difference.
There are reasons why I didn't implement MKStoreManager to accept a set of products as parameters.
1) You should not litter your code with hard coded product ids. This is because you initiate a purchase request with a product id. The former happens on AppDelegate and the latter happens on one of your view controllers. So there should be some file where you put in all those product constants. Why not use MKStoreManager.h itself for that?
MKStoreKit 3.1 requires some configuration before you use it; it doesn't just work out of the box.
Specifically, you need to tell MKStoreKit the list of features/product identifiers that you have configured in iTunes Connect. Oddly, you do that by modifying the source code, instead of passing in an array of arguments.
Examine MKStoreManager.h lines 26-34:
// CONFIGURATION STARTS -- Change this in your app
define kConsumableBaseFeatureId #"com.mycompany.myapp."
#define kFeatureAId #"com.mycompany.myapp.featureA"
#define kConsumableFeatureBId #"com.mycompany.myapp.005"
// consumable features should have only number as the last part of the product name
// MKStoreKit automatically keeps track of the count of your consumable product
#define SERVER_PRODUCT_MODEL 0
// CONFIGURATION ENDS -- Change this in your app
You have to change that stuff. If you don't, you'll get errors like the one you posted.
But that's not the only place. You also have to update the requestProductData implementation function in MKStoreManager.m, where kFeatureAId and kConsumableFeatureBId are used.
-(void) requestProductData
{
SKProductsRequest *request= [[SKProductsRequest alloc] initWithProductIdentifiers:[NSSet setWithObjects:
kFeatureAId,
kConsumableFeatureBId,
nil]];
request.delegate = self;
[request start];
}
You have to specify the product identifier list yourself; MKStoreKit can't guess it for you.
Still, it's weird. It makes you wish MKStoreKit would just accept an array of product identifiers in its initializer!
Remove the unused products inside MKStoreManager.m as follows
-(void) requestProductData
{
SKProductsRequest *request= [[SKProductsRequest alloc] initWithProductIdentifiers:[NSSet setWithObjects:
kFeatureAId,
//kConsumableFeatureBId,
nil]];
request.delegate = self;
[request start];
}
I'm trying to implement the Paparazzi 2 assignment from the Stanford CS193 course and I'm running into a problem. My one call to save the database is when the app exits (I'm borrowing heavily from Mike Postel's version to check my code):
- (void)applicationWillTerminate:(UIApplication *)application {
if (flickrContext != nil) {
if ([flickrContext hasChanges] == YES) {
NSError *error = nil;
BOOL isSaved = [flickrContext save:&error];
NSLog(#"isSaved? %#", (isSaved ? #"YES" :#"NO") );
// Replace this implementation with code to handle the error appropriately.
if(isSaved == NO){
NSLog(#"Unresolved error %#, %#", error, [error userInfo]);
abort();
}
}
}
}
Unfortunately, this doesn't seem to be doing the job. I'm getting the occasional EXEC_BAD_ACCESS call that might be related to this, but the database never saves. I've inserted the save into other pieces and it works fine there, just not in this routine. I'm not releasing any of the managed objects in my views, just the managed object context (flickrContext, or whatever I'm calling it in a view).
Any ideas?
Are you sure that applicationWillTerminate: is even being called?
With iOS4 and background process support, the usual application lifecycle is now:
running -> background -> background suspended -> exit
You get an applicationDidEnterBackground: call when transitioning into the background state, but no further notification when the background process suspends or exits.
So, you really need to save state in applicationDidEnterBackground: for iOS4, as well as in applicationWillTerminate: for older versions
flickrContext is your managedObjectContext? I'm betting it is nil or otherwise hosed when you hit this method. You say you are releasing it in a view - surely you should be creating just one, having it owned by the application delegate, and release it only in app delegate's dealloc?
(And when you need to use it -
NSManagedObjectContext* moc = [(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext];
)
Regarding your EXEC_BAD_ACCESS - what happens with NSZombieEnabled = YES? What does the static analyzer say?
Good call. I actually solved this one the old fashioned (brute force) way. It turns out that applicationWillTerminate wasn't being called, but it wasn't obvious. The routine to create the database that I had borrowed from the web was explicitly releasing an NSArray that I'm pretty sure was autoreleased. It essentially turned the program into a time bomb. Although I still haven't figured out why it lasted as long as it did and just didn't manifest until I tried to exit.
I'm still learning XCode and CocoaTouch. I know about NSZombieEnabled but I haven't figured out how to use it correctly yet. I'm still in the ham-fisted monkey stage. Thanks for the tips, though. They were helpful.
i got this piece of code:
- (void)postToWall {
FBStreamDialog *dialog = [[FBStreamDialog alloc] init];
dialog.userMessagePrompt = #"Un tuo commento:";
dialog.attachment = [NSString stringWithFormat:#"{\"name\":\"Bla: %#\"", facebookName];
[dialog show];
[dialog release];
}
the first time it get executed it works fine, no problem. But if I post or skip and then I post again I got an EXC_BAD_ACCESS, due to facebookName. The console shows no error, I found it via DebugConsole. I really don't know why this happens, can someone help?
EDIT: SOLVED!!!
In other parts of the code, I accessed the facebookName string by its name. This apparently leads to crash, so I synthesized it and then accessed it by "self.facebookName".
Thank you.
You should show contextual code regarding facebookName.
I think maybe it is being released by the time you use it again. Just to be safe, you can try doing [facebookName retain] at the beginning of the method and then [facebookName release] at the end, to signify that you need to hold on to the object to do some work.
Yep, using the synthesized property automatically retains objects when you assign them (provided you have the usual, (nonatomic, retain)). Before, it wasn't retaining so by the time you used it again a couple times, you would get EXC_BAD_ACCESS since it no longer existed (was released by then, cause again, it wasn't retained).
You will likely not get a valid stack trace at the time of the crash.
The quickest way to track down the real cause of EXC_BAD_ACCESS is by using the NSZombieEnabled executable argument, and then setting a breakpoint on objc_exception_throw. This will get you a stack trace, and allow you to determine specifically which object you are trying to access.
http://www.cocoadev.com/index.pl?NSZombieEnabled
Using Malloc to debug
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];
}