- 1 Quick introduction to widgets
- 2 Common mistakes, troubleshooting and best practices
Quick introduction to widgets
Widgets are building blocks of GL. ginstr custom widgets are explained in detail in this document. ginstr widgets have some internal functionality like taking a photo, calling a number. ginstr widgets are based on Android widgets, their behaviour is similar, for information about Android widgets refer to Android Documentation.
Widget XML structure
Each page (screen) must have root layout(widget) which behaves as main container of displayed(child) widgets such as TextView, Datepicker, ImageView, com.ginstr.widgets.GnEditText and others. Widget attributes will depend on design and business logic requirements of the ginstr app where following attributes must be defined for every widget:
- opening bracket
“<”and widget name
- closing bracket
- where pipe (
|) translates as option to choose one of attribute values shown.
- where pipe (
Below is example XML code for root layout. Note that lines 2-4 are obligatory only for each root layout and do not require any changes. Line 5 is used as identifier for widget and in a case of root layout it is required and must be unique across the whole given XML file (screen).
<source lang="xml"> 1.<LinearLayout 2. xmlns:android="http://schemas.android.com/apk/res/android" 3. xmlns:tools="http://schemas.android.com/tools" 4. xmlns:gn="http://schemas.ginstr.com/ginstr" 5. android:id="@+id/start" 6. android:layout_width="match_parent" 7. android:layout_height="match_parent" > 8. 9.</LinearLayout> </source>
Line 8 is location that contains widgets which will form screen content. All widgets in single screen XML file are in parent-child relationship. For better overview of XML code it is desired that each child is indented to the right by tabulation or number of spaces in relation to parent, which is in most IDE-s 4 spaces. This will ensure easier future improvements. There are different types of widgets where one can only display some content (text, image), while others can also be used to input values by user. We will describe several widgets of each group.
Display only widgets
Typical usage is showing text from string resource (strings.xml) on screen for purpose of page headline, subheadline and labeling other widgets. Attribute
textSize should be defined. Attribute
text has value
@string/txtPage1Headline which is reference to strings.xml containing textual value to be displayed as label.
This value is stored in strings.xml as below: <source lang="xml"><string name=”txtPage1Headline”>Page 1</string></source>
It is important to always use string references for label (
TextView), because of existence of several strings.xml files, each for different language, which then makes easier internationalization of each app. On image below TextView is used for page headline „coffee machines maintenance“ and as label „identify coffee machine*“ for reading code widget.
<source lang="xml"> <ImageView android:layout_width="match_parent" android:layout_height="wrap_content" android:src="@drawable/background_i"/> </source>
Widget is used to display graphic resource (image located in one of drawable directories) which is defined with: <source lang="xml">android:src=”@drawable/background_i”</source>
background_iis name of image (without file extension type .png, .jpeg, etc) which will be displayed in widget.
Main purpose is to enrich UI for better user experience. Other purposes may be attaching click event, which executes specific action. More about click events and execution actions will be described later in manual.
Example of imageView widget is displayed on screenshot from app below.
Note that imageView is used for icon and bottom image in red borders.
Input value widgets
The following widgets are expecting from user to input some value, textual, numeric and other. Main purpose is to collect from user data, which can also be graphical for instance taking picture, digital signature or scanning NFC (barcode). Some widgets can behave differently based on defined attributes. For instance most versatile widget is com.ginstr.widgets.GnEditText which can used as input box for collecting alphanumeric values, but also be configured for scanning NFC tag or barcode and more.
Input textual value (input box)
<source lang="xml"> <com.ginstr.widgets.GnEditText android:id="@+id/firstName" android:layout_width="match_parent" android:layout_height="wrap_content" android:background="@drawable/entering_field_transparent_2.9" android:textSize="20sp" gn:s_sourceType="input" gn:s_hint="@string/txtFirstNameHint"/> </source>
Input boxes using com.ginstr.widgets.GnEditTextImage above represents how input boxes look in application with attached background and hint text inside. Note that labels are above each of input box.
Input box when is used to collect alphanumeric data from user, which is entered via keyboard on device. Representation can be enriched with displaying hint text inside of input box when nothing is entered using attribute
gn:s_hint=”@string=txtFirstNameHint”. Hint text value is located in strings.xml, same as for TextView label described earlier. Further design enrichment includes showing input box on graphic background using attribute
Image for input background is located in of drawable directories.
Widget has also defined
android:id needed for referencing it in further app execution which may include saving data from this widget to database, saving data to variable, comparing widget data to another widget and other decision making business logic. With attribute
gn:s_sourceType=”input”, widget is configured to allow input of alphanumeric values. With different types of configuration of this attribute, widget can be used for different types of data entry such as numeric, current time, serial number of device and other. It is important to note that this attribute must always be defined for this widget.
Read NFC tag
Widget XML code above is same widget type as plain “input box” but configured to read NFC tags. This is achieved with defining
gn:s_sourceType=”nfc”. When NFC tag is read with device, read code will be displayed inside input box and action
gn:act_setOnNfc will execute all actions defined within the attribute value. Usually this would point to some action set which holds commands for reading data from database with NFC tag as key and decision making based on data existence. Validation attribute
gn:act_validate is present here, behaving as attribute to be checked when validation check is triggered. This attribute will be checked with action
[gn:act_validateScreen]| in app execution. In given example validator requires that value must be present in widget
@+id/readNfcTag, if not toast message will be displayed to user, where text value shown to user is referenced with
Validation attributes are used to ensure that data must be present in widget or having defined minimal, maximal length or other configured format of the content. With validators, user is forced to input data, which app business logic requires. More about validators is explained in next chapters of manual.
Regarding naming convention of string resources in strings.xml, it is good to notice that labels for widget are related for better description of page or specific input box, for example label
“txtFirstName”. Hint text for input will then be
“txtFirstNameHint” and if validator is used
“txtFirstNameRequired” will be string name resource. This will later ensure logical structuring of string resources and keep uniqueness through all strings. It is not permitted to use some string resource more than once. Names of widget id’s will be closely related to database column names and in best case they should be the same. Case scenarios for naming conventions will be closely examined on example apps provided later in manual.
With some described types of widgets we see that some of them are only for display text or images while others can have multiple purposes like entering data, reading data from other sources, displaying data from database, etc. Same is valid for events and actions. Some event can be defined on widget, which then executes action (or several actions, called action set). For example event
“gn:act_beforeLoad” attached to widget will execute action right before page is displayed on device, for instance loading some data fom database. Other events could be executed when user clicks on widget
“gn:act_setClick”,for loading next page (screen). This is usually case for buttons or some other user interaction.
Uploading ginstr apps to ginstr web
To upload ginstr app to ginstr web, we make zip file of root folder which contains all of our ginstr app folders (usually called app zip) and upload it to server
https://220.127.116.11/SSOServer in application management section. If you don’t have permission for ginstr app zip upload, request from ginstr apps developer for uploading this app zip. After upload, table with columns will be created on backend side. This can be examined opening ginstr web UI and searching app name and opening table in new portlet.
If app is on the list but does not have any tables, they should be enabled for current ginstr account. In ginstr UI lobby hover with mouse over account name will open menu. Selecting my account opens page for managing app for current ginstr account.
Click on “my account” and then on “hide/show content”. This will open list with apps. Clicking on app name opens in right tab table list with CRUD rights for each table. Clicking on table names will create tables if they are not yet created. For development purpose enable full CRUD rights for each table.
After this step is done ginstr app tables should be visible in portlet of ginstr web, if this is not the case please contact ginstr app developer.
Updating ginstr apps that are already present on ginstr web
Updating ginstr app procedure is identical to uploading new ginstr app. However there are some restrictions to modifications of ginstr app table structures to existing apps. If some of restrictions is blocking to update new ginstr app it's required to uninstall the app from ginstr web and add it as new app. Ask ginstr app developer or admin to do that. Restrictions in modifications of ginstr app new uploaded ginstr app zip are:
- company name and appId (zip file name) must be identical to original upload
- table names should be unique in ginstr app zip
- changing of datatype of existing column is not allowed
- table must have columns
- columns can't be deleted if they have references
- it's not possible to set "unique" or "required" setting on columns of table that already has entries
- new "required" column can not be added to table if "default value" is not set on in the column settings
- new "unique" column with "default value" setting can not be added to table which has more than one row of existing data
Common mistakes, troubleshooting and best practices
We will present several cases which ginstr app developer may encounter during development process. It is important to note that ginstr launcher as framework in which ginstr apps are running is constantly improved and with every new version new implementations make new possibilities to make more powerful ginstr apps. This process is also oriented to improvements of existing “functions”. Each version has improved error handling and also provides ginstr app developer with better feedback about bugs in XML which are causing errors.
Situation where ginstr app is crashing, dialog as below will be shown on screen.
Confirming with click on “SEND” will generate debug log with various app data and error information. This report will be sent by device to redmine and examined by ginstr launcher framework developers. Report should always be sent, before ginstr app developer should check if similar report does not exist on redmine. Most common actions to verify before sending report should be:
- check XML code which is changed before last good app execution – good text (or IDE) editors have XML syntax checker to verify if some node (widget) does not have valid structure (closing brackets, spaces in attributes, etc…). Additionally XML can be validated via XML checkers online, for instance on xmlvalidation.com. In the first place it is good to have editor which supports XML validation.
- check for widgets minimal set of attributes – app could crash if some widget does not have all necessary attributes defines:
- XML errors related to action sets:
- each action signature consists of two pairs of angle brackets (
[ ,]) and pipe (
|) between them.
- action set not in if statement is separated with comma (
,) and in if statement separator is semicolon (
;). Mismatching those separators may crash app and should be carefully checked.
- adding query to action set crashes the app – first it is important to check correct signature, there is difference between
rawQueryToWidgets. Incorrect separators, incorrect number of parameters, incorrect widget IDs or incorrect column names could lead to app crash.
- missing XML file will prevent app from start or crash app on launch or if action is referencing some root layout – check minimal folder and XML files for app. Even though copy/paste app files from PC to device may not reveal missing file, because transfer error may occur and not all files are correctly copied to device. Examining folders and files on device for given app on device can help determine missing XML file.
- each action signature consists of two pairs of angle brackets (
If on any of issues app crashes and issue does not exist on redmine, write a short description in bug report of steps how to reproduce the problem and link it to related app once report is created on redmine.
- query is not returning result, eventhough table has records and key is correct
- query result is not setting for some column into widget
- check widget data type which must be same as column data type
- try using another widget for returned data
- check column name in backend table
- query for writing is crashing app:
- check column-widget pairs
- try with single column and single widget to verify if query has all prerequisites for correct execution
- if some hidden widgets are saving in query, make them visible and set break before query is executed and after after query execution
- query is not saving/updating record in table, app is not crashing
- in some cases query may not cause app crash but query is not affecting data changes in backend
- uninstall ginstr launcher and install app from the start, after data replication try query again, this is because in some rare cases app developing process could make invalid data on device, breaking correct app execution with each new implementation
- updating data to database requires using pointer widget which may not have any value and in app implementation it is hidden from the screen. Reveal this pointer and examine if widget has value of table record for update
- action set could be spread through XML file and it is not clear place of XML code that app is not working correctly or it crashes
- use gn:act_break action to stop app execution
- move break action further in action chain to which app behaves correctly
- use toast messages in if-then statements to have feedback on screen about decision login during app execution
- widget id's, action separators, XML validation should be checked every now and then when app has bugs
- comparing two widgets is not working as expected or crashing app
- when comparing two widget, two variables or combination, it is important that they have same data type
- check comparing action with widget which has hardcoded value to verify comparing logic
- dropdown with database as source values does not have any values, even though table in backend has records
- uninstall launcher and install launcher and app again that replication restarts
- check query, table name, query name, widget id
- string resource is not showed in app
- check every strings.xml in each values folders, seach for string reference in each string.xml
- start developing XML files with intuitive naming of files and root layout id’s, for example
- during development work on strings.xml in folder values-en
- name strings with clear description having suffix “Hint” and “Required” if related to same widget
- make prototype of app business logic with basic read, write and update queries to confirm action set flow, then enhance with additional business logic which app requires
- use column names for widget id's which are user for saving/updating data
- avoid having action sets in widgets, keep those “procedures” in FrameLayout with intuitive id's grouped in certain place in xml file (at the top or bottom)
- avoid using helper widgets when possible and employ variables
- use helper toast messages for verifying business logic steps but clear them be-fore app deployment
- keep good track of changes made in every app version in changelog.xml
- design fixes should be last step in app development
- use existing good app layouts but track each copy paste of XML for required changes
- try every step verifying XML code for validation before sending bug report
- follow ginstr app test procedur rules to avoid app changes later
- investigate business logic part in other apps and try to improve them in each new app being developed
- It is recommended to set
"match_parent"values to attributes
android:layout_height. If fixed values are used i.e. "50dp" it might happen that if bigger font is used it will get cut off because container does not stretch with content due to set fixed size of 50dp.
- Avoid landscape mode of developing apps. It's recommended to user portrait only due to better visibility of the content and devices are used mostly in portrait mode.