How do I add a plugin directly to the Project? I'm using x's Control Panel and they don't offer y plugin. Also I have a form built in Xcode (basically a .h and a .m file) can I add it to a Buzztouch app? Or, Also I have a form built in Eclipse (basically a .XML and .Java file) can I add it to a Buzztouch app? What you're really asking is, "What does a Plugin do? And would a "Custom Plugin" plugin make this much easier. " A plugin does 3 main things: a. Add files to the Project (Source Code) b. Add date in JSON format to the Config file. c. Provide an interface on the Control Panel to accomplish a & b. So, how do you accomplish same without the Plugin? a. Just add the files directly to the Source Code. b. (Option 1): If you wish to follow the Buzztouch Framework and have the screens created dynamically then you'll need to create a set of files that use data in JSON format. See any Plugin for an example. I recommend you take a look at the PDF plugin since it allows both embedded files and via URL. But you really need to take a look at the type of plugin similar to the type your wishing to add to the project. (Option 2): You could use code that doesn't create screens dynamically. In this case ? c. So, by bypassing the Control Panel you encounter a problem. How to add the screen data to the Config file. (Option i): Access the database on the server directly. Problem: You may not have permission to do so? 2nd Problem: New skill, hence learning curve. (Option ii): Modify the Project's Config file. Problem: Now the Project_Config file doesn't match the Control Panel Config file. Not really a problem if your app will be a Offline app. Solution: Move the Online Config file to another location such as Dropbox, a website. (Option iii) Create the "Custom Plugin" plugin first. Yes, the Custom Plugin will allow users to add JSON data to the Control Panel Config file (the user will add the files directly to the Project), thereby allowing continued use of the Control Panel. What the Custom Plugin doesn't need: New Project files. So, @Raveyd and BT_Mods, you created several plugins already, this should be the simpler Plugin to create. Fred

Hey Fred, I'm not quite following this. At its basic, a plugin is a way to provide certain functionality to an app. It relies on underlying Java (Android) or Objective C (iOS) code to process JSON configuration data and build the required feature (generally a screen). For instance, the PDF screen plugin in iOS uses the BT_screen_pdfDoc.m and .h files to process the JSON configuration information for that screen. Without those .m and .h files as instructions on how to process the JSON and display the results, nothing would happen. So, basically, you can't have a plugin (in the current understanding of the concept) without some backend coding to be done. It sounds to me like you're proposing the ability to create a plugin without using those backend files? Just by editing the configuration file? Can you explain your thoughts a bit more? I'm interested because if there is a way to unleash plugin development from the community that doesn't require writing/modifying some code, that could be pretty powerful! Mark

Looking into this now but I also share some confusion rave. So the end product is "Option iii" right? Create a plugin from scratch that requires no files really linking towards the control panel - however can be added to the original source code. So trying to understand the end goal of this.. The goal is you using someones self hosted server, and they do not have the custom plugin you want on there. Instead of asking them to add it, which may or may not happen anytime soon - you decide to do it yourself by adding the plugin directly into your source code? The plugin would allow users to input their own json data into the config file and thus bypass the cpanel/plugin files required normally? But then how would a user update such plugin data without modifying partly the control panel data - and if you do, it would become useless, as in you would have the ability to get that plugin already into the server anyways - bypassing the need to add it externally. If you could elaborate a little more in simpler terms - my English isn't as great as it should be, but I more or less think I understand what you mean. David buzztouchmods.com

A Plugin adds the JSON data to the Config file. That allows the Config file to be hosted on the Control Panel. The JSON data that's being added is: itemId itemType navBarTitle dataURL plus any additional screen settings. From the Excel Plugin: Most folks use the control panel to configure the JSON data for this plugin but it's useful to see what it may look like. This example loads a document from a URL { "itemId":"343434", "itemType":"BT_screen_excelDoc", "navBarTitleText":"Spreadsheet", "dataURL":"http://www.mydomain.com/sample.xls" } So, when you wish to use a "new plugin" that the Administrator has not added to the Control Panel the problem is, How to add the JSON data? Adding the project files is simple, Drag & Drop. But there'a no JSON data in the Config file for the app to allow the user to access the content. If you modify the Project's Config file then you lose the ability to host the Online Config file on the Control Panel. Solution is the Custom Plugin plugin. The Custom Plugin plugin is a mechanism to add the JSON data to the Control Panel Config file allowing you to continue to use the Control Panel. It would create a new itemId You the Control Panel user would enter the itemType, which the Custom Plugin plugin would enter into the JSON data. NavBarTitle, dataURL, and other screen setting handled normally. So, if I wished to use the PDF plugin on a Control Panel that hasn't installed the Plugin you use the Custom Plugin and enter the itemType then enter the normal screen settings. Fred

But a plugin requires more than just the JSON...it requires actual code to process the JSON and draw the appropriate screen. That's what I'm not understanding about what you are proposing. You can't create a new plugin with just JSON and no code to interpret it. Now, if you're proposing using existing code, and creating new JSON defs to define a new screen...well, that might be possible. Mark

