PROVISIO DevBlog

Debugging Webpages in the SiteKiosk Android Browser

SiteKiosk Android allows you to debug webpages that are running in the SiteKiosk Android browser.

To activate this option you have to go into the settings of SiteKiosk Android, then you have to switch into the extended configuration mode. The extended configuration mode will show some options that are otherwise hidden. These are either experimental options or options useful to developers.

To enable the extended configuration mode, you need to tab seven times into the upper left corner of the configuration, right on the SiteKiosk Android logo. Please note the waring dialog, that tells you about the experimental status of the settings that are now unhidden.

In the extended configuration mode, you should go to the System page and tick the option Enable web debugging.

This is the only thing specific to SiteKiosk you need to do. The rest of the debugging process is described in detail on the Google Developers pages.

After you are done with the debugging please do not forget to disable the web debugging option of SiteKiosk again.

Allowing Android System Dialogs to set SiteKiosk Android as Default Browser for another App

As a secure kiosk solution SiteKiosk Android blocks Android system dialogs by default. Depending on the requirements of your kiosk project you might want to allow other apps to be started from within the SiteKiosk browser, for example the Android payment solution Adyen (Note: all of what is described here applies to apps that are called through specific links in the SiteKiosk browser, not to apps you are starting as an external app in SiteKiosk Android). If you need one of these apps to use SiteKiosk Android as the browser of choice to process the response of the app this selection needs to be done trough a system dialog that is called by your app while SiteKiosk is running. The aforementioned secure default behaviour of SiteKiosk Android will block this dialog. To be able to make your choice you need to temporarily allow Android system dialogs while SiteKiosk Android is running.

In order to allow another app to use SiteKiosk Android as its browser of choice you first need to open your SiteKiosk configuration editor, go to Security -> Allow assigned apps and add your app there.

The actual change required to allow Android system dialogs must be done by manually editing the SiteKiosk Android configuration. There are two ways you can do this.

If your Android device is registered with SiteRemote, you can log in to your SiteRemote team and go to SiteKiosk -> Configuration to import the existing configuration from the device, edit the configuration and publish it to one or more terminals.

If your Android device is not using SiteRemote, you can open the SiteKiosk configuration editor, go to System and select Export configuration from SD card. Now either edit the configuration locally on the Android device or copy it to computer to make the necessary change with an editor like Notepad. Afterwards copy it back to the SiteKiosk/config folder on your Android device and use the Import configuration from SD card option to activate the changed configuration.

Before editing your configuration you should make a backup, then you can skip reverting the following change that is only temporarily needed.

When you edit your SiteKiosk Android configuration look for:

</Apps></AllowedApps>

Right before that section you need to add:

<App-android enabled="true"/>

The result should look like this:

<App-android enabled="true"/></Apps></AllowedApps>

Once you use your edited SiteKiosk configuration on your Android device, start your app from within the SiteKiosk Android browser and trigger the system dialog that lets you choose SiteKiosk Android as the default browser for that app. Select SiteKiosk Android in the dialog and make sure to use the option in the dialog to make this a permanent decision.

Now that you don't need to use the system dialog anymore you can switch to your configuration backup from before the change or remove the added XML tag from your configuration. For security reasons you should not permanently run SiteKiosk Android with system dialogs being allowed.

Automatic Video Playback under SiteKiosk Android

In a few days 2015 will come to an end, therefore PROVISIO wants to wish you all the best for 2016 and we want to keep the last post for 2015 short. In the past we had a few support requests asking about automated video playback on an Android device. If you are not using the Digital Signage feature of SiteKiosk Android, with which you can create a campaign to automatically playback and even loop a video by using the Digital Signage editor of SiteRemote, there are some limitations you need to be aware of.

Automated video playback is limited in Android. This is not special to SiteKiosk Android but a general behaviour of the operating system. That feature is meant to save bandwidth and battery power. It has been added to the Android operating system on purpose and affects browsers running on Android. This means it also affects the browser part of SiteKiosk Android.

