Hello friends, I created an app with more than a hundred small pdfs (about 100k each). When I was testing the app in my iPad1 and my iPod4 the app crashes in the iPod when I clicked about 30 pdfs (the loading time gradually increase). In my iPad the pdf window open empty after some 35 clicks. I alredy created an App with 40 pdfs that worked perfectly. Some suggestions? Thanks!

This sounds like a memory leak or something to me...perhaps the app is keeping the newly opened PDF in memory and then it reaches some sort of limit after X number of files of X size are opened. One way to debug this would be to hook your device up to Xcode, and try to reproduce the problem. When the app crashes, something will get logged into the debug console of Xcode. If you can post that here, we can check it out and try to figure out what the issue is. Mark

This is an issue for David. I went round and round with an app for a big customer that did the same thing. David changed some code for me that fixed it. I can't tell you exactly what he did otherwise I'd just send you the part you need. Mark, maybe you can bug David about this. It was for my Mayo Clinic app, he'll know what it is. Tim

I'm on it!

Actually, I do have the files he sent to me that fixed it. Looks like he made changes to the appDelegate files and the BT_screenPDFDoc files. Here is the bulk of the explanation from Dave: "Explanation: The pdf screen creates a UIWebView every time it loads. This is a NEW object and iOS allocates memory for it every time this screen loads. This is normal. Deallocating, releasing, or killing this UIWebView using any published approach does NOT get rid of the memory allocated for the document or content in the UIWebView. This is widely known (as I see now in doing some research). This is a problem. There isn't anything we the developers can do about it. If you don't do any rapid tapping you could tap all day. If you do it over and over again iOS doesn't get the chance to do it's memory clean up magic on the data in the UIWebView. It's confusing I know. It's not the UIWebView itself that iOS isn't cleaning up. It's the space in memory that holds the content in the UIWebView. This is new to me and worth the BS we've been going through to understand it. Good to know! I tried all sorts of magic in the didRecieveMemoryWarning, viewDidUnload and all sorts of other methods to find and get rid of this memory. Couldn't do it. I was able to see it allocated over and over again and I was able to see the UIWebView get deallocated (released) but the iOS hangs on to the memory for the content - lame. The fix: I created a new property in the app's delegate file, it's a UIWebView and it's called pdfViewer. Cool. We create this object only ONCE. The idea is that when the pdf screen loads we check to see if we've made this in the delegate yet. If we have not, we create it. If we have, we don't re-create it, we just re-load it's content. As it turns out, re-loading the content DOES force iOS to free up the memory it was previously using for the previous content and re-allocate as needed for the new content. Go figure. " So I have to .h and two .m files but the appDelegate files have my app name stuck to the front, not sure if they'd be of use. Mark, can we use these to fix @cajujoe's problem? Tim

I think we can...looks to be the same issue. Trying to verify with David, but I'd say go ahead and hook him up. Mark

@cajujoe As you've read above I've had the same problem. I have the fix for it and willing to send you the files. There will need to be some find/replace done on them at a minimum to replace any instance of my app name with yours. Can you handle that in Xcode? Mark, any reason you can see that doing a find replace on all 4 files wouldn't work? Last thing I want to do is get him more jacked up. Tim

I think that should work. I'd suggest making copies of the files he changes first, just so he has something to back up to if problems occur. The other idea would be to scan the file for differences (if there aren't a ton), and just make the changes in his files. David is going to post later, but this seems like the same issue, so I think the fix should work the same. Mark

Mark, you're the guru. How should we proceed? I can send you the files if you would be the mediator, or if you want to see what was changed before we hack up joe's. I'm not sure I could walk him through the scan for differences. Tim

Hello Mark and Tim. Thank you very much. I could handle the x-code and see if the problem disappear. No problem if doesn't work. It's worth the try, and if anything bad happens I redownload the source.

Send it on over to cajujoe, and let's see what happens! He seems open to experimenting. @cajujoe : If you need any help, just shout! MrkFleming at gmail dot com Thanks, Tim! Mark

Ok joe. Give me an email to send the files. As Mark said, make copies of the files before you change anything so worst-case you can end up back where you are right now. You will be changing the appDelegate so... make copies. You can PM me the email if you'd like or I can put the files on dropbox. Tim

