Data Aquarium Framework

Data Aquarium Framework
Thursday, June 24, 2021PrintSubscribe
Responsive Width of Grid Columns

The new exciting feature of Touch UI is the ability to express the width of the responsive grid columns in pixels. The new tag column-width-(tn|xxs|xs|sm|md\lg\xl|xxl)_NNN makes it possible to provide the multiple values for the grid column width that will be applied conditionally in the visual containers of the specific size. We have developed this new mechanism for grid column sizing while working on the Live Designer for applications built with Code On Time. 

The Sizing Problem

HTML tables are commonly used to present data in the grid format. The browsers will automatically evaluate the text in the table cells and set the width of each table column for the best fit. This works great for the standalone tables with the known number of rows. 

If your grids are designed for infinite scrolling or consistent paging of a large number of rows, then a different mechanism must be put in place. Only the small subset of rows is rendered initially and therefore it is not possible to figure the best column width based on the text in the cells of the leading rows. Touch UI framework takes advantage of the Columns property of the data fields in the Grid views. Column values of the fields in the data controller views are derived from the size of the database table columns. The framework figures the total width of the columns by iterating through the visible data fields in the view. This allows us to determine the relative width of each individual column in the grid. Next the framework calculates the width of the grid column in pixels by multiplying the physical width of the visual container by the relative width of the column. The framework also applies constraints to ensure that the columns are never too narrow and remain usable.

The screenshot demonstrates the grid of orders and the selected order in the reading pane wizard form. The latter shows the grid of the order details.

The framework has calculated the width of individual columns to provide the best fit for the data. Scrolling, filtering, and sorting will not change the column width in both grids to ensure a consistent presentation. 

Developers can increase the value of the Columns property of individual data fields to provide them with the larger possible real estate. Unfortunately it makes it difficult to achieve the desired width without much trial and error.

The Sizing Solution

The app in the screenshot above is running in the live preview mode and matches the size of the iPad Pro. The framework has assigned the logical width md (medium) to the master list and xs (extra small) to the reading pane.

The individual logical width abbreviations supported in Touch UI are matched with the physical width of the visual containers as follows:

tn0 - 319
xxs320 - 479
xs480 - 575
sm576 - 767
md768 - 991
xxl1366 - . . .

The second column in the master grid of Orders is Customer Company Name. It represents the alias of the CustomerID. Add explicitly the “alias” data field to grid1 and tag it as 

column-width-tn-200 column-width-md-400

This will instruct the framework to set the column width to be 200 pixels if the visual container of the grid is at least tn (tiny). The “tiny” range starts from 0 and therefore the first tag will set the width of Customer Company Name to be always equal to 200 pixels. The second tag instructs the framework to set the width of the grid column to 400 pixels in the visual containers that are at least 768 pixels wide.

This is the effect of the tags on the presentation. The customer name is now 400 pixels wide since the visual container size is md.

Tap the hamburger menu in the top left corner to expand the sidebar. The visual container of the master grid will reduce to sm (small) size. This will also reduce the width of the Customer Company Name to 200 pixels.

Apply the tag column-width-tn-NNN to each data field in the grid to set the pixel-perfect presentation whatever the size of the visual container. 

You can selectively apply the tag to the specific columns to ensure the predictability and responsiveness of the presentation. The “fit to width'' mechanism of Touch UI will take care of the remaining columns in the grid. Alternatively apply the column-width- tag to every data field in the grid1 view of the data controller to override the grid column width decisions made by the framework.

Visual Designer and Grids

End users can resize the grid columns by dragging the divider in the grid header. The new width is memorized in the user storage of the browser

Dragging of the grid columns in the “preview” mode by the developer will cause the data fields to be automatically tagged accordingly with the column-width-tn- tags and will make it simple the task of grid configuration. The designer will automatically add the “aliased” fields of the lookup data fields to the grid views when the “alias” column is resized. 

Sunday, June 20, 2021PrintSubscribe
Drawing Pad

Taking photos in business apps often requires the visual annotation of the image. Another common scenario is sketching on the pre-defined template. Touch UI provides a built-in drawing pad that works seamlessly with the BLOB fields of your app. The feature is enabled by default and can be activated with a tap on the “Draw” button.

The drawing pad will be immediately displayed in fullscreen mode in response to the tap. It offers several tools: pen, highlighter, blur, and eraser with multiple levels of undo and redo. You can draw with a finger or a stylus compatible with the touch-screen device. Mouse pointers will also work. 

The “pen” and “highlighter” will impact the image as one would expect. The “blur” tool will blur the image contents. The “eraser” will remove the effect of the other tools.