There are code examples floating around the web that can work around this behaviour to a certain degree. One of these examples can be found on github, the  code to autoplay a video is available here (https://gist.github.com/BCdmlap/5339273).

If you not only want to use autoplay but also would like to loop the video, you can find an example here (http://stackoverflow.com/questions/11225927/html5-video-will-not-loop-on-android-devices).

At the time of this writing the above examples have been tested with SiteKiosk Android 2.4 on different Android 4.x versions and was working.

Using the Blackboard to Transfer Machine Information from SiteRemote to SiteKiosk Android

A previous post has explained how to use the blackboard feature of SiteRemote and SiteKiosk to work with machine information provided by SiteRemote on the Windows client version of SiteKiosk. This handy tool is available for the SiteKiosk Android version as well. Just like with the Windows version you can read information like team name or machine name used on the SiteRemote server to work with it on the SiteKiosk Android client side.

Note that at the time of writing this post the available blackboard information is not as extensive for the Android version as it is for the Windows version but that will change with time. The strings of the blackboard for Android are also in JSON format but currently none of the available values uses complex strings, so you do not need to convert the strings before working with them.

The SiteKiosk Android Object Model provides the siteKiosk.siteRemote.blackboard.getAll method to query blackboard entries. It accepts a string that contains either the full name of a blackboard value or part of it combined with an asterisk (*). The method returns an array that includes all matching blackboard entries. Each entry has a key and a value property. Key is the name of the blackboard entry and value obviously contains the value of that blackboard entry. The following example will demonstrate the different variants.

<html>
<head>
    <title></title>
<!--The following line is required and links to the local SiteKiosk Object Model.//-->
	<script type="text/javascript" src="sk:///siteKiosk/siteKiosk.js"></script>
</head>
    <body>
		<div>
			This machine is part of the SiteRemote Team <span id="teamname">[Information not yet available.]</span> and 
			its display name on the SiteRemote server is <span id="machinename">[Information not yet available.]</span>.
			<br /><br />
			These are available blackboard keys:
			<br />
			<span id="blackboardkeys">[Information not yet available.]</span>
		</div>
    </body>
    <script type="text/javascript">
        //Wait until the SiteKiosk Object Model is loaded.
		siteKiosk.ready(function (){
			//First check if the machine is registered with SiteRemote.
			if (siteKiosk.siteRemote.registration.isRegistered()){
				//Registered. Trigger the initial blackboard request. Note: the first request will most likely come back empty.
				ReadSiteRemoteBlackboard();
			}
			else{
				//Not registered. Show message on screen.
				window.alert("This machine is not registered with SiteRemote!");
			}
			
			function ReadSiteRemoteBlackboard(){
				//Get the name of the SiteRemote team the machine is registered with.
				var array_teamname = siteKiosk.siteRemote.blackboard.getAll('StC.TeamInfo.Name');
				array_teamname.forEach(function (entry) {
					document.getElementById("teamname").innerHTML = entry.value;
				});
				
				//Get the display name of the machine in the SiteRemote team it is registered with.
				var array_machinename = siteKiosk.siteRemote.blackboard.getAll('StC.MachineInfo.Name');
				array_machinename.forEach(function (entry) {
					document.getElementById("machinename").innerHTML = entry.value;
				});
				
				//Get all available blackboard keys.
				var array_allblackboardkeys = siteKiosk.siteRemote.blackboard.getAll("StC.*");
				document.getElementById("blackboardkeys").innerHTML = "";
				array_allblackboardkeys.forEach(function (entry) {
					document.getElementById("blackboardkeys").innerHTML += entry.key + "<br />";
				});
			}
        }());
    </script>
</html>

Note that a SiteKiosk Android Object Model documentation is not publicly available yet but a preliminary version can be obtained by contacting PROVISIO support.

In order to make use of the above code the SiteKiosk Android machine needs to be registered with a SiteRemote server. After the machine has been registered it can take a few minutes until the information is available on the client. You may just refresh the example page or change the code to automatically refresh it using default Javascript methods. Periodically checking the blackboard information will also ensure that changes will become available on the client shortly after they happen on the server.

This is the test setup used for the example code test scenario:

You can place the example code in an HTML file and either place it locally on the Android device or put it on a web server. Then configure the page to for example be your SiteKiosk Android start page and do not forget to give it script allowance in the SiteKiosk Android configuration. This is how it will look once you run the page in the SiteKiosk Android browser:

Different Ways to Create SiteKiosk Windows and Android Logfile Entries

SiteKiosk logfiles are text files that contain runtime information about SiteKiosk. The logs are stored on the SiteKiosk client by default. If a SiteKiosk client is registered with a SiteRemote Server the log information is also transferred to the server, where it is used for the remote monitoring and management features of SiteRemote. This applies to SiteKiosk Windows (information can be found here) as well as SiteKiosk Android (the logs are under SiteKiosk\Logs on the sdcard of the device).

Besides containing information about SiteKiosk the logs can also be used to include entries from a website or an external application. This way you could for example generate a custom alert on a SiteRemote Server.

There are different ways to create SiteKiosk log entries from an external source, depending on the client, Windows or Android, and the type of the external source, either html code running in the SiteKiosk browser or another application.

In html code you can use the SiteKiosk Object Model, which is available in a Windows version and one for Android (the Android documentation is not publicly available yet but a preliminary version can be obtained by contacting PROVISIO support).

Note that all html examples require that the pages using the code are allowed to use the SiteKiosk Object Model. In the SiteKiosk Windows configuration you can configure this option under Access/Security -> URLs with Script Permission. In SiteKiosk Android you will find the option under Application -> Browser -> Script Permission (if you use another application option the path will vary).

Our first example demonstrates how to write a log message from a web page running in SiteKiosk Android:

<html>
<head>
	<title></title>
	<script src="sitekiosk.min.js"></script>
</head>
	<body>
		<input id="id_write" type="button" value="Write SiteKiosk Android Log Entry" />
	</body>
	<script type="text/javascript">
		siteKiosk.ready(function (){
			document.getElementById("id_write").onclick = function () {writeLog();};
			
			function writeLog(){
				var lk_logfile = siteKiosk.log;
				lk_logfile.log(20,"TEST",0,"A test log message.");
			}
		}());
	</script>
</html>

The sitekiosk.min.js script file that is referenced in the above example can be obtained from PROVISIO support. If you are using SiteKiosk Android 2.4.118 you do not need the external script anymore, instead you can reference the internal script file that is included in the installation:

<script type="text/javascript" src="sk:///siteKiosk/siteKiosk.js"></script>

With the release of SiteKiosk Android 2.5 you have a third option to access the SiteKiosk Object Model, that does not require to link a script file at all:

<script>
	//method to initialize the SK Object Model as of SKA 2.5
	(new Function(_siteKiosk.getSiteKioskObjectModelCode()))();
</script>

The log method that is used to create the log entry has four parameters. The first is the log level, possible values are 0 (verbose), 10 (debug), 20 (info), 30 (warning) and 40 (error). Mostly you will work with either 10, 20 or 30. The second parameter is the facility that triggered the log message. For most log entries this is usually SiteKiosk. If you generate your own log entries you should use your own facility name, you can choose whatever name you want for it (though you should stick to a standard character set ;-)). The next parameter is the log type, you should either use 0, which stands for a generic log message, or choose one above 9000 as the rest is already used by SiteKiosk for internal log messages. The final parameter is the text string of the actual log entry.

The example for SiteKiosk Windows (see below for a script example for the new SiteKiosk Chrome Fullscreen Browser) is similar to the Android example with slight variations due to differences in the two SiteKiosk Object Model versions:

<html>
	<SCRIPT TYPE="text/javascript">
		window.external.InitScriptInterface();
		function WriteToLog()
		{
			SiteKiosk.Logfile.Write(9001,20,"TEST","A test log message.");
		}
	</SCRIPT>
	<body>
		<input type="button" value="WriteToLog" onclick="WriteToLog()">
	</body>
</html>

The method used here is named Write and expects the same parameters as the Android log method, allthough in a different order. Further information can be found here.

Next is a script example for the new SiteKiosk Chrome Fullscreen Browser (available since SiteKiosk 8.91). The Object Model for the Chrome-based SiteKiosk browser is still in the making, but you can already write log messages. As you may note, this script has a lot of similarities with the Android version:

<!DOCTYPE html>
<html>
<head>
	<title></title>
	<script type="text/javascript" src="file://C:/Program Files (x86)/SiteKiosk/SiteKioskNG/assets/siteKiosk/sitekiosk.js"></script>
</head>
	<body>
		<input id="id_note" type="button" value="note" />
		<input id="id_warn" type="button" value="warn" />
		<input id="id_error" type="button" value="error" />
	</body>
	<script type="text/javascript">
		siteKiosk.ready(function (){
			 document.getElementById("id_note").onclick = function () {writeLog('note');};
			 document.getElementById("id_warn").onclick = function () {writeLog('warn');};
			 document.getElementById("id_error").onclick = function () {writeLog('error');};
			
			function writeLog(caseid){
				var lk_logfile = siteKiosk.log;
				
				switch(caseid){
					case "note":
						lk_logfile.info("TEST",0,"A test notification.");
						break;
					case "warn":
						lk_logfile.warn("TEST",0,"A test warning.");
						break;
					case "error":
						lk_logfile.error("TEST",0,"A test error.");
						break;
					default:
						break;
				}
			}
		}());
	</script>
</html>

There are three different methods, info for informational messages, warn for warning messages and error for error messages. They all accept three parameters. The first is a string for the facility that triggered the log message. For most log entries this is usually SiteKiosk. If you generate your own log entries you should use your own facility name, you can choose whatever name you want for it (though you should stick to a standard character set ;-)). The next parameter is the log type, you should either use 0, which stands for a generic log message, or choose one above 9000 as the rest is already used by SiteKiosk for internal log messages. The final parameter is the text string of the actual log entry.

