In this section, you'll finish up the Vehicle Inspection form, adding the finishing touches to your creation.
Rest assured, there'll be a lot of new controls for you to sink your teeth into. The intriguing problem though is that according to the Rocky Jupiter specs for the Vehicle Inspection form, it should feature an automatically updating running total of how many car parts the driver has found to be operational, and how many are malfunctioning.
To pull this off, you'll have to insert some sort of counter into the
repeater that generates the segmentedbutton
controls, that keeps track of how the user input in them. Instead of just summing
the counters and displaying a total, you'll use a barview control
to display the values; an exciting proposition in itself, you'll agree.
Keep count of and display user input in your form
As you might have expected, the Mobilengine form language is versatile enough to let
you declare and define variables, with the let
element. In exchange for a few house-keeping considerations to keep in mind,
lets help you keep track of values and input generated in your
form.
A let is only valid inside a declarations trait parent (just like a validator needs to live inside a validation trait), which in turn needs to be the very first
child of its parent.
The let itself has three required attributes: the
id you'll use to refer to the value it holds, the
shape to set whether its scalar or not, and the
value, the actual meat of the variable: a data-binding
expression that returns the value you want stored.
Go ahead and try your hand at declaring a counter that holds the number of Operational and Malfunctioning selection the user makes:
<form id='vehicleInspection'...>
...
<table id="vehicleTable"...>
...
</table>
<textview label="Indicate if the element is not in order"/>
<repeater id="popupGenerator"...>
<popup ...>
<repeater id='partsList'...>
<declarations>
<let id="yesCount"
shape="scalar"
value='{SELECT COUNT(*)
FROM rows r
WHERE r.yesNo.selectedKey="Operational"}'/>
<let id="noCount"
shape="scalar"
value='{SELECT COUNT(*)
FROM rows r
WHERE r.yesNo.selectedKey="Malfunctioning"}'/>
</declarations>
...
</repeater>
...
</popup>
</repeater>
</form>
The
thing to keep in mind when putting a let inside
tables and repeaters is that
declarations isn't part of the parent's template, and so the record property isn't in scope. Not
that you need record right now: you don't want to reference the
template, but the final repeater. This is why the query statements
in the lets use rows when counting the number of
rows that satisfy a given condition (lines 14 and 19).
Right, now you've got yourself an automatic tally; unless you're not displaying those
values somehow, though, they're just baggage. Put them in the shiny new
barview control you've been promised.
A barview is an unassuming creature: all it really needs is a
value to display and a maxValue as a benchmark
to tell it how long the bar should stretch. In Vehicle
Inspection terms this translates to summing up all the
yesCount and noCount values in all of the
generated popups, relative to all the available car parts in the
parts reference
table.
...
<barview
label='{"Number of working parts ("
|| TOSTRING((SELECT SUM(pg.partsList.yesCount)
FROM vehicleRegions.rows pg))
|| ")"}'
value='{SELECT SUM(pg.partsList.yesCount)
FROM vehicleRegions.rows pg}'
maxValue='{SELECT COUNT(p.part_name)
FROM parts p}'/>
<barview
label='{"Number of faulty parts ("
|| TOSTRING((SELECT SUM(pg.partsList.noCount)
FROM vehicleRegions.rows pg))
|| ")"}'
value='{SELECT SUM(pg.partsList.noCount)
FROM vehicleRegions.rows pg}'
maxValue='{SELECT COUNT(p.part_name)
FROM parts p}'/>
...
When
specifying the values displayed in the barviews (lines 7-8 and
16-17), the query iterates through the outer repeaters generated
rows, which contain all the inner repeaters, and sums up the values
of the variables you declared earlier.
Now it's time to save and publish. Open the new version on your mobile form, and test the counting and summing.
Hopefully, you didn't go out celebrating, because there's something fishy with
those lets: since the form doesn't render a
segmentedbutton for optional parts added with the
addbutton, noCount ignores them. You'll need
to include the records inside the partsListrepeater whose required field is
0.
This isn't as straightfoward as just appending an expression to
noCount's query, because a declarations trait
isn't part of a repeater's template, and so the
record iterator isn't in scope for a let
declared there.
You need to smuggle a counter into partsList's template, where the
partrecord iterator is in scope, and then reference this infiltrator in
noCount.
The 'smuggling' is done through wrapping
partsList's children in a 'dummy' element, and then associating
the new let with
it.
...
<repeater id='partsList'...>
<declarations>
<let id="yesCount"
shape="scalar"
value='{SELECT COUNT(*)
FROM rows r
WHERE r.yesNo.selectedKey="Operational"}'/>
<let id="noCount"
shape="scalar"
value='{SELECT COUNT(*)
FROM rows r
WHERE r.yesNo.selectedKey="Malfunctioning"
OR r.optional}'/>
</declarations>
<block>
<declarations>
<let id='optional'
shape='scalar'
value='{part.required=0}'/>
</declarations>
<if cond="{NOT optional}">
...
</if>
<if cond="{optional}">
<removebutton text="Mark as operational"
label="{part.part_name}"/>
</if>
<if cond='{optional
OR yesNo.selectedKey == "Malfunctioning"}'>
...
</if>
</block>
</repeater>
...
This
'dummy' is block - all it does is define an explicit parent element for
the partsListrepeater's template to give the optionallet a way to reference the template of its parent
repeater (line 19).
Note that the yesCount and noCountlets are still outside the block, because they
belong to the repeater control itself, not its template. They
reference the rows property, which is outside the scope of the
template.
As you can see, the code above milks the new optional variable for
all its worth, replacing all instances of part.required = 0 with it
(lines 22, 25, and 28).
If you save and publish now, you'll see that the faulty partsbarview grows every time a car part is added from the
newpartsdropdown, just as it should.
Add a datepicker and a barcode scanner control, and let the user sign the form
You've arrived at the administrative fiddly bits of the form: little controls that
are important and make a difference, but aren't really exciting from a developer's
POV. You'll include a barcodereader to read barcodes, a datepicker to select a date, and a signature to, well,
submit a signature.
When the user taps the barcode icon, the device camera will fire up, and scan the barcodes that it detects. The textual representation of the barcode will appear in the text box to the left of the icon.
A datepicker is a standard iOS datepicker. The validation message,
if any, appears at the top of its dialog.
When tapped, the signature expands to fill the
screen of the device, and accepts taps and strokes. The resulting image is the value
of the control.
Let's add them to Vehicle Inspection all in one gulp:
...
<barcodereader
label="Scan the barcode on the back of the truck"
id="barcodeReader"
text='{barcode}'/>
<datepicker id="datepicker"
label="Select the current date"
dateFormat='(dtf d"/"MM"/"yyyy)'
invalidDateMessage="Please enter a valid date.">
<validation>
<validator id="dateValidator"
cond='{datepicker.date > sysp.dtlFormOpen}'
message="The entered date can't be earlier than today."/>
</validation>
</datepicker>
<signature id="signature"
label="Sign the inspection">
<validation>
<validator message='Please sign the form.'
cond='{signature.binaryId IS NOT NULL}'/>
</validation>
</signature>
...
You
didn't seriously believe there wouldn't be anything exciting about these beauties,
did you? For one thing, there's that cool new dtlFormOpen system parameter (line 12) that stores the date
and time of when the form was opened. Not to mention the
datepicker's read-only date property that it is compared to.
Then there's the mysterious binaryId, a string
that is NULL unless there is at least one stroke made in the
signature control. Look up their reference material, and
experiment.