Skip to main content

5 Cool Things you can do with HTML5 (p2)

As promised in the previous post in this series, this one will be about Web Storage.
Before the HTML5 era, you could store information on the client (browser) using a cookie. But that has two disadvantages (or limitations). First of all, a cookie's size is limited to 4096 bytes (but that differs over the different browsers and versions) and secondly - even more important - is that a cookie is always sent with every HTTP request, resulting in more data being sent over the wire. And that reduces scalability and decreases performance.
Using HTML5 you can use another type of storage, or even two types: sessionStorage and localStorage. In most browsers the storage is limited to 2.5Mb, but some go up to 5Mb or even unlimited. See this page for all limits per browser. And it is important to know that sessionStorage lives as long as your browser/tab is open - and is deleted on close, while localStorage stays on the client - even after a shutdown of the machine. 
In a storage only key-value pairs are stored - so it's a sort of NOSQL ;-) . You can add or replace a value in your store using localStorage.setItem("test", "12345"); or shorter : localStorage.test="12345"; You can even leave the quotes out, while all values are stored as text anyway.
And similar, you can retrieve a value using localStorage.getItem("test"); or localStorage.test;
One more thing: you can only access contents of the storage in a page when the storage is created from the same domain - so no cross domain sharing of data!
You see the contents of the storage from a domain, by opening up the Javascript console and issue the localStorage command and inspect the contents of the object. Or, in Chrome, open up the Developer Tools (Ctrl-Shift-I) and check the Resources tab. The users of the APEX Developer Addon will see that this (nice!) tool uses the localStorage feature as well...

You see the full W3C defintion on Web Storage here.

How could this be useful in an APEX environment?
When you want to welcome a user back, with a message like "Nice to see you back, we haven't seen you since <some date/time>", you can store that last date in the database. But then a user needs a login, otherwise you wouldn't recognize him. If you store that information in the localStorage, you can use that to say hello again - assuming he didn't remove the localStorage and he uses the same browser ;-)
A more sophisticated use could be, when you think of a webshop. A lot of people do "window shopping" on the net: filling up their virtual baskets with stuff...but never proceed to the counter. If you issue some kind of submit or AJAX call, every time a user adds something to his basket, you get a lot of network traffic and database processing for...what? For nothing actually. So when you keep this shopping on the client side, and submit the contents of the localStorage.basket to the database if  and only if the user presses the [proceed to checkout] button, you maximize the use of your resources. Positive impact on scalability and performance! 

Next post will be about ... GeoLocation!

Comments

The ApexLib APEX Developer Addon uses LocalStorage a lot.
That speeds up the whole Page Load Process and reduces Network traffic. That gives our users great functionality without any overhead.

For one we store our javascript and css code in LocalStorage. We also store User-Settings (which editor/syntax-highlighting-mode is used for what textarea) in LocalStorage.

Best of all: it is easy to use and works as expected.
Buzz Killington said…
Will it work like cookies in that you can turn it off in the browser? Or will developers be able to write whatever they want without the user knowing?
Roel said…
Hi Buzz,
When you block cookies, writing localStorage is also blocked (in fact you get a QUOTA_EXCEEDED_ERR Javascript error - that you could catch).
At least...that's the way it works in Chrome. But I expect similar results in other browsers.
HTH
Roel
Anonymous said…
Hi Roel,
The demo links to Oracle APEX site are not working, could you please put the correct links.

Thanks,
Kumar
Roel said…
I changed the ALIAS (HTML5) to the real Application ID (22115). So now it all should work again....
Thanks for pointing this out!
Anonymous said…
Thanks, it's working now.

Popular posts from this blog

Filtering in the APEX Interactive Grid

Remember Oracle Forms? One of the nice features of Forms was the use of GLOBAL items. More or less comparable to Application Items in APEX. These GLOBALS where often used to pre-query data. For example you queried Employee 200 in Form A, then opened Form B and on opening that Form the Employee field is filled with that (GLOBAL) value of 200 and the query was executed. So without additional keys strokes or entering data, when switching to another Form a user would immediately see the data in the same context. And they loved that. In APEX you can create a similar experience using Application Items (or an Item on the Global Page) for Classic Reports (by setting a Default Value to a Search Item) and Interactive Reports (using the  APEX_IR.ADD_FILTER  procedure). But what about the Interactive Grid? There is no APEX_IG package ... so the first thing we have to figure out is how can we set a filter programmatically? Start with creating an Interactive Grid based upon the good old Employ

apex_application.g_f0x array processing in Oracle 12

If you created your own "updatable reports" or your custom version of tabular forms in Oracle Application Express, you'll end up with a query that looks similar to this one: then you disable the " Escape special characters " property and the result is an updatable multirecord form. That was easy, right? But now we need to process the changes in the Ename column when the form is submitted, but only if the checkbox is checked. All the columns are submitted as separated arrays, named apex_application.g_f0x - where the "x" is the value of the "p_idx" parameter you specified in the apex_item calls. So we have apex_application.g_f01, g_f02 and g_f03. But then you discover APEX has the oddity that the "checkbox" array only contains values for the checked rows. Thus if you just check "Jones", the length of g_f02 is 1 and it contains only the empno of Jones - while the other two arrays will contain all (14) rows. So for

Stop using validations for checking constraints !

 If you run your APEX application - like a Form based on the EMP table - and test if you can change the value of Department to something else then the standard values of 10, 20, 30 or 40, you'll get a nice error message like this: But it isn't really nice, is it? So what do a lot of developers do? They create a validation (just) in order to show a nicer, better worded, error message like "This is not a valid department".  And what you then just did is writing code twice : Once in the database as a (foreign key) check constraint and once as a sql statement in your validation. And we all know : writing code twice is usually not a good idea - and executing the same query twice is not enhancing your performance! So how can we transform that ugly error message into something nice? By combining two APEX features: the Error Handling Function and the Text Messages! Start with copying the example of an Error Handling Function from the APEX documentation. Create this function