The SiteKiosk Object Model can also be used from other applications to generate log messages, e.g. applications written in C#. SiteKiosk must run in order for the other application to write to the log files and both applications must run under the same user. A C# example that writes to the SiteKiosk logs has a few more lines than the html versions:

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.InteropServices;
using SiteKioskRuntimeLib;

namespace SKControl
{
    class Program
    {
        [DllImport("ole32.dll", CallingConvention = CallingConvention.StdCall)]
        public static extern int CoGetClassObject(ref Guid rclsid, uint dwClsContext, IntPtr pServerInfo, ref Guid riid, out IntPtr ppv);

        public bool IsSiteKioskActive()
        {

            /*
                returns false, if SiteKiosk is not currently running
                returns true, if SiteKiosk is running
            */


            // initialize GUID's for classes and interfaces
            Guid lr_FactoryGuid = typeof(ISiteKioskFactory).GUID;
            Guid lr_FactoryClass = typeof(SiteKioskFactoryClass).GUID;
            Guid lr_SiteKioskGuid = typeof(ISiteKiosk).GUID;

            ISiteKiosk mk_pSiteKiosk;

            // try to get the ISiteKioskFactory interface of the instance
            // of SiteKioskFactoryClass
            IntPtr lk_FactoryPtr = new IntPtr();
            CoGetClassObject(ref lr_FactoryClass, 4, new IntPtr(), ref lr_FactoryGuid, out lk_FactoryPtr);
            if (lk_FactoryPtr == IntPtr.Zero)
                // SiteKiosk is not running
                return false;

            // convert the received IntPtr to the requested ISiteKioskFactory
            // interface
            ISiteKioskFactory lk_Factory = (ISiteKioskFactory)Marshal.GetObjectForIUnknown(lk_FactoryPtr);

            if (lk_Factory == null)
                return false;

            // call CreateSiteKiosk to get the ISiteKiosk interface of the
            // current instance of SiteKiosk
            IntPtr lk_SiteKioskPtr = new IntPtr();
            lk_Factory.CreateSiteKiosk(ref lr_SiteKioskGuid, out lk_SiteKioskPtr);

            if (lk_SiteKioskPtr == IntPtr.Zero)
                return false;

            // convert the received IntPtr to the requested
            // ISiteKioskFactory interface
            mk_pSiteKiosk = (ISiteKiosk)Marshal.GetObjectForIUnknown(lk_SiteKioskPtr);

            if (mk_pSiteKiosk == null)
                return false;

            // write to the SiteKiosk log file
            ILogfile2 lk_SKLog = (ILogfile2)mk_pSiteKiosk.Logfile;
            lk_SKLog.Write(9001, 20, "TEST", "A test log message from an external application.");

            return true;
        }