Mark and cajujoe, I sent the files to both of you by email. Good luck! Tim

Tim and Mark, The new files solved the problem! I opened more than 100 pdfs and no crashes! Thanks very much. For future reference, I just changed the delegate names (Tim app name with my app name) in the body of the 4 files. Thanks!!

Well, I was so happy that I double posted. :)

Outstanding! Thanks, Tim, for coming to the rescue. I'm sure David has this on his long list of things to make official in the code. Mark

Just getting to this. But, it sounds like you all' figured it out - awesome. Between Tim, Mark, Xcode and Snoopy, anything's possible! Well done gang.

No, thank you Dave! Tim

Any chance I could get a look at those files? I'd love to remedy this issue myself.

I'll send it after I get done hitting this little white ball about 85 times

Thanks I def appreciate it :) No hurry if you want to hang out in the clubhouse and enjoy after hopefully a good round. Tomorrow, later this week, whenever, etc... just would like to have this fix - I've run into the problem too and had no clue it was something David has fixed. Glad the OP posted it and even better you guys responded with a fix. Thanks!

92 times. Stupid F***ing game! Sent the files to your email ATrain. Tim

Many thanks! Hopefully this is fixed in some update. I'm planning to build some PDF catalogs and this would have been a killer issue.

Dear friends. I'm programming a new app, and maybe because of some buzztouch plugin changes the fix don't work anymore, and after some 30 clicks the app crashes. Some suggestions? Thanks!

David Did you make the changes to the appDelegate files to help run multiple PDF files. I'm having the same problem, after about 22 files it starts downloading slower then at around 35 files it crashes. If you made the changes, should I just redownload my source code? If you haven't made them could I try the code that cajujoe used. It sounds like the same issue I'm having unless as he recently posted there has been another plugin change. Thanks for your help with this, I'm ready to publish but need to fix this before I do. It probably wont make a huge difference when someone is using the app regularly but I'm pretty sure when apple goes to test it before publishing it will crash on them because there are quite a few files for them to go through. Any help would be great! I'm pretty good with making changes in xcode if I know what I'm looking for, so if you just have lines of code for me to search and change I'm good. If I have to come up with my own code...not so good. Thanks!

Techie, PM me your email. I'll send the files to you in the morning. Tim

thanks WolfTim

Got it. You might want to delete your email from that last post unless you like all sorts of less than interesting spam by the boat load. Tim

Thank you WolfTim the fix worked so that I can open about twice as many files before the app crashes. It would be great if there was a full fix soon. Amie

I'm creating my first iOS app on Buzztouch Self Host 2.1.9 (all plugins are updated) and Xcode 5. My app contains multiple pdf files which are causing it to crash after about 20 screens are opened and closed in quick succession. If I close the app from running in the background on ipad (tried it on 2 different ipads) and re-open app everything runs smoothly again for next 10-20 screens and then either doesn't load the pdf properly or crashes app so it sounds like the memory issue Cajujoe was experiencing in previous posts. I am ready for publishing to app store but have to fix this first. If someone can help me by sending the files Cajujoe used or give me some other advice I would really appreciate it.

PM me with your email and I'll send them over. Tim

Thanks Tim I've sent you a pm now. It's my first time posting on the forum so also created a new topic after I commented on this post because I wasn't sure how commenting on old posts worked but now I know :) Thanks for your help I really appreciate it. Sherry

This is why I LOVE BT because of the awesome people who make this possible as well as help each other along the way. WHOOOO HOOOO it's working got to over 150 pdf files opened and closed and stopped counting because there were no crashes what so ever. You guys ROCK!!

Awesome. Tim

So this is still an issue with the new BT 3.0 core, opening lots of PDF files in succession still can crash an app? Interesting that since we can use ARC now this is still happening. Kinda curious to test this out now in a new 3.0 app and revist that code fix. Thanks again to the Wolf for sharing it! I've been tinkering with this VFR code for a project, works and looks a lot like iBooks. https://github.com/vfr/Reader

Hi ATRAIN53 I'm still using BT 2.1.9 for this project so not sure if it's still a problem in BT 3 but sure it isn't. Sherry