The tragic images of brutalized masses scar our brains.

The Holocaust has long been a sad and grotesque chapter in the world’s history.

For decades historians have struggled to find an essential missing element of the calamity: the diary of Alfred Rosenberg.

Alfred Rosenberg was the central ideologist of the Nazi Party and a top aid to Adolf Hitler. He provided the basic anti-Semitic and racial ideologies that fueled the Holocaust. 

It was assumed that Rosenberg’s diary had been permanently lost following the Nuremberg Trials. However, after an extensive investigation, the Department of Homeland Security recovered the lost artifact. 

The United States Holocaust Memorial Museum just recently released the diary to the public by publishing it online. 

Museum director Sara Bloomfield asserts that: 

“The Rosenberg diary will add to our understanding of the ideas that animated the extremist ideology of Nazism.” 

The diary will undoubtedly add to the understanding of the Holocaust, but can it do more? 

Does this diary have the ability to create a deeper understanding that will prevent future genocide?

Or is it merely a fascinating relic? 

Welcome to the final part of my IndexedDB series. When I began this series my intent was to explain a technology that is not always the most… friendly one to work with. In fact, when I first tried working with IndexedDB, last year, my initial reaction was somewhat negative (“Somewhat negative” much like the Universe is “somewhat old.”). It’s been a long journey, but I finally feel somewhat comfortable working with IndexedDB and I respect what it allows. It is still a technology that can’t be used everywhere (it sadly missed being added to iOS7), but I truly believe it is a technology folks can learn and make use of today.

In this final article, we’re going to demonstrate some additional concepts that build upon the “full” demo we built in the last article. To be clear, you must be caught up on the series or this entry will be difficult to follow, so you may also want to check out part one.

Counting Data

Let’s start with something simple. Imagine you want to add paging to your data. How would you get a count of your data so you can properly handle that feature? I’ve already shown you how you can get all your data and certainly you could use that as a way to count data, but that requires fetching everything. If your local database is huge, that could be slow. Luckily the IndexedDB spec provides a much simpler way of doing it.

The count() method, run on an objectStore, will return a count of data. Like everything else we’ve done this will be asynchronous, but you can simplify the code down to one call. For our note database, I’ve written a function called doCount() that does just this:

function doCount() {
    
        db.transaction(["note"],"readonly").objectStore("note").count().onsuccess = function(event) {
            $("#sizeSpan").text("("+event.target.result+" Notes Total)");
        };
    
    }
    

Remember – if the code above is a bit hard to follow, you can break it up into multiple blocks. See the earlier articles where I demonstrated this. The result handler is passed a result value representing the total number of objects available in the store. I modified the UI of our demo to include an empty span in the header.

<span class="navbar-brand" >Note Database <span id="sizeSpan"></span></span>
    

The final thing I need to do is simply add a call to doCount when the application starts up and after any add or delete operation. Here is one example from the success handler for opening the database.

openRequest.onsuccess = function(e) {
        db = e.target.result;
    
        db.onerror = function(event) {
          // Generic error handler for all errors targeted at this database's
          // requests!
          alert("Database error: " + event.target.errorCode);
        };
    
        displayNotes();
        doCount();
    };
    

You can find the full example in the zip you downloaded as fulldemo2. (As an FYI, fulldemo1 is the application as it was at the end of the previous article.)

Filter As You Type

For our next feature, we’re going to add a basic filter to the note list. In the earlier articles in this series I covered how IndexedDB does not allow for free form search. You can’t (well, not easily) search content that contains a keyword. But with the power of ranges, it is easy to at least support matching at the beginning of a string.

If you remember, a range allows us to grab data from a store that either begins with a certain value, ends with a value, or lies in between. We can use this to implement a basic filter against the title of our note fields. First, we need to add an index for this property. Remember, this can only be done in the onupgradeneeded event.

    if(!thisDb.objectStoreNames.contains("note")) {
            console.log("I need to make the note objectstore");
            objectStore = thisDb.createObjectStore("note", { keyPath: "id", autoIncrement:true });
            objectStore.createIndex("title", "title", { unique: false });
        }
    

Next, I added a simple form field to the UI:

