I am using VerificationController.m provided by Raywenderlich for validating receipts for in ap purchase. It is working fine for XCode5 but in XCode6 it is giving number of errors. probably due to C++ code like:
Missing Code for Method declaration
#end must appear in objective-c
context Conflicting types for 'checkReiptSecurity'
can anyone tell me what is needed to be done ?
Edit : Here are errors screenshot
Have you fixed this? I was running in to the exact same problem so I'll leave my fix here for anyone that comes looking. It turns out in newer versions of Xcode you aren't allowed to put C/C++ code in objective-C context anymore. So I moved the declarations for unsigned int iTS_intermediate_der_len, unsigned char iTS_intermediate_der[], char* base64_encode(const void* buf, size_t size), and void * base64_decode(const char* s, size_t * data_len) to the top of the file, above the #implementation tag.
Have you downloaded sample code? I have downloaded sample code and its working fine at my side. It seems that you have missed or added an extra braket } or { in your code.
May be this happened when you was trying to comment this code [UIDevice currentDevice].uniqueIdentifier; because originally this line produce an error.
Related
I believe ive looked at every article related to keyboard input, but still cant get it to work. ALl i want is a output, using NSLog everytime i hit a key, in the app or not. Im currently using xcode 5. Ive tried many snippets of code such as
[NSEvent addGlobalMonitorForEventsMatchingMask:NSKeyDownMask handler:^(NSEvent *event)
NSLog(#"%#",event.characters);
and im not sure where to put his code. Do i put it in the main function like this
#import <Foundation/Foundation.h>
#import <appkit/NSEvent.h>
int main(int argc, char * argV[]) {
#autoreleasepool{
[NSEvent addGlobalMonitorForEventsMatchingMask:NSKeyDownMask handler:^(NSEvent *event)
NSLog(#"%#",event.characters);
}
}
Clearly im new to objective-C, and i dont plan on continuing with it unless i can get keyboard input to work. Ive tried tutorials, snippets from keyloggers, and the mac dev forums. Thanks.
Your code is pretty close but you're getting hung up on block syntax. Blocks are very powerful and useful, but the syntax is truly awful and I still struggle with it 2 years after starting to work with them. Blocks are much less readable than C function pointers, and that's saying a lot.
It should look like this:
int main(int argc, char * argV[])
{
#autoreleasepool
{
[NSEvent addGlobalMonitorForEventsMatchingMask: NSKeyDownMask
handler: ^(NSEvent *event)
{
NSLog(#"%#",event.characters);
}
];
}
}
I put all the opening and closing braces on separate lines for clarity. A block needs to be enclosed in braces, and you were missing braces, as well as the closing bracket on your call to addGlobalMonitorForEventsMatchingMask:handler:
BTW, it's very unusual to change the main() function on a Mac or iOS program. Usually you leave that alone, and then set up an application object, set up a delegate, and put your custom code in the app delegate.
You should start of using the normal Cocoa design patterns for applications, and not try to toss them.
If you want to work with main() in C style you should think about creating a command line tool intend of an interactive application. You're going to set yourself up for failure if you don't follow the standard patterns. There's just too many ways to get things wrong.
Your main is missing the housekeeping needed to create a working iOS or Mac application
I have used JSONKit library to parse dictionary and get JSON string. All is well and good with normal devices (iOS7). But when i run application in iOS 7-64 bit simulator it was crashed at below method:
- (NSString *)JSONString;
And the crash message shows on this line of JSONKit.m class
Tried to find out it but not able to sort out.
And i ended up with our native NSJSONSerialization class.
Did any one sort out this?
As far as I know there are more than one patch versions that tried to fix the 64 bit crash issue you mention here, e.g. JSONKit 64bit crash fix by heroims.
They all tried to fix that troublesome line for getting tagged pointers, "the very first thing that a pointer to an Objective-C object "points to" is a pointer to that objects class":
*((void **)objectPtr)
I wrote a simple code to emulate the crash,
NSDictionary *dic = #{#"hi":#(4)};
void *keys[2], *objects[2];
CFDictionaryGetKeysAndValues((CFDictionaryRef)dic, (const void **)keys, (const void **)objects);
void *objectPtr = objects[0];
void *another = *((void **)objectPtr);//Only works for 32 bit machine
NSLog(#"%#",[another description]);
My guess is that for 64bit compiler, apple changed the tagged pointer implementation for NSNumber, which causes the crash. Check the discussion for tagged pointers here stackoverflow.com/questions/5819387/why-is-nsnumber-immutable
If I change NSDictionary *dic = #{#"hi":#(4)}; to NSDictionary *dic = #{#"hi":#"hello"}; it won't crash.
The patch I mentioned here just used object_getClass, which seems to defeat the original purpose, "Why not just use object_getClass()?..." (the comments right above)
So like you said now I also end up using NSJSONSerialization class.
There is an patched version of JSONKit here that fixes the 64 bit issues among others.
I'm having a really weird problem here with NSUInteger in iOS7,
everything is perfect before iOS7, I guess it's related to the 64-bit support in iOS7.
My code is like this, very simple:
if (blah blah blah) {
NSUInteger firstRow = 0;
firstRow = ([self.types containsObject:self.selectedMajorType] ?
[self.types indexOfObject:self.selectedMajorType] + 1 : 0);
...
}
According to my console,
[self.types containsObject:self.selectedMajorType] is true
[self.types indexOfObject:self.selectedMajorType]+1 is 1,
no doubt, and indexOfObject also returns an NSUInteger (according to Apple's document),
here's the screenshot:
but firstRow is always fking **0
This is so creepy I don't know what's going on with NSUInteger,
can someone help me? Thanks a lot!!
____new finding____
I guess this is the problem? It's weird..
I tried to recreate this scenario but I was always getting the expected result 1.
Here is the screen shot:
Here is the project, try running this and see if you still face the problem.
PS. I was using xcode 5.1 and iPhone 64bit Simulator.
=============UPDATE================
Here are some explanations on the lldb commands you used.
po : prints the objective C description of an object.
print / p : Evaluates a generalized expression in the current frame. Specify return type of the function if not used in your program.
Hope this screenshot will help you understand more.
I just upgraded Xcode + iOS SDK to the latest versions (5.1/7.1) and am now getting a bunch of errors about implicit conversions losing precision (NSInteger to int etc).
Does anybody know if there is a compiler flag or something that allows me to tell the compiler to treat those as warnings rather than errors again? I couldn't find anything so far. I really don't want to go through the code and add explicit casts everywhere as this would be in a lot of places.
This is an error for good reason. NSInteger throughout your codebase will make sure that when you compile the code for 32 and 64 bit iOS devices they are handled consistently. In the 32 bit world NSInteger and int were the same, but with the advent of the iPhone 5S and the iPad Air, iOS is no longer 32 bit only.
As others have said, there really is no way around this if you don't want trouble with modern devices.
If you just want to get back to work and deal with this problem later, then you need to remove arm64 from the 'Valid Architectures' and 'Architectures' items in your project's Build Settings.
As others have said, you really should fix the warnings, but this was a nasty little surprise by Apple (that is, adding the arm64 architecture to Build Settings on Xcode 5.1) so I can totally understand wanting to put these warnings away for a while and work on what ever you were working on before you decided to upgrade.
Indeed XCode now includes the arm64 architecture.
NSInteger is something completely different now as it is define in NSObjCRuntime.h :
#if __LP64__ || (TARGET_OS_EMBEDDED && !TARGET_OS_IPHONE) || TARGET_OS_WIN32 || NS_BUILD_32_LIKE_64
typedef long NSInteger;
typedef unsigned long NSUInteger;
#else
typedef int NSInteger;
typedef unsigned int NSUInteger;
#endif
To deal with it you should improve your codebase. First of all, you have to be really consistent. Assign NSInteger only to NSInteger and not to int. Avoid all kind of :
int i = [aString integerValue] ( as it returns a NSInteger)
but
NSInteger i = [aString integerValue] (and if it's a long type then you won't have any trouble.)
Moreover, another issue you might have is when you want to create a string from a value.
What you could do is something like:
#define cL(v) (long)(v)
#define cUL(v) (unsigned long)(v)
NSLog(#"array.count: %ld", cUL(anArray.count));
array.count returns an unsigned int under armv7(s) and an unsigned long under arm64. By always casting into an unsigned long you will not face any warning anymore and, more important, do not get any bug.
This "logic" have been introduced by Apple itself on some tech-talks videos there:
https://developer.apple.com/tech-talks/videos/ (video "Architecting Modern iOS Games". Play the video around 10m00s)
You should go and cast them the way they ought to be. Apple isn't complaining for no reason - it also ensures that you don't get any weird unexpected behaviour later down the line. I suggest you go and cast them all. It's extreme but well, it's clean.
I followed Claus's post to set up code coverage on Xcode 4.2 with LLVM 3.0. I'm able to see test coverage files, but they're only for my unit test classes, not my actual project classes. I've tried setting Generate Test Coverage Files and Instrument Program Flow to Yes on my main target, but that didn't help, as it failed with the following error:
fopen$UNIX2003 called from function llvm_gcda_start_file
To clarify, I don't think that's even the right approach - I just tried it to see if it would generate code coverage on my project classes.
At this point, I'd be happy to try anything that gets code coverage working on my app. Any suggestions?
You are expecting linker problem, profile_rt library uses fopen$UNIX2003 and fwrite$UNIX2003 functions instead of fopen and fwrite.
All you need is to add the following .c file to your project:
#include <stdio.h>
FILE *fopen$UNIX2003( const char *filename, const char *mode )
{
return fopen(filename, mode);
}
size_t fwrite$UNIX2003( const void *a, size_t b, size_t c, FILE *d )
{
return fwrite(a, b, c, d);
}
This code just remaps the missing functions to standard ones.
Note on $UNIX2003 suffix:
I've found an Apple document saying:
The UNIX™ conformance variants use the $UNIX2003 suffix.
Important: The work for UNIX™ conformance started in Mac OS 10.4, but was not completed until 10.5. Thus, in the 10.4 versions of libSystem.dylib, many of the conforming variant symbols (with the $UNIX2003 suffix) exist. The list is not complete, and the conforming behavior of the variant symbols may not be complete, so they should be avoided.
Because the 64-bit environment has no legacy to maintain, it was created to be UNIX™ conforming from the start, without the use of the $UNIX2003 suffix. So, for example, _fputs$UNIX2003 in 32-bit and _fputs in 64-bit will have the same conforming behavior.
So I expect libprofile_rt to be linked against 10.4 SDK.
I use CoverStory http://code.google.com/p/coverstory/ a GUI for .gcda and .gcno files.
The documentation explains the settings needed to generate these files http://code.google.com/p/coverstory/wiki/UsingCoverstory.