If I'm not mistaken the JSON data is what hooks the Project files to the Buzztouch app. The Project files create the screen. The Control Panel simply inserts the JSON data into the Config file. A plugin's .php adds a itemId to the JSON data. So by having the additional screen settings itemType in the Custom Plugin you can specify a type that doesn't exist on the Control Panel. If I'm missing something pray tell. Fred

@MrDavid, i feel u loud and clear! Although a newbie, I Am. I have been scratching my head wondering what to do, because someone has given me some lines of code to add directly into the BT sourcecode. I dare not. Something (maybe self preservation?) tells me its a kinda one-way street, cos afterwards, i would in my view lose the ability to continue using the control panel, and find myself marooned at sea! So, i am watching this discuss with keen interest...

I'll start by saying I don't pretend to understand all the intricacies of the buzztouch code...after all, I use buzztouch because I can't code! That being said, here's how I understand it works: 1. The app fires up and some code kicks in to start parsing the configuration file 2. When it hits part of the JSON that describes a particular screen, it then sends that info over to the related Java or Objective C code to actually render that screen. Here's an example: "itemNickname": "Dimension Chart", "itemId": "9A3A57E578AAEDECD7F14E2", "itemType": "BT_screen_webView", "localFileName": "ASA_Field_Dimension_Chart.pdf", "navBarTitleText": "Field Dimension Chart", This is to create a screen that displays a PDF file. When the configuration parser sees this information, it notes that it's a webView, and sends this section to the BT_screen_webView code (BT_screen_webView.m). That code takes all the parameters in this sections, and uses it to create the screen. In doing so, it invokes additional code as necessary. So, as I understand it, it's not enough to just create a new JSON definition for the type of screen you want, unless there is some actual code that can interpret that code and actually render the screen. Some of the current code - like BT_screen_webView.m - might be already written for that, but, depending on the plugin...new code might need to be written. I'm hoping I'm making sense here, and that we're not both talking in circles! I'd love nothing more than to see more plugins get created. But, in many cases, I think new code will have to be written, IN ADDITION to new JSON. Mark

I'm a tad bit confused by this thread, but I'll add my understanding. Its my understanding that a plugin that someone creates would have the combination index.php file to create the user input fields for the plugin's properties, and the .js files to process that input and put it in the server's database. From there, the server (whether self hosted, or BT's) processes the database to create the configuration (JSON) necessary. @Omoba, its possible to use Obj-C code in a BuzzTouch project if you do it right. You need to create a subclass of BT's view controller and use it as a custom plugin.

The solution is in the index.php file. It needs to be modified to allow the itemType to be set. (In addition the text needs to be modified to reflect the Custom Plugin). The config.text normally would provide the itemType but the Custom Plugin is not a normal Plugin. Perhaps the Launch a Native app plugin has the solution. Fred

Mark, we were typing together, so I wanted to chime back in and tell you i agree with what you understand. New code does need to be created, or existing code can be modified. And its not as hard as it might sound. That's how I'm implementing the DoubleHTML screen Tool, and the "Candy Stripe" list menu, and the soon to be released Quiz Maker tool. Now, while I'm sorta "back-dooring" the concept of a plugin, its basically the same thing. I'm just using a tool rather than a control panel based plugin.

@Fred, I believe the itemType is mostly present to setup conditions for the screen in the existing BT binary. If you are creating your own plugin, you are already defining the behavior of the variables being passed into the code.

I can concur with @Stobe on the above.

Indeed this can be a complex subject! Glad to be part of the discussion on it. I'm glad that there are some people out there who understand it enough to create new plugins! Thanks, @stobe, @MrDavid and @coderx, for the discussion contributions, and to @Fred for getting the discussion going!

Yes, thanx especially to @GNW, @Fred and @Stobe. A few things became clearer still. Launch a native app plugin has kinda ghosted away from my nearsight. I will check it out tomorrow, since i know what i want to do, and have a bit of code for it, but cant quite figure out how to put it in. I guess thats the beauty of being a newbie - blissful unawareness... :)

The question is how to enter a new itemType that's not been used before. The config.txt file in the normal plugin provides this info, but the user won't have access to the plugin's config.txt that was added to the Control Panel when the plugin is added to the Control Panel. The Custom Plugin will (?) have it's itemType. (Perhaps a var ?) This var would be set by entering the value via a screen setting in the Control Panel. Fred

I think you may be over-thinking the itemType. BuzzTouch uses it for the pre-existing code, not necessarily for a custom plugin. If I told you to go to the grocery store and buy me some cereal, you might purchase some grape nuts for me. But if I told you to go to the grocery store and buy me something for breakfast, you could choose between cereal, eggs, bagels, etc - since I didn't define for you the exact "type" of breakfast food. I hope that analogy helps (it only made me hungry for breakfast!).