Developers can handle the event triggered on the document and override the available tools and their properties such as the width of the stroke and the color choices. The toolbox property of the event provides access to the default tool configuration.

The drawing is composed of multiple layers. Saving of the drawing will compose the final image that will be submitted to the server when the data record is saved. The end user can perform multiple sessions of drawing prior to the submission since the layers remain preserved until the record has been saved.

Sketching on the template will require a default image to be provided. Create a custom script to handle the event. The field property will indicate the name of the blob field that does not have a value. If e.blob.url or e.blob.icon properties are assigned in the event handler, then the corresponding image will be downloaded or a material icon will be drawn.

For example, the following handler will cause the framework to create a blue material icon for the category picture in the application.

The default image based on an icon may serve as a blob stub whenever the optional image is required. The end user may tap on the image and have it replaced with their by either taking a photo on the device or choosing a previously created image.

Tapping on the default blob image will always activate the drawing pad if the BLOB data field is tagged as image-user-defined-none. The end user will not be able to replace the template image.

The end users may take real-world photos and provide the visual comments with the drawing pad tools. Keep in mind that the huge photographs taken by modern day cameras will likely be redundant for business purposes. Make sure to specify the image-size-WxH tag to engage the image preprocessor to enforce the pre-defined image photo size and graphical annotations. 

Drawing pad provides a powerful tool for the line-of-business apps. Naturally it may not always be desirable to allow image alteration. Tag the blob data field as image-editor-none to disable the drawing pad.

By default the blob images are rendered as thumbnails. Tag the data fields as image-original-always if the original image must be displayed both when the users are viewing and editing the data. The field with the tag image-original-editing will show the original image if the blob is presented in the “edit” mode. End users may still download the original image when viewing the record.

The drawing pad will work on the small devices, tablets, and huge desktop monitors.
Saturday, April 17, 2021PrintSubscribe
Image Preprocessing

The primary focus of every mobile device maker is to deliver a camera that beats the competition. Year after year the consumers are getting better photos with an unbelievable level of detail. Large high resolution images have huge implications for the business app developers since the files need to be transmitted, stored, and processed at an increasing cost and often without a significant benefit. 

Touch UI introduces a simple and powerful set of image preprocessing capabilities that help enforce the image size, format, and compression quality for any BLOB field. The processing is performed entirely on the client and works both in online and offline modes.

Image Size

Apply the tag image-size-WxH to a blob field in a view to ensure that the submitted images will have a fixed size. For example, entering image-size-640x480 in the tag property of a BLOB field in the data controller views createForm1 and editForm1 will ensure 640x480 images. Also only the image files will be accepted and any other types of files will be rejected. 

Mobile browsers and web views provide an option to take a photo with the camera. Photos taken with the device camera will also undergo the pre-processing if the image-size-WxH tag is specified.

The original 4032 x 3024 image in the screenshot below was taken with the Pixel 4XL and occupies 3.43MB of storage. The preprocessing has reduced the image to 640 x 480 pixels and will require 768 KB on the hard drive.

Fit vs Cover

If the large image does not perfectly scale down to the specified size, then the image will be reduced to fit in the specified boundaries with the horizontal or vertical bars (gaps) around it. Developers can change the default image background color from white to yellow by tagging the blob field as image-background-yellow.

Use image-background-transparent tag to have the transparent bars instead. The standard color names 
and the hexadecimal values are allowed when specifying the background.

Tag image-large-cover will prompt the framework to scale the large image down to cover the entire area without gaps.

If the smaller image is provided, then it will be centered on a solid background.

Clipping Large Images

A large image can be reduced to the requested size without the “filler” bars. Tag the blob field as image-large-clip to ensure that no file is larger than the specification. Large images will be reduced and clipped. The smaller images are accepted as-is by default. 

Image Quality and Format

Preprocessing will draw the original image on the DOM canvas. The default binary serialization format of the canvas is PNG with the 92% compression. The latter cannot be changed. Apply the tags image-format-jpeg and image-quality-50 to the BLOB data field and ensure the standard JPEG image format with the 50% compression. 

Rejecting Image Upload

Image size specification can also serve as a client-side image filter. Tag image-small-reject will reject any image that is smaller than the specified size. Tag image-large-reject will reject the larger images instead.

If you want to enforce a specific image size 320 x 320, then apply these tags to the BLOB field in the data controller views:

image-size-320x320 image-small-reject image-large-reject.

The following combination of tags will ensure that all images are uniformly confirming to a particular size requirement and do not have the gaps:

image-size-640x480 image-large-cover image-small-reject