Then I added a “keyup” handler to the field so I’d see immediate updates while I type.

$("#filterField").on("keyup", function(e) {
        var filter = $(this).val();
        displayNotes(filter);
    });
    

Notice how I’m calling displayNotes. This is the same function I used before to display everything. I’m going to update it to support both a “get everything” action as well as a “get filtered” type action. Let’s take a look at it.

function displayNotes(filter) {
    
        var transaction = db.transaction(["note"], "readonly");  
        var content="<table class='table table-bordered table-striped'><thead><tr><th>Title</th><th>Updated</th><th>& </td></thead><tbody>";
    
        transaction.oncomplete = function(event) {
            $("#noteList").html(content);
        };
    
        var handleResult = function(event) {  
          var cursor = event.target.result;  
          if (cursor) {  
            content += "<tr data-key=\""+cursor.key+"\"><td class=\"notetitle\">"+cursor.value.title+"</td>";
            content += "<td>"+dtFormat(cursor.value.updated)+"</td>";
    
            content += "<td><a class=\"btn btn-primary edit\">Edit</a> <a class=\"btn btn-danger delete\">Delete</a></td>";
            content +="</tr>";
            cursor.continue();  
          }  
          else {  
            content += "</tbody></table>";
          }  
        };
    
        var objectStore = transaction.objectStore("note");
    
        if(filter) {
            //Credit: http://stackoverflow.com/a/8961462/52160
            var range = IDBKeyRange.bound(filter, filter + "\uffff");
            var index = objectStore.index("title");
            index.openCursor(range).onsuccess = handleResult;
        } else {
            objectStore.openCursor().onsuccess = handleResult;
        }
    
    }
    

To be clear, the only change here is at the bottom. Opening a cursor with or without a range gives us the same type of event handler result. That’s handy then as it makes this update so trivial. The only complex aspect is in actually building the range. Notice what I’ve done here. The input, filter, is what the user typed. So imagine this is “The”. We want to find notes with a title that begins with “The” and ends in any character. This can be done by simply setting the far end of the range to a high ASCII character. I can’t take credit for this idea. See the StackOverflow link in the code for attribution.

You can find this demo in the fulldemo3 folder. Note that this is using a new database so if you’ve run the previous examples, this one will be empty when you first run it.

While this works, it has one small problem. Imagine a note titled, “Saints Rule.” (Because they do. Just saying.) Most likely you will try to search for this by typing “saints”. If you do this, the filter won’t work because it is case sensitive. How do we get around it?

One way is to simply store a copy of our title in lowercase. This is relatively easy to do. First, I modified the index to use a new property called titlelc.

        objectStore.createIndex("titlelc", "titlelc", { unique: false });
    

Then I modified the code that stores notes to create a copy of the field:

$("#saveNoteButton").on("click",function() {
    
        var title = $("#title").val();
        var body = $("#body").val();
        var key = $("#key").val();
        var titlelc = title.toLowerCase();
    
        var t = db.transaction(["note"], "readwrite");
    
        if(key === "") {
            t.objectStore("note")
                            .add({title:title,body:body,updated:new Date(),titlelc:titlelc});
        } else {
            t.objectStore("note")
                            .put({title:title,body:body,updated:new Date(),id:Number(key),titlelc:titlelc});
        }
    

Finally, I modified the search to simply lowercase user input. That way if you enter “Saints” it will work just as well as entering “saints.”

        filter = filter.toLowerCase();
            var range = IDBKeyRange.bound(filter, filter + "\uffff");
            var index = objectStore.index("titlelc");
    

That’s it. You can find this version as fulldemo4.

Working With Array Properties

For our final improvement, I’m going to add a new feature to our Note application – tagging. This will
let you add any number of tags (think keywords that describe the note) so that you can later find other
notes with the same tag. Tags will be stored as an array. That by itself isn’t such a big deal. I mentioned in the beginning of this series that you could easily store arrays as properties. What is a bit more complex is handling the search. Let’s begin by making it so you can add tags to a note.

First, I modified my note form to have a new input field. This will allow the user to enter tags separated by a comma:

I can save this by simply updating my code that handles Note creation/updating.

    var tags = [];
        var tagString = $("#tags").val();
        if(tagString.length) tags = tagString.split(",");
    

Notice that I’m defaulting the value to an empty array. I only populate it if you typed something in. Saving this is as simple as appending it to the object we pass to IndexedDB:

    if(key === "") {
            t.objectStore("note")
                            .add({title:title,body:body,updated:new Date(),titlelc:titlelc,tags:tags});
        } else {
            t.objectStore("note")
                            .put({title:title,body:body,updated:new Date(),id:Number(key),titlelc:titlelc,tags:tags});
        }
    

That’s it. If you write a few notes and open up Chrome’s Resources tab, you can actually see the data being stored.

Now let’s add tags to the view when you display a note. For my application, I decided on a simple use case for this. When a note is displayed, if there are tags I’ll list them out. Each tag will be a link. If you click that link, I’ll show you a list of related notes using the same tag. Let’s look at that logic first.

function displayNote(id) {
        var transaction = db.transaction(["note"]);  
        var objectStore = transaction.objectStore("note");  
        var request = objectStore.get(id);
    
        request.onsuccess = function(event) {  
            var note = request.result;
            var content = "<h2>" + note.title + "</h2>"; 
            if(note.tags.length > 0) {
                content += "<strong>Tags:</strong> ";
                note.tags.forEach(function(elm,idx,arr) {
                    content += "<a class='tagLookup' title='Click for Related Notes' data-noteid='"+note.id+"'> " + elm + "</a> ";  
                });
                content += "<br/><div id='relatedNotesDisplay'></div>";
            }
            content += "<p>" + note.body + "</p>";
             I
            $noteDetail.html(content).show();
            $noteForm.hide();           
        };  
    }
    

This function (a new addition to our application) handles the note display code formally bound to the table cell click event. I needed a more abstract version of the code so this fulfills that purpose. For the most part it’s the same, but note the logic to check the length of the tags property. If the array is not empty, the content is updated to include a simple list of tags. Each one is wrapped in a link with a particular class I’ll use for lookup later. I’ve also added a div specifically to handle that search.

At this point, I’ve got the ability to add tags to a note as well as display them later. I’ve also planned to allow the user to click those tags so they can find other notes using the same tag. Now here comes the complex part.

You’ve seen how you can fetch content based on an index. But how does that work with array properties? Turns out – the spec has a specific flag for dealing with this: multiEntry. When creating an array-based index, you must set this value to true. Here is how my application handles it:

objectStore.createIndex("tags","tags", {unique:false,multiEntry:true});
    

That handles the storage aspect well. Now let’s talk about search. Here is the click handler for the tag link class:

$(document).on("click", ".tagLookup", function(e) {
        var tag = e.target.text;
        var parentNote = $(this).data("noteid");
        var doneOne = false;
        var content = "<strong>Related Notes:</strong><br/>";
    
        var transaction = db.transaction(["note"], "readonly");
        var objectStore = transaction.objectStore("note");
        var tagIndex = objectStore.index("tags");
        var range = IDBKeyRange.only(tag);
    
        transaction.oncomplete = function(event) {
            if(!doneOne) {
                content += "No other notes used this tag."; 
            }
            content += "<p/>";
            $("#relatedNotesDisplay").html(content);
        };
    
        var handleResult = function(event) {
            var cursor = event.target.result;
            if(cursor) {
                if(cursor.value.id != parentNote) {
                    doneOne = true;
                    content += "<a class='loadNote' data-noteid='"+cursor.value.id+"'>" + cursor.value.title + "</a><br/> ";
                }
                cursor.continue();
            }           
        };
    
        tagIndex.openCursor(range).onsuccess = handleResult;
    
    });
    

There’s quite a bit here – but honestly – it is very similar to what we’ve dicussed before. When you click a tag, my code begins by grabbing the text of the link for the tag value. I create my transaction, objectstore, and index objects as you’ve seen before. The range is new this time. Instead of creating a range from something and to something, we can use the only() api to specify that we want a range of only one value. And yes – that seemed weird to me as well. But it works great. You can see then we open the cursor and we can iterate over the results as before. There is a bit of additional code to handle cases where there may be no matches. I also take note of the original note, i.e. the one you are viewing now, so that I don’t display it as well. And that’s really it. I’ve got one last bit of code that handles click events on those related notes so you can view them easily:

$(document).on("click", ".loadNote", function(e) {
        var noteId = $(this).data("noteid");
        displayNote(noteId);
    });
    

You can find this demo in the folder fulldemo5.

Conclusion

I sincerely hope that this series has been helpful to you. As I said in the beginning, IndexedDB was not a technology I enjoyed using. The more I worked with it, and the more I began to wrap my head around how it did things, the more I began to appreciate how much this technology could help us as web developers. It definitely has room to grow, and I can definitely see people preferring to use wrapper libraries to simplify things, but I think the future for this feature is great!

Having the ability to take elements, or even entire pages fullscreen allows developers to create fully immersive experiences for the user. You can remove the distractions from other apps and help the user to focus on the task at hand. Whether you’re watching a movie, playing a game, or just trying to get some work done, going fullscreen can really help to keep you focussed.

In this blog post you’re going to learn the ins and outs of the Fullscreen API. You’ll be learning how to take any element fullscreen, and how to style fullscreen elements using CSS pseudo-classes.

Browser Support for the Fullscreen API

All of the major desktop browsers include support for the Fullscreen API. However the implementations across these different browsers are inconsistent. Aside from the familiar vendor prefixes, the names of methods vary, as does the use of camelcase.

Source: http://caniuse.com/fullscreen

The current WebKit and Trident (IE) implementations are closest to the W3C standard for the Fullscreen API. However, no browser currently supports the non-vendor-prefixed API methods and properties.

Support on mobile is currently confined to the Android versions of Chrome, Firefox and Opera. The Blackberry browser also include partial support for the API.

Source: http://caniuse.com/fullscreen

In this post I’ll take you through the various different implementations as they stand today. Keep in mind that these may change in the future.

Going Fullscreen

You can make any HTML element fullscreen using the requestFullscreen method. For example, you could make the whole page fullscreen using the following statement.

document.documentElement.requestFullscreen();
    

Note: If you call requestFullscreen on the document body, WebKit and Blink based browsers will squash the width of the page to the smallest size possible to display the content. To avoid this you should go fullscreen on the document element instead (document.documentElement).

The requestFullscreen method must be called in response to a direct user action, like a mouse click or a key press. This prevents websites from using the API for undesirable purposes, like displaying fullscreen ads.

The implementations of requestFullscreen vary across browsers. The examples below show the methods for WebKit, Gecko and Trident browsers. Note the uppercase
’S’ in the Gecko implementation.

element.webkitRequestFullscreen(); // Chrome, Opera & Safari (WebKit)
    element.mozRequestFullScreen(); // Firefox (Gecko)
    element.msRequestFullscreen(); // Internet Explorer (Trident)
    

You may want to create a helper function that abstracts away the complexity of supporting all these vendor prefixes from your main code. The example below shows how this could be achieved.

var requestFullscreen = function (ele) {
        if (ele.requestFullscreen) {
            ele.requestFullscreen();
        } else if (ele.webkitRequestFullscreen) {
            ele.webkitRequestFullscreen();
        } else if (ele.mozRequestFullScreen) {
            ele.mozRequestFullScreen();
        } else if (ele.msRequestFullscreen) {
            ele.msRequestFullscreen();
        } else {
            // Fallback
            console.log('Fullscreen API is not supported.');
        }
    };
    

Exiting Fullscreen

To exit fullscreen mode you can use the exitFullscreen method. This should be called on the document object.

document.exitFullscreen();
    

Again, the implementations of this method varies between the different browsers. The implementation in Firefox’s Gecko rendering engine uses the non-standard mozCancelFullScreen method.

document.webkitExitFullscreen(); // Chrome, Opera & Safari
    document.mozCancelFullScreen(); // Firefox
    document.msExitFullscreen(); // Internet Explorer
    

Again, we see the uppercase ’S’ featured in the Gecko (Firefox) method. This convention is consistent across the entire Gecko implementation of the API.

You could also create a helper function to abstract away the complexity of exiting fullscreen mode. The example below shows how you could achieve this.

var exitFullscreen = function () {
        if (document.exitFullscreen) {
            document.exitFullscreen();
        } else if (document.webkitExitFullscreen) {
            document.webkitExitFullscreen();
        } else if (document.mozCancelFullScreen) {
            document.mozCancelFullScreen();
        } else if (document.msExitFullscreen) {
            document.msExitFullscreen();
        } else {
            // Fallback
            console.log('Fullscreen API is not supported.');
        }
    };
    

Document Properties

As well as the requestFullscreen and exitFullscreen methods, the API also extends the document object by adding two new properties. These are fullscreenEnabled and fullscreenElement.

fullscreenEnabled

The fullscreenEnabled property has a boolean value that is set to true if the document has the ability to display elements fullscreen.

document.fullscreenEnabled;
    

The vendor-prefixed versions of the fullscreenEnabled property are as follows:

document.webkitFullscreenEnabled; // Chrome, Opera & Safari
    document.mozFullScreenEnabled; // Firefox
    document.msFullscreenEnabled; // Internet Explorer
    

fullscreenElement

The fullscreenElement property will return the HTML element that is currently displayed fullscreen. The property will be set to null if there’s no element in fullscreen mode.

document.fullscreenElement;
    

Here are the vendor-prefixed versions of this property:

document.webkitFullscreenElement; // Chrome, Opera & Safari
    document.mozFullScreenElement; // Firefox
    document.msFullscreenElement; // Internet Explorer
    

Styling Elements in Fullscreen Mode

There is a :fullscreen CSS pseudo-class that applies to elements in fullscreen mode. This functions in a similar way to :hover or :focus if you are familiar with CSS.

/* W3C Standard */
    selector:fullscreen {
    
    }
    

Again, the naming of this pseudo-class varies across browsers. The examples below show the vendor-prefixed versions for Chrome, Firefox, Opera, Safari and Internet Explorer.

/* Webkit (Chrome, Opera & Safari) */
    selector:-webkit-full-screen {
    
    }
    
    /* Gecko (Firefox) */
    selector:-moz-full-screen {
    
    }
    
    /* Trident (Internet Explorer) */
    selector:-ms-fullscreen {
    
    }

Examples of using the Fullscreen API

Now that you understand how the API works lets take a look at a couple of examples. You’ve already seen how to make the entire document fullscreen. In this section you’re going to look at examples that use videos and images.

See the Demos Download The Code View on CodePen

Fullscreen Videos

A common use case of the Fullscreen API is to display media like videos fullscreen. This can be done by calling the requestFullscreen method directly on the <video> element. Remember that this will need to occur as the result of a user interaction.

var video = document.getElementById('video');
    var button = document.getElementById('btn');
    
    button.addEventListener('click', function(e) {
        video.requestFullscreen();
    });
    

Of course this example shows the nice, clean standardised version of the API. For this to work you would need to use the vendor-prefixed versions mentioned earlier.

Fullscreen Images

You can display images fullscreen in much the same way as videos. In WebKit browsers, images will be displayed in the center of the screen, and as close to their original dimensions as possible. Firefox will stretch images to fill the entire screen.

var image = document.getElementById('image');
    var button = document.getElementById('btn');
    
    button.addEventListener('click', function(e) {
        image.requestFullscreen();
    });
    

Final Thoughts

The Fullscreen API enables web developers to match the immersive experiences that were only previously possible with native applications. The current implementations of this API may be a little inconsistent, but this feature is certainly not going to get any less important as time goes by.

One thing we haven’t spoken about a lot in this post is how the Fullscreen API applies to mobile. Mobile devices are arguably one of the most important platforms for this new browser feature. The inherent lack of screen space on a mobile device means that any extra pixels that you can get your hands on are a big bonus.

Just because you now have the power to go fullscreen doesn’t mean that you should though. You need to seriously consider whether your desire to go fullscreen is just a greed for attention, or if viewing your app fullscreen will make a significant and positive impact to the user experience.

Useful Links

• Fullscreen API W3C Specification
• Using Fullscreen Mode (MDN)
• Microsoft Fullscreen API Documentation

The post Creating Immersive Experiences with the FullScreen API appeared first on Treehouse Blog.