This may be a dumb question, but I am curious to hear what you think some of the key benefits are for developing classes with WebSDK versus creating similar functionality via WebContainerControls. (Really wanting to assess the benefits of investing my time in coming up to speed on the WedSDK and all that it entails)
Thoughts?
You can put more logic on the client side with an SDK control, which should typically result in less back and forth between client and server, and thus less stress on bandwidth and server processing per instance. The downside is that you have to program that control in JavaScript and munge the JavaScript into your Xojo app somehow. Also, you don’t get the benefit of a useful control preview in the design editor.
With Containers, you can design things in the IDE and write code in Xojo. Downside is typically more back and forth between client and server.
I’m a “spiral model” guy, and I push optimizations as far off as feasible because they tend to be the most costly parts of design and implementation. So I’d typically make it work with a Container, and if it turns out to be a real drag or I think I can get good bang for the buck optimizing, I’d write an SDK control.
The original goal for the WebSDK was to allow our customers to create wrappers for other libraries and evolved into something that could create controls from scratch. Brad is correct in that the main strength is that you can keep a lot of logic on the client side and only transmit to the server when necessary, but the WebSDK also gives you the power to explore technologies that are not build into the framework. For instance, many of the latest browsers support audio recording as part of html5. You could create a. Control with the WebSDK to do that, but it’d be rather difficult to get enough performance with a container control.
If you’ll tell us what type of control you’re after, maybe we can give you better guidance.
Thanks Brad and Greg -
Very useful perspectives.
Where the notion comes to mind most often is around weblistboxes or webtextareas. These are still pretty limited for the functionality I would like to offer my users. I expect these will evolve over time, but I can probably? evolve my own more quickly. But it would be an investment of time - that is also very limited.
Enabling icons or ‘stacked’ cells for weblistboxes, and word-level font/font-style/font-size adjustments in webtextareas are some of the specifics that I am thinking about.
You could use either to create that type of functionality, but my instinct is that the more complicated your control becomes, the more likely it will be that you’ll want to use the WebSDK. It gives you a lot more control over the outcome.
Here’s the thing though… if you want to build large, complicated controls, you absolutely must know HTML, CSS and Javascript to be successful with the WebSDK.
Also, I did a 3 part series about building an iOS style table-view control using the WebSDK back in April. If you’d like to get a feel for the process of designing a control for the WebSDK, take 30 minutes, read and follow along in Xojo.
http://www.xojo.com/blog/en/2014/04/iostableview-web-control.php
How would I approach word-level formatting in a container control - let’s say for a paragraph of 100 words. Best I come up with is each word is its own weblabel. Having so many controls, doesn’t sound like best practices to me, but I would love to be convinced otherwise.
I have already done some really good functioning webcontainer based list boxes, but I always felt (1) no matter how efficient I made the icons, it burdened performance too much, and (2) it was really hard to emulate the “multi-line” capability of the built-in weblistbox.
I am always looking for ideas and tips in all of these areas and more.
[quote=113203:@Greg O’Lone]Also, I did a 3 part series about building an iOS style table-view control using the WebSDK back in April. If you’d like to get a feel for the process of designing a control for the WebSDK, take 30 minutes, read and follow along in Xojo.
http://www.xojo.com/blog/en/2014/04/iostableview-web-control.php[/quote]
Thanks - I will definitely take a look at that.
I wanted to thank you for introducing me to the “spiral model”. Not sure how I missed that in my education (granted that was a long time ago) and my readings over the years.
I am precisely in the middle of an ongoing series of experimentations to try and expand the current WebListBox limitations. There are only so much once can do with current tools provided by Xojo. Recently, I researched three features I could not do with the regular Xojo WE :
These are available in JavaScript and I was able to implement them, but I was limited by the ways to getback the values into Xojo. So far all I had found was to set the HashTag which triggers Session.HashTagChanged. A bit hackish, and seen by the user on the URL line.
Yesterday, following Greg advice, I started working on WebSDK and by simply following the accompanying PDF, I was able in an hour or so to get the values through a WebControlWrapper, so now I can communicate silently back and forth between the JavaScript and the app. And probably much faster as well.
I have reported that in https://forum.xojo.com/14037-webcontrolsdk-controlid
That was easy. Creating more elaborate controls will probably require a lot more work. But one may not have to reinvent the wheel. WebSDK controls and WebContainers may not be mutually exclusive. By combining them, it is probably possible to get amazing results.
You wouldn’t. What you’d probably want to do is something similar to the HTMLArea example control in the WebSDK where you feed it raw HTML (or HTML & CSS) for formatting purposes.
Ah! You’re beginning to see that it’s not one of those “this should be easy for you to fix” kind of control 
The real performance hit for icons in a WebListBox comes from each image being a separate download. The browser has to negotiate a new connection each time and that’s extremely time consuming. The way the rest of the world does this is to combine all of the icons into a single image using a grid and then use CSS to position the image so that only the icon you want shows through. The image is bigger, but the removal of the extra connection beats it every time when all of the images are the same size.
[quote=113204:@Mark Pastor]I have already done some really good functioning webcontainer based list boxes, but I always felt (1) no matter how efficient I made the icons, it burdened performance too much, and (2) it was really hard to emulate the “multi-line” capability of the built-in weblistbox.
I am always looking for ideas and tips in all of these areas and more.[/quote]
If the icons you’re using on your custom listbox are the same across many rows, you only have a few defined and they are not a graphic generated depending on data in the row, a way round the problem of downloading the same icon many times is to define WebPictures on the App and reference them from there.
This way the listbox gets the same URL for the same icon wherever it’s used, and only downloads it once to a browser as the browser will cache the picture and re-use it when the same URL is referenced.
Made a massive difference to some stuff I was doing with a custom listbox like control.
Great input!
Now that, I never thought of. Very interesting.
I heard similar advice not too long ago - I haven’t had the chance to try this out yet. I assume this is similar to the advice provided to be earlier suggesting I store images in properties? Is there a difference (aside from retrieving/generating the initial instance)?
At its simplest, yes, just a bunch of WebPicture properties defined on App that you populate (usually on App.Open).
So if for example you had images in your project such as addicon, backarrowicon and cancelicon…
// Initialize images that we want browsers to cache.
me.addIcon = addicon
me.backArrowIcon = backarrowicon
me.cancelIcon = cancelicon
Now instead of using addicon you would use App.addIcon to get the one and only instance of that WebPicture and your browser will not ask for it more than once.
Very clear - thanks.