        static void Main(string[] args)
        {
            bool lb_ReturnValue = false; //false if SiteKiosk is not running, true if SiteKiosk is running; not used in this example
            
            Program lk_Prog = new Program();
            lb_ReturnValue = lk_Prog.IsSiteKioskActive();
        }
    }
}

As the C# example is basically using the SiteKiosk Windows Object Model the syntax of the Write method is the same as if you would use it in html code. Make sure to read the part about using the SiteKiosk Object Model in C# from the SiteKiosk Object Model documentation. Running the example code from within Visual Studio while SiteKiosk is running and the debug output window is enabled (SiteKiosk Windows configuration -> Logfiles -> Show output window) will give you something like this:

Note that you may need to build your C# application for an x86 target platform rather than any cpu, otherwise it may fail to detect SiteKiosk on a 64-bit system, because SiteKiosk runs as a 32-bit application.

How to Use SiteRemote to License Your SiteKiosk Android Devices

Of course you can always apply your SiteKiosk Android license to each of your devices manually by using the configuration editor. But to spare you some repetitive work or even the trip to the device, you can easily use the Job feature of SiteRemote to remotely apply a license to your SiteKiosk Android devices. This can be a device that is previously not licensed or one that you want to change the license on.

Note that you need the SiteKiosk Android version you can get from our website and not the SiteKiosk Android Lite version from the Google Play Store.

