Hello, I've been working with BT 2.0, and studying iPhone programming over the last couple of months. I am not a programmer, but I'm starting to understand some things. The PDF screen allows you to show a button where you can e-mail the PDF. I am thrilled about this feature. However, when I tested it, the PDF has this really long filename (instead of the original filename). I'd like to change the code so that the filename in the e-mail is the same as the original filename. I found BT_screen_pdfDoc.m in my Xcode project, and a setSaveAsFileName (method?) that sets the name, and takes in screenData and itemId as (parameters?). I changed that to a simple "document.pdf" string as a test, and the results were, well, interesting. I changed it back. Later in the code, I read in the comments (thanks for the great code comments!) that BT_viewControllerManager handles sending the e-mail, so I hopped over there. I think I found the spot where the attachment is put onto the e-mail and the filename is "attachmentName", so I changed that to "document.pdf", and that seemed to be a step in the right direction; it's not the actual filename, but I like that better than the itemID plus "_screendata.pdf", (which just looks a little weird to a customer). I thought to write maybe a For loop that would create a string from the characters between the "." and the last "/" in the dataURL (or maybe there's a method in NSString that does that?), but my issue now is it doesn't seem like I can use the dataURL in BT_viewControllerManager.m, because it's not a variable in that file. Creating these variables (if that's even the right thing to do) feels beyond me, because it involves BT_item.m (I think), and now we're talking about multiple files. Plus I don't know if the tiny change I made will have an effect on some other parts of the app I'm too naive to see. Sorry for the long post, but I wanted anyone who could possibly help to know what I've tried so far. Again, I've been reading programming tutorials in my spare time since December 2012, so only parts of the code make sense to me right now. I'm beginning to understand classes and objects, but I don't know what JSON is (yet). Any tips/thoughts or general suggestions as to how I might proceed, I'd be excited to try.

I know this sounds mad but write your own code, We have had issues emailing sharing urls. It's hard to explain but I'll try and knock you up the code.

JSON = Java Script Object Notation. - Sounds impressive, but it's just another way of formatting data... not quite a 'dictionary' but it uses dictionary pair kind of way of grouping values... Strings are handled... different in iOS than in other languages I've been accustomed to. In Java (Android) most of the time you just need to use a '+' symbol... mystring = "buzz"; myotherstring = "touch"; myfavoritepackage = mystring + myotherstring; in iOS you have to use the "stringByAppendingString" function... NSString *myfavoritepackage = [myString stringByAppendingString:myotherstring]; In the plugin that I'm finishing up I give the user the choice of SMS or Email for some data, but no attachments. However, in the class I stole from (MGMailComposeViewController) I 'could' have used an attachment, I just had no need for it. It might take a bit of thinking, but if you look at 'BT_viewControllerManager.m' around line 859 or so (continuing until line 927), just after the function 'sendEmailWithScreenData' you'll see a 'mailClass' being declared that utilizes all the functions you'll want to borrow. In my plugin, I just copied and pasted the entire mailClass into my own procedure, and cut out the bits I didn't need. That might be a way to start... in any event a way to further understand... And let me know if I didn't explain it right or well enough or whatever, but I do hope it helps! Cheers! -- Smug

And just as a 'by the way'... There are millions of tutorials out there, but the ones I have found the most 'real world application' ready is either by Ray Wenderlich (iOS) or Mook Yong (Android) http://www.raywenderlich.com http://www.mkyong.com/ In addition to the great support here on the forums and GoNorthWest's BT Tutorials, these two guys are my heroes. Cheers! -- Smug

Wow - thanks for the quick and great responses! Like the code I am reading, I understand about a third of what you said, but I'm going to keep experimenting and see where it goes. I'll post back after I've made some progress. Also thanks for the tutorial suggestions - it's good to know I picked at least one good source, as I'm currently reading Ray Wenderlich's tutorials on iPhone programming. Another great site I've been spending a lot of time on is www.codeacademy.com. It's what they call a MOOC (massive open online course) to learn things like html, css, javascript, python, and a few other things. The learning design is excellent and has helped tremendously for fundamentals. I recommend to anyone who's ever said "nah, coding isn't for me"; you'd be surprised how far you get. Thanks again!

Peter is the pdf in the package or is it coming from an URL

The PDF is coming from a URL, something like: http://buzztouch.com/Apps/petersApp/104442_AD200.pdf I think that URL is held in something called "dataURL" (according to the JSON reference data when I save the file in the BT control panel). I also think the code that sets the filename in BT_viewControllerManager.m is part of sendEmailWithAttachmentFromScreenData (thanks Smug!), and looks like this: [picker addAttachmentData:theAttachmentData mimetype:@"application/octet-stream" fileName:attachmentName] so I was thinking if I could access that "dataURL" from the BT_viewControllerManager.m file, I could extract just the filename from that URL and set that to be the fileName instead of "attachmentName". Where I'm stuck is I can't seem to access "dataURL" from that file; I get itemNickname, itemID, and itemType. Again, I'm naive and this is literally my first time editing iOS code in an app that matters. It seems like a good approach because all docs in my app (not just PDFs) would have URLs, which means any type of document could have a more user-friendly name when it's e-mailed.

