Search Results

Search found 6 results on 1 pages for 'felixyz'.

Page 1/1 | 1 

  • PDF rendering crashes app Core Graphics

    - by Felixyz
    EDIT: The memory leaks turned out to be unrelated to the crashes. Leaks are fixed but crashes remain, still mysterious. My (iPhone) app does lots of PDF loading and rendering, some of it threaded. Sometime, it seems always after I flush a page cash after getting a memory warning, the app crashes with a bad access when trying to draw a pdf page stored in an NSData object. Here is one example trace: #0 0x3016d564 in CGPDFResourcesGetResource () #1 0x3016d58a in CGPDFResourcesGetResource () #2 0x3016d94e in CGPDFResourcesGetExtGState () #3 0x3015fac4 in CGPDFContentStreamGetExtGState () #4 0x301629a8 in op_gs () #5 0x3016df12 in handle_xname () #6 0x3016dd9e in read_objects () #7 0x3016de6c in CGPDFScannerScan () #8 0x30161e34 in CGPDFDrawingContextDraw () #9 0x3016a9dc in CGContextDrawPDFPage () But sometimes I get this instead: Program received signal: “EXC_BAD_ACCESS”. (gdb) bt #0 0x335625fa in objc_msgSend () #1 0x32c04eba in CFDictionaryGetValue () #2 0x3016d500 in get_value () #3 0x3016d5d6 in CGPDFResourcesGetFont () #4 0x3015fbb4 in CGPDFContentStreamGetFont () #5 0x30163480 in op_Tf () #6 0x3016df12 in handle_xname () #7 0x3016dd9e in read_objects () #8 0x3016de6c in CGPDFScannerScan () #9 0x30161e34 in CGPDFDrawingContextDraw () #10 0x3016a9dc in CGContextDrawPDFPage () Is this an indication that I've mistakenly deallocated an object? It's hard for me to decode what's happening here. This is how I create and retain the various objects involved: // Some data was just loaded from the network and is pointed to by "data" self.pdfData = data; _dataProviderRef = CGDataProviderCreateWithData( NULL, [_pdfData bytes], [_pdfData length], NULL ); _documentRef = CGPDFDocumentCreateWithProvider(_dataProviderRef); _pageRef = CGPDFDocumentGetPage(_documentRef, 1); CGPDFPageRetain(_pageRef); _pdfFrame = CGPDFPageGetBoxRect(_pageRef, kCGPDFArtBox); So the NSData object is retained, and I explicitly retain the page reference. The data provider and the document are already retained by the create-functions. And here is my dealloc method: -(void)dealloc { if (_pageRef) CGPDFPageRelease(_pageRef); if (_documentRef) CGPDFDocumentRelease(_documentRef); if (_dataProviderRef) CGDataProviderRelease(_dataProviderRef); self.pdfData = nil; [super dealloc]; } Am I doing anything wrong? Even an assurance that I'm not, with explanation, would be a help.

    Read the article

  • OAuth secrets in mobile apps

    - by Felixyz
    When using the OAuth protocol, you need a secret string obtained from the service you want to delegate to. If you are doing this in a web app, you can simply store the secret in your data base or on the file system, but what is the best way to handle it in a mobile app (or a desktop app for that matter)? Storing the string in the app is obviously not good, as someone could easily find it and abuse it. Another approach would be to store it on you server, and have the app fetch it on every run, never storing it on the phone. This is almost as bad, because you have to include the URL in the app. I don't believe using https is any help. The only workable solution I can come up with is to first obtain the Access Token as normal (preferably using a web view inside the app), and then route all further communication through our server, where a script would append the secret to the request data and communicates with the provider. Then again, I'm a security noob, so I'd really like to hear some knowledgeable peoples' opinions on this. It doesn't seem to me that most apps are going to these lengths to guarantee security (for example, Facebook Connect seems to assume that you put the secret into a string right in your app). Another thing: I don't believe the secret is involved in initially requesting the Access Token, so that could be done without involving our own server. Am I correct?

    Read the article

  • NSPredicate as a constraint solver?

    - by Felixyz
    I'm working on a project which includes some slightly more complex dynamic layout of interface elements than what I'm used to. I always feel stupid writing complex code that checks if so-and-so is close to such-and-such and in that case move it x% in some direction, etc. That's just not how programming should be done. Programming should be as declarative as possible! Precisely because what I'm going to do is fairly simple, I thought it would be a good opportunity to try something new, and I thought of using NSPredicate as a simple constraints solver. I've only used NSPredicate for very simple tasks so far, but I know that it capable of much more. Are there any ideas, experiences, examples, warnings, insights that could be useful here? I'll give a very simple example so there will be something concrete to answer. How could I use NSPredicate to solve the following constraints: viewB.xmid = (viewB.leftEdge + viewB.width) / 2 viewB.xmid = max(300, viewA.rightEdge + 20 + viewB.width/2) ("viewB should be horizontally centered on coordinate 300, unless its left edge gets within 20 pixels of viewB's right edge, in which case viewA's left edge should stay fixed at 20 pixels to the right of viewB's right edge and viewA's horizontal center get pushed to the right.") viewA.rightEdge and viewB.width can vary, and those are the 'input variables'. EDIT: Any solution would probably have to use the NSExpression method -(id)expressionValueWithObject:(id)object context:(NSMutableDictionary *)context. This answer is relevant.

    Read the article

  • Multiple on-screen view controllers in iPhone apps

    - by Felixyz
    I'm creating a lot of custom views and controllers in a lot of my apps and so far I've mostly set them up programmatically, with adjustments and instantiations being controlled from plists. However, now I'm transitioning to using Interface Builder as much as possible (wish I had done that before, was always on my back-list). Apple is recommending against having many view controllers being simultaneously active in iPhone apps, with a couple of well-known exceptions. I've never fully understood why it should be bad to have different parts of the interface belong to different controllers, if they have no interdependent functionality at all. Does having multiple controllers risk messing up the responder chain, or is there some other reason that it's not recommended, except for the fact that it's usually not needed? What I want to be able to do is design reusable views and controls in IB, but since a nib is not associated with a view, but with a view controller, it seems I'd have to have different parts of the screen be connected to different controllers. I know it's possible to have other objects than view controllers being instantiated from nibs. Should I look into how to create my own alternative more light-weight controllers (that could be sub-controllers of a UIViewController) which could be instantiated from nibs?

    Read the article

  • Optimal pixel format for drawing on iPhone?

    - by Felixyz
    Pretty simple question: when doing some pretty intense drawing with CoreGraphics on the iPhone, how can I specify the pixel format to get optimal performance? Is the format that I get from the context via UIGraphicsGetCurrentContext per definition the best one? I know that RGB565 is supposed to be the fastest to use in OpenGL. Does that go for CoreGraphics as well? General advice?

    Read the article

  • Which pdf elements could cause crashes?

    - by Felixyz
    This is a very general question but it's based on a specific problem. I've created a pdf reader app for the iPad and it works fine except for certain pdf pages which always crash the app. We now found out that the very same pages cause Safari to crash as well, so as I had started to suspect the problem is somewhere in Apple's pdf rendering code. From what I have been able to see, the crashing pages cause the rendering libraries to start allocating memory like mad until the app is killed. I have nothing else to help me pinpoint what triggers this process. It doesn't necessarily happen with the largest documents, or the ones with the most shapes. In fact, we haven't found any parameter that helps us predict which pages will crash and which not. Now we just discovered that running the pages through a consumer program that lets you merge docs gets rid of the problem, but I haven't been able to detect which attribute or element it is that is the key. Changing documents by hand is also not an option for us in the long run. We need to run an automated process on our server. I'm hoping someone with deeper knowledge about the pdf file format would be able to point me in a reasonable direction to look for document features that could cause this kind of behavior. All I've found so far is something about JBIG2 images, and I don't think we have any of those.

    Read the article

1