First you have to login to your SiteRemote team. Then you select the SiteKiosk tab and choose Jobs from the submenu. On the next page you choose to create a new job. Make sure to use "SiteKiosk Android" as the client type and "Execute Script" as the action type. Choose the other options to your liking and then click on the Add button next to "Execute Script". Now add the following code lines as the script:

siteKiosk.license.registerLicense("AAAAA-BBBBB-CCCCC", function (data) {
    siteKiosk.siteRemote.scriptJob.finish(0, JSON.stringify(data));
});

Of course you need to replace AAAAA-BBBBB-CCCCC with the actual license code you received from PROVISIO. Make sure to enable the checkbox "Script requires SiteKiosk Object", otherwise the job will return an error.

In order for the client to use the license, SiteKiosk needs to be restarted. You can do this for example as a second job step by choosing the "SiteKiosk Command" option under action type and then select the Restart.

Finally assign the job to one or more devices you want to apply your SiteKiosk Android license to.

Customizing a SiteKiosk Android Browser Design

Accompanying the release of SiteKiosk Android 2.0 this blog post will show you how you can customize a Browser Design. This way you can make your SiteKiosk Android stand out from the rest, e.g. by creating a browser skin in your corporate design.

The following steps can be performed directly on a tablet, but I would suggest doing it on a PC to ease the editing process. First you need to download the Android installer package for SiteKiosk Android from our website: http://www.provisio.com/download/SiteKiosk.apk.

The installer package is basically a zipped archive, therefore the next step is to unzip the archive, using your favorite tool for that (e.g. Winzip, Winrar, 7zip, etc.).

In the unzipped archive you will find numerous files and folders. The ones we are interested in are all in the folder named assets. The folders required for our customization are apps, common (if available), external, provisio and siteKiosk. 

For our experiment we concentrate on changing the look of the browser. We therefore change a few subfolders deep in the apps folder. In ..\assets\apps\browser\skins we find all the browser designs (or skins) that are included in the SiteKiosk Android installer. To start creating our own design we make a copy of the folder named metal and rename the copy to MyBrowser (of course you can choose any name you like, but if you do, keep that in mind for the upcoming changes).

Now we step into the MyBrowser folder. In it, we will find the images subfolder. In that subfolder are a number of png files which make up the design of a browser skin. You will notice that all but the toolbar.png file are available in two sizes. This is to cater for different pixel sizes of Android devices. You are free to change the logos and icons to your liking. Just make sure to keep the original image sizes and the placement of icons, so for example do not put the refresh icon in the place that the home icon is currently using otherwise you would mix up the functions of your browser skin. The one image file that is only available in one size is the background of the browser tool bar, again you are free to change this to whatever you like, but please keep the size. The next screen shows my colorful (and possibly eye-hurting) design attempt that will be used to illustrate our little tutorial.

Next we create a logo icon for our browser to show in the configuration when we select the browser design. Go to the ..\assets\apps\config\images folder and create two png files for the icon, e.g. MyBrowser_logo.png and MyBrowser_logo2x.png. Again two version to cater for different pixel sizes. You may use the two sk_android_logo files as a base for your own creation.

Now that we are done with the actual design, we have to edit six files to make our browser design show up the way we want. In the folder ..\assets\apps\browser are two files named browserSettingsDescription.xml and browserSettingsDescriptionStrings.xml. Both have to be opened with an editor, e.g. Notepad, Notepad++, etc.