Agreed. The itemType only works if there is actual code to process the variables associated with that itemType. Can't invent an itemType with no code to interpret it! Mark

So the Custom Plugin plugin will consist of the following files. icon.png (any graphic artist wannabes) index.php (This is the hard part) readme.txt (consider it done) save.js (I assume it can be copied from any existingplugin) config.txt (consider it done) screenshots (folder) (Consider it done) save_AJAX.php (same as save.js) update.txt (same as save.js) Note the "Custom Plugin" plugin doesn't need Project files as these will be added by the user. Any coders out there for modification of index.php? Note: a custom plugin is not the "Custom Plugin". The "Custom Plugin" plugin will be a custom plugin, but the eBook plugin is also a custom plugin. (Just for clarification should anyone get confused.)

Perhaps Custom Screen plugin would be better terminology. Fred

I'm following this thread and will add some detailed thoughts later. In the meantime, I think was Fred is referring to is the Custom Plugin "screen type" as seen in a v1.5 apps control panel. Choosing Custom Plugin from the drop down list (in a v1.5 app) allows exactly what he's describing. It's this feature that needs to be added as a downloadable plugin to then be added to self hosted panel. The purpose of this screen is to allow you to use an arbitrary .m and .h file, or .java file (a custom Objective C UIViewController or Android Activity) in your project without losing control in your online self hosted software. Example: a) Your buddy makes a neato calculator class, only iOS. He provides you the .h and the .m files. These files are loosely based on a previous BT plugin so they have the basic structure down. b) You drag these into your Xcode project. At this point they are in your project but you don't have anyway to connect them to the JSON data in your configuration file. c) You add a "Custom Plugin" screen type in your control panel (you can do this now in v1.5, Fred's proposing to allow this in 2.0). This step is what establishes the connection to the JSON data for that screen. You configure the JSON data for that screen manually using the screen in the self hosted panel. You provide any itemId you want. itemType is BT_screen_plugIn, classFileName (in the JSON you manually enter) is the name of the objective C class your buddy gave you. Any number of arbitrary properties can be added to the JSON as needed by the custom plugin. Example: If it's a custom class that shows a hangman game, the JSON may need a wordList. If it's a geo location reporter, it may need a showUserLocation default choice or whatever. Totally arbitrary and up to the app owner to implement. So, to make this available in 2.0 we just need a plugin that loads NO .h, .m, .java whatever. All the plugin would do would be to facilitate the online part, the php page, the icon, etc. Maybe I don't need to write more later...just wrote the explanation! LOL. Hope this helps. I've been working like a mad man trying to get more BTU content created but will look into creating this plugin before continuing the BTU stuff.

Hi David, Thanks for your input here! This, for me at least, totally clears things up...well, at least what the function of the Custom Plugin screen is. Makes sense that you need the .m and .h files as we've debated, plus having that screen to tie in the custom JSON. I'm still not entirely sure I'm clear on what Fred's original intent with the post was (perhaps it was, as you indicated, to get the Custom Plugin screen into v2), but I think it brought forth some good discussion on one of the meatier subjects at buzztouch! And for that I'm grateful! Mark

It was exactly to get the BTv1.5 Custom Plugin screen into BTv2.0. Plus, learn how to create a plugin (accomplished), plus increase ability of users to use plugins without installation of Plugin to control Panel (We now have one method and when the Custom Plugin plugin (Strongly suggest it be called Custom Screen plugin) is created we'll have two methods. But it was also to explain how to add code, Project files (.h & .m) and (.java) files, directly to the Source Code. The use of Online Config files on Dropbox and the ability of addition of project files directly to the will allow various tricks: Duplication of apps. Use of one Buzztouch app cross platform (without the moaning and groaning about how iOS is better than Android and the opposite. In the process I've learned: How to modify the index.php file, modifying the icon.png is simple modifying the readme.txt is now clear Don't need to modify save.js, save_AJAX.php save.js and update.txt (David, I assume it can be copied from any existing plugin. Correct?) config.txt (Easy to modify) modifying screenshots (folder) is simple update.txt (same as save.js) Now the hard part will be: Conceiving a useful plugin Then creating the iOS Project files Then creating the Android Project files What I'm not sure about is: itemType is BT_screen_plugIn - Apparently you can create any previously unused itemType name. But how does it connect to classFileName, and what is the Android version of "classFileName"? Fred PS I also learned that the YouTube screen is not really an additional screen. Says so in the BTv1.5 Documentation but who really reads that. So the obvious question is should I reduce the BTv1.5 screen count by one?

I think this plugin should be called "Custom View" so the word plugin isn't even part of it. Far less confusing that way. Last chance for ya'll to make the Chicago hangout....Saturday approaching fast ;-)

100% agree "Plugin" should not be part of the name, only leads to contusion. View vs. Screen As a user I would think Screen is a bit clearer. As a programer View is probably a bit more accurate. Fred