Monday, August 18, 2014

Local Database

The discussion of client-side storage requires investigating the use of a client side database in addition to cache, local storage and session storage tools. An advanced experience of this tool will call for the completion of the following task where you will create a ToDo app:
http://blog.teamtreehouse.com/create-your-own-to-do-app-with-html5-and-indexeddb complete it and modify somehow.

If you would like to do something more business like, although somewhat more complex, you can follow this tutorial allowing to create a useful bibliography management app.

This task is totally voluntary and will not affect your Excellence attribute of the Certificate, but will just give you an extra knowledge and hands-on experience of an important tool.
More help on IndexedDB could be found in a mini series here, here, and here.

Be aware of your browser capabilities.


On another note I want to emphasize a growing important of the local storage solutions use case, especially in games and business apps, where the local and server content are being synced. For example, Backbone.js comes with methods for fetching and saving data models to and from the server. Then any local change or information entry can be synced with the server and then synced with other local devices. Real estate, or insurance agent software can serve as good use cases.

Monday, August 4, 2014

Additional Work Using jQuery Mobile

Knowledge of  jQuery Mobile is rapidly becoming a must in app development community (along with some other frameworks)  - so here is an additional simple task making it easier to absorb the rapid development capabilities.

As an extra point work and an additional training in jQuery Mobile do the following:

1. Read, follow, and recreate a simple app from http://ht.ly/cM7QS.

2. Modify it with following MINIMAL changes:
    a) use your own photos
    b) add Home and Info pages with some content to make the footer navbar workable from the Photos page
    c) put the footer navbar on these new pages allowing switching among pages
   

3. Of course, you can also modify the book's project for your own design, which is somewhat more complicated...

4. Post the description of the changes to the original app that you've made and the link to it (check the link workability before and after posting it) to the Extras forum.


For those who would want to include some more features - you can use this tutorial


Note: these additional efforts will not be supported - so that you should not make your code too complicated and then ask me to debug your project :) 

Saturday, August 2, 2014

Explore Emulators

One of the goals of this program is to introduce students to various approaches in mobile app development. Responsive design with its variations is an important part of it. But there are situations when it might be beneficial the creation of separate mobile sites. An interesting example can be seen in the recent political campaign.
Another aspect of separate mobile site development is in determining exactly when and for what devices such development is necessary. The two mainstream directions of the automation oof such redirecting is in media queries and user agents that you've been introduced in our studies. There is an ongoing evolution of both approaches attempting to increase their precision, while on the other side the users are getting tools allowing to change user agents in order to get different corresponding source code and views.
An important part of the decision is an ability to see how different the content looks like on different devices by using a variety of device emulators. In my opinion the latest beta of Chrome Canary (you can download it) already has a bunch of such emulators working without the need for any special installation. It actually is a useful development tool. Although I do not want to overload the course of studies with a lot of possible sideline information sticking close to the coverage of all modern approaches to mobile app development, advanced students might be interested in some additional exploration.

Exploration Advice: install the latest Chrome Canary. Go to your site and see it on the screen. Go to Tools, Developer Tools and click on any emulator you want to explore in the upper menu (under Device option).
You might also tweak your HTML and CSS in the bottom menu and see how it affects various emulators. The screen will look like the following:






But be aware that richness of the newest development tools is just masking the main challenge – responsive design as automation of responsiveness and adaptation (see RESS in my previous post) versus manual choices. And this is not only about adapting to the screen size or resolution. Modern mobile devices increasingly use additional capabilities in the use of various sensors, user actions, and dynamic UI modifications. Allowing your app automatically adapting in its behavior requires not only the views of the content that you can see in Chrome Canary manual development assistance but access to the decision making system determining app behavior and adaptive changes when dealing with specific devices and their capabilities. But this will be another story that we will touch upon later.

Saturday, July 26, 2014

Deeper DOM

What you will learn this week from w3schools is a VERY simplified view on HTML DOM used by Javascript. This post is for those who want to know somewhat more, have a better orientation in the HTML5 technologies trends.Object that you might be used to usually are special data structures supported in the memory after instantiation. In other words, they are “real” physical structures. HTML objects are a figment of imagination brought to life by browser interpretation of simple flat texts (like the one you can create in your Notepad). The ability of modern browsers creating such virtual objects with their properties and methods allowing to work with these properties and other elements creates a new world of virtualization.
This allows really modern programming against browsers (especially in HTML5-based development). APIs (Application Programming Interfaces) allow to standardize JS operations on DOM, like:

document.createElement("h1");