In the file browserSettingsDescription.xml add a new Option tag. Look for the Option tag with the name metal and add the new entry after that:

        <Option name="Metal" title="$Browser/BrowserSkins/Metal.Title" iconName="application-icons" iconIndex="34"></Option>
	<Option name="MyBrowser" title="$Browser/BrowserSkins/MyBrowser.Title" iconName="MyBrowser-icon" iconIndex="1"></Option>
</PreferenceSettings>

The referenced iconName will be created later. The iconIndex can be 1 as our own logo picture is not part of a single file with more than one logo.

Next is the file browserSettingsDescriptionStrings.xml. We have to add the title for our browser design, so there is a caption next to the logo in the SiteKiosk configuration. Open the file in an editor and search for Metal.Title. You will find 5 matches. Add a new line after each of the matches with your own browser title.

<String Id='Browser/BrowserSkins/Metal.Title'>Metal</String>
<String Id='Browser/BrowserSkins/MyBrowser.Title'>MyBrowser</String>

Let's step into a new folder. This time it is ..\assets\apps\browser\skins\MyBrowser. You will see three .tmpl files in there. Open all of them with an Editor and change all occurrances of the word metal into MyBrowser.

On to the last file that has to be changed. It is the file icon.js in the folder ..\assets\apps\config\widgets. After you have opened it, a few addImageMap entries have to be added. Look for metal-fullscreen-icon and after that line we add our image maps.

addImageMap({ name: "metal-fullscreen-icon", src: "../skins/metal/images/sk_android_fullscreen_icon.png", width: 42, height: 42 });
	
addImageMap({ name: "MyBrowser-icon", src: "images/MyBrowser_logo.png", width: 29, height: 36 });
addImageMap({ name: "MyBrowser-browserbar-36-icons", src: "../skins/MyBrowser/images/sk_android_browserbar_36_icons.png", width: 38, height: 38, padding: 0, states: 3, icons: 8 });
addImageMap({ name: "MyBrowser-browserbar-25-icons", src: "../skins/MyBrowser/images/sk_android_browserbar_25_icons.png", width: 27, height: 27, padding: 0, states: 3, icons: 2 });
addImageMap({ name: "MyBrowser-browserbar-logo", src: "../skins/MyBrowser/images/sk_android_browserbar_logo.png", width: 119, height: 37 });
addImageMap({ name: "MyBrowser-fullscreen-icon", src: "../skins/MyBrowser/images/sk_android_fullscreen_icon.png", width: 42, height: 42 });

We are done with our browser design. The next step is to copy the files over to the right location on the Android tablet. Attach the tablet to the PC, usually using a USB cable. Locate the SiteKiosk folder on the tablet. You can find it under [externalStorageDir]/SiteKiosk which usually translates into /mnt/sdcard/SiteKiosk. Using the USB connection from the PC the path is something like ..\Internal Storage\SiteKiosk. Copy all the four subfolders from the assets folder described above into the SiteKiosk folder on the tablet.

/mnt/sdcard/SiteKiosk/apps
/mnt/sdcard/SiteKiosk/common (if available)
/mnt/sdcard/SiteKiosk/external
/mnt/sdcard/SiteKiosk/provisio
/mnt/sdcard/SiteKiosk/siteKiosk

Start SiteKiosk and open the configuration. If you are using SiteKiosk 2.6 or higher, go to Security and select the option to allow custom SiteKiosk applications. Go to Application > Browser > Design. You should see the newly added MyBrowser design there. Select it.

Go to Application > Browser > Advanced Settings > Logo and select your logo design there. The path usually would be something like mnt/sdcard/SiteKiosk/apps/browser/skins/MyBrowser/images/sk_android_browserbar_logo.png.

Finally select Start SiteKiosk from the treeview on the left and have a look at your design in the SiteKiosk Android browser.

Please remember we kept things pretty basic for this small tutorial, as this was about showing you the places that need to be edited to have your own SiteKiosk Android browser design and not giving lessons in design. Using your own icon, background and color design you can have a completely unique look.

Smooth animations on Android

