I'm trying to get my arms and mostly my mind around the extent of use the plugins will play in the future. Bare with me on this.... If I was to take an existing plugin. Modify for my use by adding very specific code in both Apple and Android then deploy it for my own use. Is that a way to manage source code changes in the long run. Later I need to come back and make a change I can then change the plugin instead of going to the generated source code to make the changes!! that right...

Hi gbakakos, Your (any) plugin will be written in Objective-C and/or Java. That code will need to be modified if you want to make a change to the behavior of a plugin. Say for example a plugin is designed (through code) to allow a user to select between a green or a red background. If the screen was set to red and the user wanted a green background the user would probably just use the plugins control panel page to change the setting. If however the user wanted a blue background, the code itself would have to be modified, and then the user could select from green, red, or blue backgrounds. Part of the idea for plugins is that we want to make it easier for people like yourself to experiment and learn. With a single plugin to work on, this whole learning process becomes a lot more manageable. I hope that answers your question. If not, please ask some more questions.

I beleive you answered my question. Great way of handling it... Thanks

Another way to look at it: For sure re-puposing code is one of the main ideas. If you use the same types of screens (custom or not) in several different apps you should'nt have to recreate them each time. Think of it this way. There are some screens that are literally the same in every app you use. In these cases the /index.php page used to manipulate the plugins behavior in the control panel would do almost nothing. All it would have would be a nickname and background setting. Every app you added this plugin to would behave exactly the same way. Two scenarios... a) A plugin that has no adjustments in the control panel. A custom splash screens might be a good example of this. You could create a splash screen plugin that showed your companies graphic and some other info everytime it loaded and there would be no need to have image settings or animation settings or any other settings in the contorl panel. The conrol panel would just explain what the plugin did but would not allow any modification. Again, every app that used this plugin would work the same way. b) A plugin that has sophisticated options. An example of this might be a plugin that showed a weather report for certain location. In this case, the screen in the app will need to know what location to show the weather and it may be different in one app vs another app. So, because of this, the /index.php page would have an option like: 'Weather City' and or 'Allow User to change city' . The Objective C and .java would understand these options that were setup in the control panel. In these cases the plugins act almost the same way but with minor differences. This his how the screen-types you see today are setup, almost the same but adjustable on a screen-by-screen basis. This is how most plugins will end up working and it will be up to the plugin creator to decide what's adjustable and what's not. Lastly, and the coolest part, a button that says 'duplicate this plugin' or 'create a new plugin based on this plugin' is coming soon. The idea here is simple. You want to make a new screen type thats almost like an existing screen type. All the plugins (regardless of who made them) can be duplicated with this button. click the button, re-name the plugin, and you quickly and easily have an entirely new plugin thats useable in all your apps that behaves like the one you copied. It's logical that you would then tweak this newly created plugin to do whatever it is that the original one didn't ;-)