I am currently trying to transfer an app that I made for a client (local restaurant) from another app-builder (SeattleCloud) to Buzztouch. The main reason (besides learning Buzztouch) is that an HTML form in this app that allows to make reservations via email does not work reliably... and I have no idea what is going on behind the scenes. Moreover, the SeattleCloud system makes it easy to combine all sorts of screens, but it is difficult to generate a uniform look & feel across all screens of the app. So I thought Buzztouch should do better... When reading through different Forum posts on the combination of HTML/jQuery forms and Email submission it seems as if many Buzztouch members use external services like jotform or wufoo for this purpose. My questions and comments are 1) If you use such external services, is it easy to adapt the layout of these forms to other parts of your app? 2) Do you prefer to link to external URLs in this case or do you copy the HTML code to your Xcode/Eclipe protect? What are the pros and cons? 3) In general, I would like to keep the number of external URLs (besides the Buzztouch control panel) as low as possible. Jotform and Wufoo may be around for some years in the future... but who knows...? 4) So I would prefer to have some smart code in a Custom HTML page that triggers an email (e. g., via the Send Email plugin) after the user has put his data in the form fields and hits "submit". I guess that such an interaction between HTML code and the Send Email plugin would need some extra Xcode/Eclipse programming. Right? In that case it might be easier to implement these forms without HTML in pure Objective C code? Thomas

1) I would not worry too much about having the layout conform to the remainder of the screens within the app. As long as the color scheme is the same, then the User will be comfortable. Go for the "good enough" satisfaction level. 2) Linking to an external source allows you to make updates without having to re-compile and re-publish the app to the App Stores. 3) If your external Form Provider goes out of business, just switch the URL to a different service. It is a pain, yet, you will have that flexibility of making changes without having to re-compile and re-publishing the app. 4) Chris1 should be publishing his Form plugin soon, now that the Plugin Market is open for new submittals. Perhaps you can try that approach. In the meanwhile, use the external Form Providers. 5) Take a look at Email to DB as another service provider. I do not have experience with them. Another BT Member had mentioned them as part of his research. http://www.email2db.com/editions.aspx Please let us know how you get along! -- Niraj

I have in the past tried to send an email from an html page, that calls the native email app using 'mailto' in my html. In theory you should be able to add html parameters for the to address, subject and body text. However, whilst I can prove this works OK in a browser, it doesn't work if you you use the custom url plugin or custom html plugin (which you would use for the form). The email app is opened, but the parameters are not paased into the email app.

Alan just gave me an idea! Using a custom URL Scheme, one can click on an embedded HTML link that will "call" the same mobile app, pass parameters to it, which will then invoke the native email screen with all of the attached parameter information. Then the User would simply have to tap on "send" to dash-off that email to your destination. Is that scenario something you have an interest in? -- Niraj

@Niraj Thanks for your ideas. Yes, the flexibility to update an app without re-compiling or re-publishing is important. But as our Buzztouch apps can be easily updated via the control panel, this aspect alone would not be an argument for an external service. Even the SeattleCloud app-maker provides such a syncing, so I guess Buzztouch would handle the required flexibility as well. And sure, one could easily switch if one form provider goes out of business. Perhaps my concerns have something to do with my surprise about the idea to outsource the handling of forms. Over the years I have gone through so many books and courses on different programming languages. The implementation of a "model-view-controller" concept, where a controller handles the interaction between the user interface and the underlying data model is so common, that I did not expect to use an external service for such a functionality. But let's see what Chris1 has developed in his plugin. Finally, one major problem with the email form in my current (SeattleCloud) version of the app was that those emails were sent from the control panel of the app, not from the user's email account. So the user puts his email address in a specific form field that is sent to the restaurant owner, but only in the body text of the email, not in the "From:" or "Reply-To" field. Of course, this caused problems when the restaurant owner replied to the email in the standard way... and sent a response to the control panel, not to the user. I guess that the same problem might occur if you use an external service, I have to check this. Thanks again Thomas