This allows standard and simple way of performing various operations on HTML text and its object interpretations. The growing number of special methods of HTML processing create a growing number of APIs instead of inventing programming methods of doing same things again and again. For example HTML5 DOM includes standardized methods allowing to handle:
  • Contacts - The HTML5 specification mentions that the Contacts API allows to have a common contacts repository in the browser which can be access by any web application.
  • Selection - The selection API supports selecting items in DOM (supports CSS3 type of selectors), to be used along with jQUERY.
  • Offline apps - This API allows marking pages to be available in Offline mode. This is useful if a resource requires dynamic processing.
  • Indexed database - This API is meant for a database of records holding simple values (including hierarchical objects). Every record has a key and a value. An indexed database is supposed to be implemented using b-trees. Web SQL DB is no longer being pursued as part of HTML5 specification.
  • File API - The File APIs are used by the browser to provide secure access to the file system.
  • Etc.

 Given the dynamism and growing expansion of HTML-based development it has include two functions: create standards to support globally acceptable and “re-combinable” applications and allow for the evolving nature as any language has. Therefore the two main organizations W3C and WHATWG (in ots living satndard) correspondingly split these functions.

The modern evolution of the HTML DOM goes in the direction supporting the emerging needs of effective (allowing for the latest enhancements in programming methods, operations, and interfaces) and efficient (simplifying) programming (mainly Javascript-but other languages are possible - on HTML and styles, but also on device resources like memory, sensors, etc.). For example, since the regular HTML DOM tree lacks encapsulation (one of the key features in using object-orieneted programming)  there are spreading to life such exotic things as Web Components allowing for it that also include so-called Shadow DOM.

PHP can do the same what JS does on the client – but on the server side thus nicely supplementing client or server side implementation options. For example finding an element in DOM can use the domdocument class of Php like th efollowing:

// a new dom object
$dom = new domDocument;

// load the html into the object
$dom->loadHTML($html);

// discard white space
$dom->preserveWhiteSpace = false;

//get element by id
$some_div = $dom->getElementById('someID');

if(!some_div)
{
    die("Element not found");
}

echo "element found";

Sunday, July 20, 2014

Responsive Images, etc.


Media is playing an increasingly big role in RWD methodology evolution. Only 2 years ago there were battles between client- and server-side fans of media optimization. Then the time came for RESS as a mix of responsive (at the time was reserved for client side) and adaptive (server-side) strategies.

In our learning of RWD you can see that more professional and industry-level idea of responsiveness without creating and supporting a great number of specialized sites and their components requires additional serious efforts when it comes to multimedia. Making your fixed width video and image files resize to fill any mobile device can seem a lot more complicated than using the basic general methods of RWD. And you’ve touched only images… Video, for example, is a bigger problem since is capable to hamper user experience much more. It includes more parameters to consider (like bit-rate, aspect ratio, etc.).

Some directions include control of the loading of multiple sized images via the choice by special analysis/information, like JavaScript that determines the specific features of the browser and the device with further requesting the proper media files. Others get maximum quality media (like images twice the required quality) and then simplify them for the screen (like shrinking images down).

 

With media queries getting better and better support in modern browsers sensing the local situation and ordering the proper image is not that difficult… if it is done in CSS where the image is placed as a background image order. But if you have to use the src attribute in HTML where you have to indicate a particular source – then JavaScript injection of that statement is recommended (JavaScript can modify the HTML on the fly in its DOM – model). Placing special cookies with information about the local context might serve as another way of informing the server (letting it do some work in analyzing cookies) what and how to serve.

More advanced combinations of server intelligence with browser figuring out the local context and sending some information to the server the solutions are improving. Industrial level scaling of serving video streams and multiple images already have to use cloud and grid intelligence and scalability instead of just servers (see Akamai as an example).

At the same time there are undergoing efforts in enhancing HTML5 allowing for some solutions to the problem its discussion, and more on picturefills.

There is a vast area of literature on the topic but at least read this (which is a couple of years old showing the ideas of that time) and this ( a bit later), this, and Blink/Gecko implementation. Look at src-N discussion.

 

Tuesday, July 15, 2014

Browser Support for Layered Enhancement

During progressive enhancement you use a lot of JS functionality at the top enhancement layer. But... some browsers do not support enough of JS. In order not to break your app - the usual browser response to the errors in JavaScript which makes the script stop working at that point - is to continue rendering HTML. This might look as an OK work but some parts of your JS or the whole thing might not working correct. This is why in real life watching the HTML page working is not enough for JS debugging.



Methodology is important: Progressive Enhancement vs Graceful Degradation

This week you will make another step in mastering RWD. And this is a methodological step. You can understand the components of RWD well but might start having methodological problems, that sometimes can kill a project.
    
Please read http://www.peachpit.com/articles/article.aspx?p=1586457 to get a better picture of this approach. Compare with top-down Graceful Degradation...

It doesn't mean that graceful degradation (especially if done right) is wrong :) This depends on the type of your project, its use cases, and your resources. There are proponents stating that in some cases they want to show the best modern technology can offer in order to beat the competition and demonstrate the latest advantages. Then there are only three ways: progressive enhancement, creating a separate advanced site, or use graceful degradation techniques that analyze the context and start simplifying/dropping some features depending on the situation. This requires knowledge of additional "context sniffing" and project simplification methods, more coding, but can still lead to an RWD version that will work on all devices and browsers with automatic adjustments.