Would you like a hack. If ALL your apps are going to be urls lets use the the File Name in Project section in your control panel to control what you want your PDF to be named. To do this comment out line 66 so it looks like this //self.localFileName = [BT_strings getJsonPropertyValue:self.screenData.jsonVars:@"localFileName":@""]; then cnage line 80 from this [self setSaveAsFileName:[NSString stringWithFormat:@"%@_screenData.pdf", [screenData itemId]]]; to this [self setSaveAsFileName:[BT_strings getJsonPropertyValue:self.screenData.jsonVars:@"localFileName":@""]]; The first change stops the plugin for asking for the local file The second change tells the line to set the pdf file name as the local one in the control panel. remember to add .pdf

I know it's a hack but as you have noticed the other classes intertwine making it difficult to amend the string.

Have you tried the amendments, I've tested it a few times it works

Brilliant! It works very well - thank you so much for your help. I understand your description of the code changes, but I don't fully understand how it works. When I first made the change and recompiled, the PDF view screen was actually blank. I thought it wasn't going to work. Then I saw that we're using localFileName, and I didn't have a value for the File Name in on the BT control panel. I put in the name, and now it works perfectly. As near as I can tell, it seems to use the localFileName for just the filename, and still uses the URL to get the actual file, so it seems safe as long as I be sure to have a value for filename in the BT control panel. I don't quite get why the screen is blank if there's nothing in the Filename field in the control panel - I thought it would load but then the e-mail wouldn't work. Either way, it seems to work and the app is still stable, so seems like a safe modification. You call it a "hack" - is there a code stability implication there? Is it a hack in the sense that it's just a quick way to get the job done, or a hack in the sense that there may be other unintended side effects? Again, thanks very much for your help, you went above and beyond!

No when i said hack, I meant we're cutting and adding stuff out of the default code. You already noticed that when you used an url it defaults to the app identifier and screen data. because the pdf name is passed through a few classes it is too difficult to follow or ammend them. The reason it was blank was because the control panel I thought you may aswell assign your own pdf name. As you see it works, and the code is stable, just make sure you add the local name in the control panel. Also the downloader is used for so many different screens it's probably not best to mess with them. if we would have done it that way it may have had side effects. I'm glad it works

Not sure if I should start another thread because I have a small issue with the Android version of my app now. I think the root cause is that for "document location" in the BT Control Panel for the PDF, I have a value in both "File Name in Project" (to set the filename) and "Load from this URL" (to get the actual file). In the Android version, when the user taps Open With and picks a PDF viewing app, a prompt appears "document is empty". If the user taps "refresh from URL" prior to tapping Open With, the document opens fine. I suspected this may be because there's a value in "File Name in Project", and since there's no file in the project, the app thinks it's empty. I'm tempted to look in the code to see if there is a way to sort of force the app to always look for the URL, but I'm not sure how to do it. Thoughts?

yeah that is what it is with our work around, we didn't think about the android version, you cant try and figure out how to make the same changes to android I'm guessing it's pretty similar. You could change this line we made in ios earlier [self setSaveAsFileName:[BT_strings getJsonPropertyValue:self.screenData.jsonVars:@"localFileName":@""]]; to [self setSaveAsFileName:[BT_strings getJsonPropertyValue:self.screenData.jsonVars:@"itemNickname":@""]]; you would then make the screen's nickname myfile.pdf in the control panel so it will free up the local file. The nickname doesn't have to be seen so that shouldn't be an issue. If you were self hosted could have made you a new screen does that make sense, two options to choose

Thanks for the response Kittsy...I understand the two choices. The easiest one is probably to use itemNickname in the iOS code. This just creates some extra work for me, because I've used the itemNickname for every screen in this brilliant naming convention to help me quickly find any screen in the BT control panel. The names of my PDFs are mostly part numbers, so finding a screen when I need to will be a challenge, but I guess that's better than having a frustrated user. I'm still studying over the Android code to see if there is a way to resolve it there, but it's more likely I'll be using the itemNickname in the iOS code in order to get both platforms to work. Thanks again for your help, and if you or anyone can think of an Android hack, I'm all ears!

I'm sure it's pretty much identical but uses java versions. I don't have eclipse working so unfortunately I cant even test it.

Just a quick update - I found a different way that I think I'll go with. I set the doc behavior from the BT control panel to "Force Refresh". This disables the Open With button until the user hits "Download Document". Once they do that, they can Open With and it works fine. The great thing is that it's intuitive to the user - they can only hit one button, and once they do that they can view the PDF. I'm not proud that I added a tap to my Android users' navigation, but it works. I still plan on trying to get the refresh to happen automatically in the Android code.

Hello, I just created a new app, with lots more PDFs. I downloaded the source code for iOS, and expected to have to make this change again (the hack referenced above) so my PDFs would have the correct name when e-mailed. When I made the change, iOS had a minor compile error, and the app would crash anytime I tried to load a PDF. I undid the code change, and to my surprise, the app now shows the correct filename when it is e-mailed! To say again: with the original downloaded code, the filename is now maintained when e-mailed. Has some change been made to the source code generated by Buzztouch? Am I going crazy? I'm pleased that it seems to work great with no change to the code, but I'm nervous that I'm not remembering something right...

Happy days maybe this post was spotted by David