I think that there are several options to send an email from an app. Yes, you can use a forms based approach. A simple html form can either link to a local email application on the device, or it can be entirely web hosted. My earlier post was meant to highlight that if you want to link an html form to local emailer, there are issues to overcome, although @chris1's upcoming plugin may help there. I'm looking forward to it as well! Web hosted can be a service provider, but doesn't have to be. I use Joomla and I host web forms that send emails from my own host. I think that it ultimately depends on the user experience you are looking for and bear in mind that if you are developing for apple, I believe that using native app features is usually preferred by the apple reviewers. I'm looking forward to seeing which way you go. Alan

Hi AlanMac, thanks. Your idea to use forms on your own site is very good. In this way you don´t have to rely on another party. As I use one of my own sites for redirects, this would be a similar extension. Great idea. Your point about native app features is interesting. This would also be in favor of a "keep it in the app/phone" solution. Also, not every user has internet connection all the time. Being able to write an email that waits to be sent in the Mail app may be a better user experience than not being able to access the form at all. Anyway, I will report my decision when the app is finished ;-). Thomas

Just to report back... ... last night I sent my first email from a form. Being equipped with a glass of italian wine and having J. S. Bach music in the background, I created a minimal app in the control panel with the following plugins - "send email" (I filled both emailToAddress and emailSubject fields) - "login" (to get some inspiration on how to place the form fields on the screen etc.) - "blank screen" as a starting point for my own screen with form fields. In the future I should start with a proper "empty plugin", but for now this was best to begin with. Then the solution was surprisingly simple. 1. I placed a textfield (text_test) and a submit button in the (formerly) blank screen 2. I added an new "emailID" field in the JSON data for my modified "blank screen" at the Buzztouch control panel and set the value to the itemID of the "send email" screen 3. The function to handle the button click did the following (I leave out the usual error checking here) // Get the ScreenData of the email screen screenObjectToLoad = [appDelegate.rootApp getScreenDataByItemId:emailID]; // Get the JSON data for the email screen NSDictionary *emailJSON = [screenObjectToLoad jsonVars]; // Get text from textfield and modify the emailMessage accordingly [emailJSON setValue:[NSString stringWithFormat:@"Buzztouch is awesome,\n\nMy comment: %@",[text_test text]] forKey:@"emailMessage"]; // Fire the "send email" screen [BT_viewControllerManager handleTapToLoadScreen:[self screenData] theMenuItemData:nil theScreenData:screenObjectToLoad]; Done. I was in a "flow" and enjoyed the interplay between the control panel, XCode, and the debugger very much. What a great experience. After developing with XCode for some time now, I might have developed something in my own style in a similar amount of time. However, I was amazed how easy it was to implement it with "Buzztouch tools", which is of course the best way as it gives a great opportunity to customize the user interface via the control panel. I am pretty sure that Chris1 will provide a much better plugin than my adhoc-solution. For me it was an exercise to learn developing Buzztouch plugins... and the experience was great. If I would continue and improve this first step, I would - include information on the type, description and name of the form fields in the JSON of the (formerly) blank screen - have to do some cleaning after the email is sent. So I guess it should return to the parent of the form screen if the email was sent successfully, and return to the form screen if the user noticed that he wanted to change the data - have to find out whether it was ok to use "nil" for theMenuItemData in the handleTapToLoadScreen call. Usually, you attach the "send email" screen to a menu item. But here I launch it from a button. After this worked fine (and after the glass is empty ;-) ) I am even more convinced that Buzztouch is an amazing approach than before... Thomas

Excellent results, Thomas! I expect great plugins to emerge from Würzburg in a few weeks! Please consider joining us on the BT Developer web conferences. If interested, send me or Susan Metoxen a Private Message. -- Niraj

Thanks for this encouraging response, Niraj. Susan already put me on the Wednesday conferences list and I was able to attend two of them. What really inspires me is the helpful community here. And I have the feeling that it was exactly the right time that I stumbled upon Buzztouch. Core 3.0 is out, self-hosted server and plugin creation tools are published... I hope to do just that... provide some great plugins... let´s see. Best wishes Thomas