SiteKiosk for Android offers secured browsing preventing any misuse that could mess up your tablet configuration. But it's not only browsing that you can secure with SiteKiosk, also self service applications like for example menus, info terminals or customer surveys can be (and should be ;) run with SiteKiosk. An additonal advantage: you can use the powerful SiteKiosk Object Model to have even more control as normally possible with HTML pages. As I mentioned in an earlier post you can have access to local files via the sk:// protocol for example. We are adding more and more useful functionality to the Object Model in the future, so watch out for new versions. You can also post a comment here stating what you'd like to have us added to the SK Object Model.

Speaking of self service applications we realized early in our development process that android tablets are capable of many things, but still not comparable to desktop computers. Especially the browser component is a difficult story, since on one hand it supports many HTML5 features already (which is fantastic), but on the other hand still has some problems concerning completeness and performance of these new features. So you have to be a bit careful if you program web applications targeting android devices.

One example would be animations. Ever since JavaScript was introduced to the browser world, it has been used to program animations for web pages. Still it is widely used for that purpose on many pages and doing it quite well at least on desktop computers. Concerning Android, doing animations (like transitions) in JavaScript is not the best thing to do (even for desktop computer, but goes unnoticed most of the time). Say you want to create a sliding animation of a particular div containg some content that need to be exchanged when the user pressed a "next" button. You could use JavaScript's setInterval() and periodically update the div's left parameter. Unfortunately this results in poor results since the animation can be jerky on many Android tablets. A better way to do it is using CSS transforms and transitions. These will be hardware-accelerated even on Android tablets and therefore a lot smoother than JavaScript animations. 

An example would be:

<div style="-webkit-transform: translate(-600px, 0px); width=600px">Your content.</div>

This moves the div 600 pixel to the left relative to its normal position. Nice, but still no animation, right? Here you go:

<div style="-webkit-transition-duration: 500ms; -webkit-transform: translate(-600px, 0px); width=600px">Your content.</div>

Adding the "-webkit-transform-duration" will result in transition animations every time you change the "-webkit-transform" value. Obviously the transition will take 500 ms in this case. So Adding these two style properties results in a sliding animation moving the div from right to left by 600 pixels. There are a bunch of other transforms you can use for transitions like rotation, scaling and skewing. You could also use transitions for normal CSS style properties like "margin-left", but these might not be hardware-accelerated, so be aware.

Manipulation these style properties in JavaScript is not a big deal, but can be a bit cumbersome. My adivce is to use the free Move.js which makes adding these transitions dynamically very easy.

 

SiteKiosk Android: access the local file system via the "sk://" protocol

SiteKiosk Android has been out now for a (short) while and we've already gathered important feedback. We've learned that customers want to go beyond what is possible in a normal browser, which makes perfect sense given the fact that SiteKiosk for Windows already provides such possibilities to a great extend.

Accessing arbitrary local files is not allowed in a normal browser with pages coming from a server. This makes sense because security would otherwise be compromised. But sometimes you need to access large image or video files from a page and downloading these files from a server and relying on the browser to cache for example mega or even giga bytes of data doesn't seem very feasible.

So with the release of SiteKiosk Android 1.1 we proudly present: the "sk" protocol. Using "sk://" as a prefix for your URLs allows you to address files in a particular location on your Android device. When connecting the device as a USB drive, this particular location is a folder named "SiteKiosk" directly inside the root folder of the drive. The HTML pages you load in SiteKiosk don't have direct access to this folder but instead to a subfolder named "data".

So suppose you want to show a local image named "test.jpg" in one of your pages in SiteKiosk. Here is the HTML snippet for the image you could use in order to achieve this:

<img src="sk:///data/test.jpg"></img>

Notice the three (!) slashes after the "sk:", the last one stands for the sk root folder and is mandatory (meaning it doesn't work if you forget to write it). The image "test.jpg" must be located in "SiteKiosk/data" (relative to the root of your Android USB drive). Important: you have to create both folders "SiteKiosk" as well as its subfolder "data", so don't be confused if you don't find them after installing SiteKiosk (we may add the creation of these folders to the installation process in a future version).

You can use these "sk" URLs with the 'src' attribute of image, script and link tags at the moment (further support might be available in one of the next versions). Make sure the "Enable SiteKiosk scripting" option is enabled for your page, if you restrict the surf area.

If you have any problems using this feature or have other suggestions, comments, etc., please write a comment or contact us via our web page.