SitePoint » Mobile

Strengthen User Authentication and Preserve User Experience

Roman Yudkin — Tue, 07 May 2013 09:25:58 +0000

Alphanumeric passwords have long been the primary method of authentication and access control on the Web. In recent years, however, relying on passwords as the sole method of authentication has proven to be unsustainable and not secure.

Research shows that authentication-based attacks were used in the majority of major data breaches in 2012. Simply moving beyond passwords to implement stronger forms of user authentication would prevent nearly 80 per cent of hacking attacks on companies.

Because people often use the same password on multiple websites, a large-scale password leak at one site creates a domino effect that harms security for many other websites and applications. When 1.5 million user credentials were leaked from Gawker Media Group, spammers and hackers immediately used those credentials to access user accounts on other websites. Hundreds of thousands of accounts on Twitter were compromised and used to spread spam and malicious links. Amazon and LinkedIn had to enforce password resets for their entire user communities.

Such debacles harm not only the individual users whose accounts are compromised; they also harm the organization, website or application itself. The negative repercussions of a data breach can include legal liability, fines, loss of customers, damage to brand reputation, plus the cost of fixing security and IT systems amidst a crisis.

When hackers stole more than 8 million user passwords from LinkedIn and eHarmony accounts in 2012, LinkedIn estimated it spent more than $1 million to clean up the breach and would need to spend another $2-$3 million for additional security upgrades. In 2011 Sony was forced to spend more than $170 million to remedy the fallout from a data breach that leaked more than 100 million PlayStation passwords.

Mobile developers must also consider better authentication methods. The majority of smartphone and tablet owners do not password protect their devices, despite having them connected to sensitive applications including work networks and banking applications. Users do that because typing passwords to log into mobile apps is too cumbersome. Experts at the CTIA Wireless conference even stated that growth of mobile commerce will be stunted until new, easier-to-use authentication methods are developed.

To achieve effective, strong user authentication on websites and applications, developers must balance security with usability. Do this by evaluating the security needs of the business as well as the characteristics of the user population. Is the user base comprised of employees, business partners, or the general public? This will help determine risk level and how stringent the authentication requirements should be.

Recommendations For Strong Authentication

Make sure the basics are covered

Since most websites and applications will likely choose to continue using a password as the first layer of authentication, make sure these basic security measures covered:

Enforce a dictionary check to ensure that users cannot choose common words for their password.
Require a strong username that includes a numeric character. Often the username is the easiest portion of the login credentials for a hacker to guess. Do not use the user’s email address as their username.
Limit the number of failed login attempts to three and temporarily suspend account access unless the user can authenticate through other means.
If the login fails, don’t identify which portion of the credentials was incorrect. Stating that the ‘password is incorrect’ or the ‘username doesn’t exist’ enables hackers to harvest account information. A general statement such as “Incorrect login, please try again” helps prevent account harvesting.
Use SSL to create an encrypted link between your server and the user’s web browser during account enrolment, the login process and the password reset process.
Provide users with advice on how to choose a strong username and password. Research shows that users do choose better passwords when given advice on how to do so. One option is to have a password strength meter built into the page.
Hash user passwords using bcrypt, scrypt, or other hash algorithms specifically designed to store passwords. Do not use SHA1, MD5 or other algorithms that were not designed for hashing passwords, as they are not secure.
Use Salt. Use a unique salt for each user account/password and store that salt with the password. An additional layer of system wide salt that is not stored with the password can also add extra strength if the database is stolen because it is not stored with the passwords but is known to you.

These steps may seem rudimentary to some readers, but a study conducted by researchers at Cambridge University showed that most websites did not even enforce these minimum standards.[i]

SaaS solutions for generating one-time passwords

With the growth of Software-as-a-Service (SaaS) providers, it’s easier than ever to adopt authentication solutions that generate one-time passwords for users without any hardware investment or significant integration efforts. While one-time passwords will not stop a sophisticated man-in-the-middle threat, they do protect against the most common security threats: users choosing weak passwords, reusing the same password or having their passwords stolen using keystroke-logging malware.

By generating one-time passwords for users each time authentication is needed, organizations can ensure strong passwords are used and that previously stolen or leaked passwords cannot be used to access accounts.

The growing number of user devices with touchscreens enables new approaches to SaaS authentication schemes, including image-based and graphical approaches. Increasingly users are asked to draw a pattern, touch points on a picture or identify a series of secret images to authenticate. When evaluating such approaches, it’s important to make sure the solution generates one-time passwords and is not simply a static pattern or image. User’s fingerprints and smudges on the touchscreen can reveal their secret pattern or touch points if it is a static approach.

One way to generate one-time passwords using an image-based approach is to have the user choose a few secret categories of things – such as dogs, flowers and cars. Each time authentication is needed the user is presented with a series of pictures on the touchscreen and must tap the ones that fit his previously chosen categories. The specific images are different every time and displayed in a different location on the screen every time, but the user will always look for his same categories. As the user clicks or taps on the pictures that fit his categories, a one-time password is generated behind the scenes and submitted to the server for verification.

Graphical authentication approaches are easier for users to remember than complex passwords and they are faster for users to perform on smartphones and tablets than typing an alphanumeric password. For this reason, they are a good method for adding a layer of security or a one-time password without inconveniencing users.

Risk-based authentication

Organizations requiring even stronger security should consider integrating a risk engine with their authentication solutions. Using behavioral and contextual risk profiling, risk engines can dynamically trigger additional layers of authentication only when needed. This increases security without inconveniencing users because users will rarely encounter the additional steps. Risk-based authentication solutions should identify device reputation, and evaluate the geolocation of the user’s IP address and time of day they are accessing the site.

Also examine the frequency of the login attempts, which could indicate a brute force attack. If a high-risk or suspicious situation is identified, require an additional authentication step from the user. The additional authentication step could simply be second layer of authentication, or it could be a second factor of authentication.

Multifactor Authentication

Organizations whose websites or applications could be a high-profile target for hackers should adopt out-of-band, multifactor authentication. Multifactor authentication involves at least two of the following authentication factors:

Something you know (i.e. a password, secret image categories or other shared secret)
Something you have (i.e. a mobile phone or authentication token)
Something you are (i.e. biometrics such as a fingerprint)

Multifactor authentication solutions that rely on the mobile phone as the second factor are increasingly popular. The most common approach involves sending an authentication code to the user’s phone via an SMS text message and having the user type the code into the web page to authenticate. Knowing that banks often use this approach, cybercriminals are increasingly targeting the SMS channel for attack. Using malicious software they are able to compromise a user’s online account, intercept and reroute the authentication text messages to their own phones, then use the code to gain access to the user’s account.

A more secure approach is to adopt a multi-layered, multifactor authentication solution that remains completely out-of-band from the web session on the PC. Organizations can use push technology to send an authentication challenge to users’ smartphones. Users must solve the authentication challenge on their phone and send back their response/approval via push technology, which uses a server-to-server communication channel and is more secure than SMS.

For example, using the image-based authentication approach described earlier, when a user logs into their online bank account on the PC they enter their username and password. Using push technology, the bank sends an image-based authentication challenge to the user’s smartphone. The user must tap the images that fit his secret categories and tap a submit button to send his selection back to the bank for verification. The process remains entirely out-of-band from the web session because there is no data to type into the web page on the PC.

In addition to being out-of-band, the process is multi-layered and multi-factor. The user must have possession of the registered second factor device (their phone) but also apply a shared secret (knowledge of their secret categories) on the phone. Even if someone else had possession of the user’s mobile phone or intercepted the delivery of the out-of-band authentication challenge, they would not be able to complete the process because they would not know which images to identify.

When evaluating multifactor authentication solutions that rely on the user’s mobile phone as the second factor, look for solutions that remain completely out-of-band from the web session on the PC and those that use push technology rather than plain text SMS.

Biometrics and Behavioral Biometrics

Biometrics and behavioral biometrics are also increasingly viable authentication options. Most laptops, smartphones and tablets now come with built-in video cameras that can be used for facial recognition, and fingerprint scanners are quite common in mobile and desktop environments. Smartphone applications can be used for voice recognition. However, drawbacks of biometric authentication include the need to maintain the equipment and ‘body parts’ to get accurate readings; biometric ID data must also be stored in databases and is therefore susceptible to theft and forgery.

Depending upon the type of organization or account being accessed, users may not be willing to provide biometric data for authentication. For example, users may be willing to use a fingerprint scanner to authenticate for their bank account, but not for a social networking or shopping site.

Behavioral biometrics are technologies that tracks the user’s behavioral patterns such as keystroke speed and mouse movements. These and other behavioral profiling techniques can help to successfully identify individual users, especially when used in conjunction with another authentication factor. Behavioral biometrics are usually analyzed behind the scenes, unnoticed by the user, so they do not inconvenience the user, which helps improve the usability of security.

Conclusion

Authentication standards on most websites and applications are woefully lacking. Relying solely on passwords puts the organization, its users and its data at risk. Not every website needs multifactor authentication, but most can benefit from using multiple layers of authentication or one-time passwords. User education is also critical for improving authentication. Unless the user clearly understands the reasons for additional authentication requirements, they will find ways to circumvent the policies.

Finally, it’s important to remember that ‘security’ is a process–organizations must continually re-evaluate security needs, identify areas for improvement and make a security roadmap for future improvements. A website or application can never be completely secure, but developers and security professionals should aim to strengthen security to the point where it will deter most attackers while maintaining ease of use for end-users.

[i] “The password thicket: technical and market failures in human authentication on the web” by Joseph Bonneau and Sören Preibusch

Build a Responsive, Mobile-Friendly Website From Scratch: CSS stylesheet

Annarita Tranfici — Tue, 07 May 2013 07:10:27 +0000

In the last article of this series, I’ve shown how to start building a website from scratch with a particular focus on the HTML code and its main elements.

Now it’s time to introduce the first CSS rules in order to have a general idea of the graphic style that the homepage of our website will display, especially for the pc-desktop version.

First of all, before having a look on the rules we have to apply in order to create a particular design for our homepage, let’s see how it will appear in our browser window (my default browser is Chrome but, with the application of some specific rules, you’ll be able to obtain the same result for all modern web-browsers).

The homepage of our totally customizable website should look more or less as following:

As you can see, I have imagined a very big banner to allow the designer to express all his creativity and chosen colors that combine in a clear and positive way (I really love them!). Having said that, let’s dive deep into the code.

As for the HTML section, in this case we’ll proceed step-by-step from the upper part of our layout to the bottom part. The code for the very first part (which includes the elements of banner, newsletter bar and menu) will be shown piece after piece with a very short comment, as for the other items of the page.

The first one is the banner element, with this code for styling:

#banner
{
   width: 100%;
   margin-top: 0.2em;
}

These first rules simple enough to understand. To space the banner from the top of the browser window we’re applying a margin of 0.2em and to let our banner-image cover all the width of our browser’s window, we’ve set the corresponding rule with a percentage of 100.

Let’s go on with the rules for styling our newsletter-box. In this case we have to pay attention for the rules to put on the id and the ones to consider for the class since I have decided, for personal clarity, to not choose different names for elements that substantially indicate the same part. So, for the class we set a background color (which will be the color of the box and a margin-top of 0.2 em–you’ll find out why it’s better to use these kind of measurements for a responsive website in this article, which will give you a short overview on the most common units used in Web Design) to slightly space the newsletter-box from the banner above.

The id “newsletter-box”, that is the space where we’ll find the input field and the submit button, has three simple rules, to define the spacing with the box that contains the above-mentioned elements. As you can see, there’s an id (“mobile-newsletter-box”) that seems to be inappropriate to the version we’re analysing. Actually, it’s not so: since there’ll be a change of view when passing from a pc-desktop version to a tablet version or a mobile-phone one, we have to “suggest” to our stylesheet how to perform and display the page elements.

In this case, as you’ll see in the next article when we’ll discuss about the rules to set thinking responsively, the disposition of all the elements characterizing the newsletter bar will totally change. What we have to do now is avoid having the mobile-display shown in the pc-desktop version. To achieve this result, we simply set to the rule “display” the none parameter.

A nice effect I’d like to talk about is the transition I have applied to the white box where the user inserts his e-mail to receive news. Setting to the element a transition, the resulting effect is an enlargement of the box; the other thing I’ve done is to indicate the time that this has to last. This is a CSS3 rule that creates a simple and light movement with a very pleasant output.

The last rule to discuss is the width applied when the newsletter box is clicked: setting this to 17em, the box will appear larger than usual.

.newsletter-box
{
   background-color: #c32526;
   margin-top: 0.2em;
}
#newsletter-box
{
   margin-top: 0.5em;
   height: 1.8em;
   padding: 0.3em;
}
#mobile-newsletter-box
{
   display: none;
}
#newsletter-email
{
   width: 12em;
   -webkit-transition: all 1s;
   -moz-transition: width 1s;
   -o-transition: width 1s;
   -ms-transition: width 1s;
   transition: width 1s;
}
#newsletter-email:focus
{
   width: 17em;
}

Let’s go on now analyzing our navigation bar. To delete the default bullet points of our menu list, we set the parameter to none, while to center it we recourse to the well-known rule “text-align: center”. Then we change the padding and the margin rules to the size that seems to be appropriate for our purpose. To let the elements of the list appear one after another horizontally, we change the display from the default setting “block” to “inline” and also, in this case, specify the margin parameters.

Now, it’s time to have a look at the rules applied to the link elements: as font, I’ve chosen “Bebas Neue” (you can download it here). I’ve set a font-size of 1.3 em, removed the underlining with the rule “text-decoration: none” and set the color I preferred. This color changes when the cursor moves on the menu items and, moreover, when the user clicks on the link of the page he desires to visit, there’s a 3D effect, and you can obtain it setting the rule “position: relative” on the menu links and the parameters top and left on the active state of the same element. In this way, you’ll have a slight movement that will give you the impression of a clickable 3D button.

ul.menu-list
{
   list-style-type: none;
   padding: 0;
   margin: 1em 0em;
   text-align: center;
}
li.menu-item
{
   display: inline;
   margin: 0em 1.5em;
}
a.menu-item-link
{
   font-family: "Bebas Neue",Calibri,Arial,Helvetica,sans-serif;
   font-size: 1.3em;
   text-decoration: none;
   color: #c31f05;
position: relative;
}
a.menu-item-link:hover
{
   color: #000000;
}
a.menu-item-link:active
{
   top: 0.1em;
   left: 0.1em;
}
#menu-select
{
   display: none;
}

Now, move on to the general part, that is on the rules applied to elements such as heading, paragraphs, images, boxes appearance and so on. Here is the code with the specifications of the rules for the layout I have thought out, planned and realized.

body
{
   max-width: 1024px;
   margin: 0 auto;
   font-family: "Cwmagic",Calibri,Arial,Helvetica,sans-serif;
   background-color: #E3E3E3;
   font-size: 1.2em;
   line-height: 1.5em;
}
img
{
   border: 0em;
}
h1,
h2,
h3
{
   text-align: center;
}
.float-left
{
   float: left;
}
.float-right
{
   float: right;
}
.clear-both
{
   clear: both;
}
.shadow
{
   -webkit-box-shadow: 0.4em 0.4em 0.2em #5C5B5B;
   -moz-box-shadow: 0.4em 0.4em 0.2em #5C5B5B;
   -o-box-shadow: 0.4em 0.4em 0.2em #5C5B5B;
   -ms-box-shadow: 0.4em 0.4em 0.2em #5C5B5B;
   box-shadow: 0.4em 0.4em 0.2em #5C5B5B;
   margin-right: 0.4em !important;
}
.long-box,
.small-box
{
   background-color: #cdcdcd;
   padding: 0em 0.3em;
   margin: 0em;
   margin-bottom: 1em;
}
.small-box
{
   width: 47%;
}
p
{
   margin-top: 0;
   margin-bottom: 0.5em;
}

I won’t explain the rules one by one as for the first part, especially because they are almost all the same. The only thing to which I’d like you’d pay attention is the classes float left, float right and clear both; in fact, I’ve preferred to create a class which “identifies” these rules and applies them to the elements in the HTML code rather than repeating the elements. Another element worthy of note is the CSS3 rule “shadow“.

This property allows designers to easily implement multiple drop shadows (outer or inner) on box elements, specifying values for color, size, blur and offset.
It can accept a comma-separated list of shadows, each defined by 2-4 length values (specifying in order the horizontal offset, vertical offset, optional blur distance and optional spread distance of the shadow), an optional color value and an optional ‘inset‘ keyword (to create an inner shadow, rather than the default outer shadow).
Browser support is growing of late with Mozilla (Firefox), Webkit (Safari/Chrome/Konqueror), Opera and the IE9 Platform Preview all offering a decent implementation of the specification.

Let’s conclude this article with the rules applied to elements present in the footer, that is the footer itself and the bar containing the icons for the linking to the most important social networks’ profile.

#main-footer
{
   background-color: #c32526;
   text-align: center;
}
.social-bar a
{
   text-decoration: none;
   margin-right: 3em;
}

Finally, let’s see how to manage fonts in the CSS stylesheet, bearing in mind that Internet Explorer requires a different format for the fonts, that is “eot”. Here is the code.

/*
 ***********************************
     FONT FOR INTERNET EXPLORER
 ***********************************
*/
@font-face
{
   font-family: "Bebas Neue";
   src: url(../css/bebasneue.eot);
}
@font-face
{
   font-family: "Palatino Linotype";
   src: url(../css/pala.eot);
}
/*
 ***********************************
       FONT FOR OTHER BROWSERS
 ***********************************
*/
@font-face
{
   font-family: "Bebas Neue";
   src:
      local("Bebas Neue"),
      local("Bebas Neue"),
      url("../css/bebasneue.ttf");
}
@font-face
{
   font-family: "Palatino Linotype";
   src:
      local("Palatino Linotype"),
      local("Palatino Linotype"),
      url("../css/pala.ttf");
}

Conclusion

In this article we’ve seen the basic rules to create a simple layout for a website. After concentrating on the pc-desktop version, in the next part we’ll see which are the rules to apply to make this layout responsive.

Build a Responsive, Mobile-Friendly Website From Scratch: Semantic HTML

Annarita Tranfici — Tue, 16 Apr 2013 17:37:35 +0000

In the last article, as promised, we’ve begun doing some practical work with the planning and creation of a mockup. Now, we’ve focused on how to build a personal project wireframe thinking responsively and—consequently—how a responsive design can adapt to three target layouts: Default (PC desktop), Portrait Tablet, and Smartphone.

We’ve seen how to arrange the elements of a typical website in the three main devices’ categories by creating a template that represents the common content elements. In this third part of this series, I’ll concentrate on writing the HTML code and work on the structure of the homepage, while in the very next, I’ll be setting the first CSS styling rules to build the initial design of our project.

First Step: HTML code

Let’s begin building the structure of our website through the use of HTML code. To avoid confusion and miss some steps, we’ll proceed by dividing the layout into three parts, just like we did during the mockup design phase. We’ll pause from time to time on parts of the code that are inherent only to that single part. The first part we’ll face with will of course be the header, that is the part that in our mockup consists of the following elements: banner, newsletter-box, and main menu bar. Now, what we have to do as our first task is declare the type document that for HTML5 is indicated in the following way:

Next, we must add the section that is necessary to help the web browser to interpret the content in the following body section. This section contains specific tags, CSS stylesheets, and other elements that remain hidden and are not displayed in the browser. These elements are generally called meta information (basically “information about information”) because their function is to describe what kind of information is on the page.

The first meta-tag which needs a specification is “meta charset”; it defines what character coding is used in the page. In our case, we set it to UTF-8, which is a variable width Unicode format compatible with ASCII or plain text for the basic alphanumeric characters. By using the “upper half” of the 8-bit ASCII set and extension codes, it can handle over a million unique characters.

It’s a requirement that any web page defines the formatting of the page within it’s header info so that all the browsers know exactly how to read and interpret the content. Otherwise, they’ll show the characters using their “best guess,” which isn’t always accurate. The guess could be wrong, and this will lead to showing the wrong characters to the users.

The next item we have to pay attention to is the viewport property. Setting a viewport tells the browser how content should fit on the device’s screen and informs the browser that the site is optimized for mobile. For example…

…tells the browser to set the viewport to the width of the device with an initial scale of 1. After this, we insert into the title tag the name we’ve chosen for our website. Finally, we have to link our HTML page to the CSS stylesheets that we’ll use to define the style of our homepage; the HTML “link” element specifies relationships between the current document and other documents. With this line of code…

…we link the document to the common stylesheet (that is, the document which contains all the common CSS rules that will be shared by the three versions of the project), while this one…

…recalls to the file where there are the specifications of the particular rules that will be applied only to that particular device indicated. Please note that since we’re using HTML5, you don’t actually need to specify type="text/css".

Close the head tag and move on to the body section. At this point, we have to create two separate divs: one for the banner, and one for the newsletter box.

In the first, in addition to the id, it’s a good practice for accessibility to use a WAI-ARIA role; generally roles describe widgets and structure. Structural roles are added to markup as attributes of elements, which makes it perfect for our purposes.

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) is a technical specification published by the World Wide Web Consortium that specifies how to increase the accessibility of web pages. It allows web pages (or portions of pages) to declare themselves as applications rather than as static documents by adding role, property, and state information to dynamic web applications in order to make controls and content updates accessible to users with disabilities. That’s why all these kinds of specifications are so important.

Let’s continue our project by building a newsletter opt-In form. first of all, add a form with

tags. The opening tag should include the form name, a method which can be either “query” or “post,” and the destination or “action” where the form should send the input (I put a # to indicate that it is not fixed).

Now, add a text field with a label to collect the email address and assign an ID and a class for the following changes of style you might apply to your form. Finally, add a submit button to the form. The information put into the form fields will be sent to the receiving page for processing when the visitor clicks the submit button. Insert the word “Submit” for the input type, name and value fields to create a submit button, and close the form and div tags.

So, at this point, you should have the following code:



   
      
      
      Website name
      
      
  
   
      
         
         
            
               Newsletter:

Let’s proceed with the central part of our layout, namely the one used for different types of content.

First and foremost, let’s create a classic menu, composed of five options that will be the main categories of the whole website: Homepage, News, Graphics, Mobile, and Web Design. In this case, the element most suitable for our purpose is the nav element, which is a semantic element used for declaring a navigational section of a website (that is, a section of a page that links to other pages or to parts within the page).

Within the nav tag, let’s add an unordered list (to which we’ll assign a class called “menu-item”). For the content section, let’s create a main div whose ID is “content”, a wrapper div, and put an article within it. The article element is a specialized kind of section; it has a more specific semantic meaning as an independent, self-contained part of the page. In our sample, it’ll be used to contain the description of the purpose of our website.

As for the wrapper div, it will contain three more elements: a div which contains all the information about the author (and a photo,if you want), an aside in which the author can add his screencasts, and another aside intended for his latest tweets. Two points on the aside element: it is used for tangentially-related content. However, in the interpretation of this new element there lies some confusion as to how it should be used; remember that just because some content appears to the left or right of the main content isn’t enough reason to use the aside element. The better way to decide whether you should use an aside or not involves asking yourself if the content within the aside can be removed without reducing the meaning of the main content or if the main content is truly dependent on the aside. Pullquotes, glossaries, or even related links are some examples of tangentially related content that are appropriate for an aside.

The code for this second part is the following:

      
         
            
               Homepage
            
            
               News
            
            
               Graphics
            
            
               Mobile
            
            
               Web Design
            
         
      
      
         
            Title
            
               Your content here
            
         
         
            
               
                  Information about the author 

               
            
	    
               
 
 

            
            
               
                  
                  Follow me on Twitter! 

                  We're in (number of follower)

The last remaining part is the section called footer, which generally contains information about its sections, the author, links to related documents, copyright data, and so on. In some cases, you can also find links to profiles or personal pages of ubiquitous social networks such as Facebook, Twitter, Google+, and LinkedIn. So, we place the principal information in a paragraph inserted in the new HTML5 tag

and the links directed to the social profiles mentioned above in a div whose main class is named “social-bar”.

Here is the code of this last part:

      
         
            Author's name. All rights reserved. Copyright © 2012 - 2013.

Conclusion

In this article, we’ve seen how to start building a website from scratch with a particular focus on the HTML code and its main elements. In the next article, I’ll introduce the first CSS rules in order to have a general idea of the graphic style that the homepage of our website will display. Once we pass this step, we’ll concentrate on the aspects and the procedures to be followed to convert our static homepage into a responsive homepage that will be viewed correctly on numerous different devices.

Build a Responsive, Mobile-Friendly Website From Scratch: Design a Mockup

Annarita Tranfici — Tue, 09 Apr 2013 19:52:22 +0000

In the first article of this brand new series, I have introduced the main objectives of the series and given a short but complete introduction on the critical components of media queries and responsive breakpoints. Now, it’s time to begin doing some practical work. As I have mentioned before, I’ll start with the planning and creation of a mockup for each of the three main device types on which our responsive website will be designed, tested, and displayed: PC desktops, tablets, and mobile phones.

3…2…1… Let’s Start!

Before continuing, I want to give you a little advice: remember that the more mockups you do, the more arduous and confusing your job will become. Responsive mockups are not the same as static mockups; you don’t really know where your content will be placed, because it depends on the screen size.

Obviously, as we’ve seen in the previous series, designing mockups for every screen size is nearly impossible, because there are potentially hundreds of screens, layouts, and orientations that you have to accommodate. This is why I suggest that you select your target screens/layouts and build the project mockups only for your top three main devices’ categories.

For obvious reasons, I won’t show you how to design and build the entire website, but I’ll focus on the homepage, although I’m sure that once you have understood the logic and basis of responsive web design, you’ll be able to proceed with building the entire portal and everything will fall into place. I should reiterate that creating mockups doesn’t usually require that you lay out every single view to perfection, and that they are effective as soon as they’re enough of an abstraction of the final product (website or app) that they give you sufficient information to begin building.

I have chosen to build my project mockup using Balsamiq Mockups. As I have explained in detail in the linked article, Balsamiq Mockups is a tool that helps developers to create wireframes and communicate with clients and coworkers with visual representations of their design plans. Balsamiq is offline desktop software, and you can work with it using the operating system of your choice, since it runs on Mac, Windows, and Linux.

Let’s start planning the mockup of our website working on the PC desktop version.

First and foremost, let me introduce the kind of website we’re going to desogm and all of the elements that we’ll find within it. In fact, when building a web app or website, it’s a good practice to identify your content ahead of time and designate respective content areas within the website template. For our purposes, we’ll build a website with main content topics like graphics, web design and mobile development, a place where the design-addicted can read articles about their favourite fields, discuss, learn new techniques, and stay informed.

Let’s see how can we proceed using the elements of Balsamiq Mockups and focus on one target layout first. We have to work on the placement of blocks on the layouts, and as a first step, I place the browser window shape to represent the profile of any browser page and set its size using slight adjustments with the mouse.

As for the style of the main page, the first thing to determine is which elements we want to show on our brand new homepage. Generally, we might find a header, a newsletter bar, a menu-list, some sidebars (based on the extra-content you want to enter), a text box for the most important information, an image, or some links, for example.

Thanks to its simple, intuitive drag-and-drop system, we can easily add everything we want with a few clicks. For the first components of our page, we have to open the category called “Big.” Here, we’ll find the following elements elements: title/headline, the text area, and the image box. So, drag and drop each of these into your mockup. Then, open the category “Common” to find rectangles, text areas, text input boxes, image and icons’ indicators, and link pointers. Let’s place the two sidebars to the left of the author information box (where it could be nice adding a photo) under the main content box, which occupies the full window width.

At this point, our design concept should look something like this:

Once you’ve dragged and dropped the elements, you’ll see that each element has extensive editing options. When you click on the title/headline or within the text box, you’ll see a typical text editor, where you’ll be able to specify the characteristics or content. You can modify texts selecting size, text alignment, format, and color. You can also set the background color, set the border color, add a scrollbar, and play with opacity and focus.

For images, we can show or hide a border, crop the image, and hyperlink the chosen image to lead to a new URL or screen. Since this is a mockup project intended mainly to keep in mind all the page elements and their arrangement, is not necessary in my opinion to make ultra-precise stylistic changes. What is important is to have a sort of “skeleton,” or a point of departure to fix attention on what is necessary to build into the structure with the help of the HTML code and the CSS3 styling rules.

Once we’re done with this first passage, let’s continue planning our tablet version.

As you can see in the image above, all the elements used in this second mockup are the same; the only thing that has changed is their arrangement. In the top part of the page, almost everything has the same style: the banner and the newsletter bar occupy all the window width on the PC desktop as well as the tablet version.

What has changed is the alignment of the menu-list items. In order to make the reading of menu items clear and easy even on a screen with a reduced size, I have planned to increase the space between all the present items. Additionally, the bottom part of the mockup introduces some slight changes: the sidebars that were placed on the left side of the author box have been moved under this and positioned next to each other in order to give them a larger width. Look below for clarity.

As our last step in the mockup process, let’s tackle the smartphone version. I have placed the iPhone shape (as said before, it’s the only one available to represent the profile of all modern smartphones) and duplicated it twice to allow you to view what the user would see by scrolling through the site from the top to the bottom.

As you can see, for the top part of the portal, the arrangement of the newsletter elements has changed, andthe menu-item list is also different compared to the PC desktop and tablet mockups. The input box and the submit button are presented vertically in order to make the process of writing and sending data faster and simpler. As for the menu, the best solution to adopt in this case (since the menu is composed of only five items) is to create a drop-down menu that the user can easily touch to load the page he desires to visit.

All the other components of the page are set to their max width to make the content intuitive and accessible. Even if at this stage you cannot see it, for the text view, you can think about a simple trick to make your users satisfied. Remember that, if your content is too long, they would have to scroll down the page many times to reach the end, and this could easily cause disorientation and boredom. So you could solve this “too much content” problem by placing a “Read more” link that takes the user directly to the information he demands and makes the homepage more streamlined, easier to load, and pleasant to visit, even on a narrow smartphone screen.

Conclusion

In this article, we’ve seen how to build a project mockup thinking responsively and—consequently—how a responsive design can adapt to three target layouts: Default (PC desktop), Portrait Tablet, and Smartphone. We’ve seen how to arrange the elements of a typical website in the three main devices’ categories by creating a template that represents the common content elements. In the third part of this series, we’ll start to write the HTML code and work on the structure of the homepage and set the first CSS styling rules to build an initial design.

Build a Responsive, Mobile-Friendly Website From Scratch: Introduction

Annarita Tranfici — Mon, 25 Mar 2013 14:51:30 +0000

In the last series (“Understanding Responsive Web Design“), I defined the basic features of this new and important responsive approach to mobile-friendly, device-agnostic design. Now, let’s set the stage for a more concrete work.

We’ve seen that there are many aspects to take into consideration throughout the responsive design process: screen size, operating platform, user behavior, and so on. We have explored the various measurement options for fonts in a website, and we’ve covered the best way to approach typography in terms of responsive web design. We’ve explored the characteristics of four different layout types and their respective fields of implementation. We’ve covered some common problems that a web designer may encounter when managing responsive images (and pointed out potential solutions). Finally, we’ve explored the problem of cross-browser compatibility and proposed different ways to achieve it.

Now it’s time to demonstrate some real-world technical applications of the responsive web design and build a real responsive website.

Objectives

Let’s start with defining the objectives of this new series, and highlight what you’ll learn. Thanks to this tutorial…

You’ll learn how to create a responsive design mockup, taking into account the main features of a website, the users’ needs, and the way to effectively combine responsive graphics and web design. The mockup of the website won’t be unique to one platform, and it’ll provide an example of the possible structure of a portal from several standpoints—imagining the view on three different devices: smartphones, tablets, and desktop PCs.
You’ll learn how to take full advantage of modern web technologies, namely HTML5 and CSS3, applying them step-by-step to each component of your web content.
You’ll see how to implement some rules related to responsive web design, by applying what we have analyzed conceptually in prior articles.

Media Queries

One of the foundations or responsive design is media queries, which ultimately make the site accessible and usable by the largest number of users, including those who do not use recent versions of popular browsers such as Internet Explorer, Mozilla Firefox, and Chrome.

Let’s start by getting our hands dirty with media queries; they represent one the most important tools that a web designer has to make their website responsive and mobile-friendly.

Media queries are composed of two main parts:

@ media screen — The first part of a media query is the type of support. You might recognize this syntax from writing your own CSS styles, especially if you used this method before when designing printing options for your website.
(min-width: 500px) — The second part is the query itself. It includes the function to be evaluated (in this case, the minimum width of the browser window) and the corresponding value to test that the rule has been applied (in this case, a value of 500px).

Thinking about responsive web design, there is a tendency to focus exclusively on the width property, but there quite a few other attributes to consider when designing for a variety of screen sizes. There are many more valid properties associated with media queries. They are:

width / height — With these properties, you can set the width and height of the display area including any scroll bar. You can use the prefixes min and max.
device-width/height — These properties set the width and the height of the rendering surface, that is, the width and height of the entire screen of the device and not simply of the display area of the document. Even in this case, you can still use the min and max prefixes.
orientation — it sets a vertical or horizontal orientation. By specifying particular rules in the CSS stylesheet, you will be able to define how the various elements of a web page will be displayed on the device, in this case, depending on the orientation of the device we use. We can then specify the type of orientation; landscape and portrait that allow us to change the layout of your design according to the current orientation of the browser.
aspect-ratio — This is a property that sets the ratio between the width and height of the display of a document. Even in this case, you can still use the min and max prefixes.
device-aspect-ratio — This attribute monitors the ratio between the width and height of the device. Prefixes min and max are allowed.
color — This applies certain CSS styles for all color devices. Prefixes min and max are allowed, but very few black and white devices (besides inexpensive Kindles) remain as popular browsing options
color-index — This describes the number of colors in the palette supported by a device. It can have min and max prefixes.
monochrome — This property indicates the number of bits per pixel of a monochrome device (grayscale).
resolution — Resolution sets the resolution (i.e. the density of pixels) of the output device. The values of the resolution can be expressed in DPI (dots per inch) or in DPCM (dots per centimeter).
scan — a valid property for television screens that indicates the type of scan, interlaced or progressive. The values can be precisely progressive or interlaced.
grid — Grid indicates whether the device is a bitmap type or a “grid” equivalent.

Breakpoints

After this short overview of the main (and often underutilized) properties of media queries, let’s proceed by pointing out what are the best responsive breakpoints and how to determine them for a given project.

Breakpoints in terms of responsive web design are browser widths that have a media query declaration to change the layout once the browser is within a declared width range. More specifically, a breakpoint is a point on a line that starts from 0, where there is a change (via CSS) within the layout of the page. Breakpoints are defined with numeric values and units of measurement based on the media queries entered into your CSS stylesheets.

In general, every responsive website has a minimum of two breakpoints — one for tablets and one for mobile devices. Each breakpoint corresponds to a media query. In the media query below, I wrote CSS that only takes effect when the minimum width of the browser window (min-width) is equal to a specific value (that can be 320px, 480px, 768px, etc..).

Here is an example of one of these standard breakpoints:

@media only screen and (min-width : 320px) {
/* Styles */
}

But, how many breakpoints does a web designer need to create? This depends on the characteristics of the website, on its layout, and on the techniques that you decided to implement in order to turn your design plans into something truly interactive and responsive In essence, we could answer the previous question in this way: You need a breakpoint for every device that you deliberately choose to support.

Breakpoints According to the Devices

Today, the prevailing practice tends to set breakpoints based on the size of the screen (or browser window) of the following popular device types:

Smartphone (with portrait or landscape orientation)
Tablet (with portrait or landscape orientation as well)
Netbook
Desktop PC monitor with high or very high resolution

Translating this scheme into pixels, you can see how for smartphone and tablet categories, the “standard” sizes adopted mainly correspond to the screen dimensions of the iPhone and iPad:

320px — iPhone in portrait orientation
480px — iPhone in landscape orientation
768px — iPad in portrait orientation
1024px — iPad in landscape orientation (as well as netbooks, since these devices typically have a horizontal resolution of 1024px).

Someone might argue that not all smartphones and tablets are iPhones or iPads, and they’d be unquestionably correct. But, in this case the screen size of the Apple device is used more as a reference point for a greater category of devices. Moreover, creating a breakpoint for each and every device would be totally absurd.

A good practice could be defining a set of main breakpoints possibly combined with some secondary breakpoints in order to fit the document to specific devices. You could also think about creating a custom breakpoint; this is very straightforward but requires a familiarity with media queries, so I suggest practicing initially with basic media queries and common breakpoints.

It’s extremely important to test your dynamic layouts, including the breakpoints themselves, and the CSS that executes under certain screen size conditions. If you do not have both of those aspects of your responsive design in good order, you’ll end up with glaring layout and functionality problems that make your website less responsive than if you hadn’t attempted any mobile-friendly accommodations. Test your designs thoroughly!

Conclusion

I have introduced the main objectives of the series, and above all, I have given a short but complete introduction on the critical components of media queries and responsive breakpoints. In the next article, I’ll start with the planning and the creation of a mockup for each of the three main device types on which our website will be designed, tested, and displayed.

Want to learn more about Responsive Web Design? Check out SitePoint’s new book, Jump Start Responsive Web Design!

Why Mobile Apps Need Privacy Policies (and How To Get Yours Right)

Veronica Picciafuoco — Tue, 19 Mar 2013 14:40:41 +0000

Privacy Policies and other legal documentation are occasionally viewed as an afterthought of the mobile development process—something to be hastily included after all of the conceptual design and development work is complete. This legal safeguarding may seem like a last-minute addition that doesn’t merit much thought, but it may be the most important component of your entire business.

Privacy Policies are not all alike, and there are numerous ways that a missing clause or a mismatch between your legal documents and your app itself can cause catastrophic problems. Quite a few ubiquitous and successful mobile apps have run into massive legal headaches and astronomical fines due to flaws in their privacy policy and a failure to integrate and unify their legal protection with the “private parts” of their app architecture.

Only a few weeks ago, social app Path was fined nearly 1 million dollars by the FTC (Federal Trade Commission) for privacy violations. The $800,000 penalty stemmed from two lethal mistakes made by the app:

storing third-party names and numbers from their users’ address books, without proper disclosure;
failing to comply with the provisions of COPPA, a law that applies to every app that knowingly collects information from children.

This means that if you extract phone contacts from your users, not only must you notify them, you must also explain within the app’s privacy policy how any why the information is used. If you collect users’ birth dates, you can likely figure out if children are using your app and do something about it. You essentially have two legal avenues: comply with COPPA or make sure users represent that they’re over 13.

But there’s more. The FTC published a long document with recommendations for app developers and even platform-specific advisement for big platforms like Android and iOS.

Privacy by Design

The FTC wants app developers to use a (relatively) new approach called “Privacy by Design.” “Companies should build in privacy at every stage in developing their products.” This means a number of things:

before building an app or a feature, think of the privacy implications;
if you collect information, protect it. Follow the security recommendations of the FTC (with special attention to the third-party software you used) and be careful not to overpromise or make generic reassuring statements;
keep your policy updated! Every time you roll out a new update to the app store, stop for a second and think if you added something that has an impact on your privacy statements. Added a new analytic script? It should go in there. Added “find friends via Facebook”? Go and edit your privacy policy.

What Does It Mean for App Developers?

There are known best practices—some of them coming from the California Attorney General—to give you some legal protection and prevent problems, privacy breaches, and lawsuits. But this is what the FTC actually says that developers should do.

You should have a privacy policy and it must be accessible from the app store.

The simple way to accomplish this is to simply link the policy when you submit the app. But, this means the privacy policy should live on your website. You could also provide the full text of the policy within the app, or a short statement describing the app’s privacy practices. Need a privacy policy from scratch? There are many options: Docracy’s open source standard, a privacy policy generator, and many other free resources you can find on Google.

You should provide “just-in-time disclosures” and obtain affirmative express consent when collecting sensitive information from outside the platform’s API.

You already know that iOS pops up a notification that a certain app is requesting access to the user’s location or other private data. In this case, the disclosure and the consent are taken care by Apple. But, your app might as well collect other important stuff, and a pop-up notification is the best way to make sure the users know. FTC names financial, health, or children’s data, but also a generic “sharing sensitive data with third parties” as sensitive private information, so it’s best to err on the side of caution.

Know the legal implications of the code you’re using.

It’s normal for app developers to use third-party packages, SDK, and the like. You should make sure this code is secure and fully understand exactly what information it pulls, because you’re ultimately legally responsible for it. There’s a long list of questions to ask yourself, including:

Does this library or SDK have known security vulnerabilities?
Has it been tested in real-world settings?
Have other developers reported problems?

Conclusion

Path was fined $800,000. While this is was in connection with COPPA violations, it’s the start of broader policing of privacy practices, even against non-American developers. If you cater to the American mobile market, you can still be fined by U.S. Authorities. It’s time for app developers to lawyer up and get a properly-written, constantly-curated privacy policy. The FTC is encouraging the adoption of public standards and suggests tightened integration among app developers, trade associations, ad networks, and mobile platforms, so this is definitely a topic to keep under the radar. You wouldn’t want a legal problem to cripple your app right as it’s starting to soar.

Understanding Responsive Web Design: Cross-browser Compatibility

Annarita Tranfici — Wed, 13 Mar 2013 13:06:22 +0000

In the last article, I described three ways to work with with images from a responsive design standpoint, discussing the best solution to adopt while serving properly-sized imagery to a variety of screen sizes. In today’s article, I’ll focus on imagery management from another point of view, that is cross-browser compatibility.

During the creation of a website — especially if your aim to make its structure responsive — one of the most important and frequent problems that a web designer has to face involves cross-browser compatibility, that is, compatibility across different browsers.

What does “compatibility” stands for? The designer of a website must ensure that their design works properly and that its appearance is error-free and functional on any platform used to view it. It ‘s definitely one of the most complicated and frustrating aspects you must consider when designing a new project, but it’s essential that the you do not leave anything to chance and keep cross-browser compatibility in mind throughout the design process.

Many of the new CSS capabilities introduced in the new CSS3 version are still not widely supported by all major browsers. In fact, some are not recognized and therefore ignored completely, which can pose major problems if your design relied on unsupported CSS. It’s not just a variety of browser types either; different versions of the same browser can support (or fail to support) various design techniques, which complicates cross-browser compatibility even further.

Let’s get back to image management, which probably is the weak point of the RWD approach, especially for browser compatibility issues. Photos and media need to be flexible and adapt to different devices, and at the same time, it’s crucial that they don’t slow down page loading in the process. Therefore, there is still no definitive, ideal solution to problems such as different screen sizes, restricted bandwidth (in cases of mobile browsing), performance on high-resolution (“retina”) displays, and so on.

It is clear that using a single image (the largest possible version) for all devices is not an advisable solution. Think about the time a poor smartphone-2G user would take to load your design. After your ultra-slow image loads, those high-resolution images will probably display at about one quarter of their original size.

The largest problem is that media queries do not work with older browsers. Consequently, a responsive web page with many CSS3 rules applied can be seen correctly only by those who have recently-updated browsers with strong CSS3 support. Fortunately, there are three JavaScript solutions that can help us serve responsive websites to older browsers lacking CSS3 support: Respond.js, Modernizr, and adaptive.960.js. Let’s have a look together.

Respond.js

The first solution is also the simplest one — I’m talking about a script called respond.js, which enables the older browser versions to understand and execute CSS3 media queries. Here’s all it takes to get started.

This script is called on the page (as shown above) and adds support to media queries, min-width, max-width, and all media types (e.g. screen) for older browsers. This script can help your CSS3 instructions work properly, even for older browsers.

Respond.js may seem like it’s too easy to be an ideal solution, but for many projects this is an great solution because the code is read from the latest CSS3 PC browser and all browser designed for smartphones. The sole purpose of the script is to make older browsers read the CSS3 instructions within media queries. Nothing more, nothing less.

Modernizr

The second solution is the use of a tool called Modernizr. As explained in the documentation page of its website, “Modernizr is a small JavaScript library that detects the availability of native implementations for next-generation web technologies, i.e. features that stem from the HTML5 and CSS3 specifications.”

Many of these features are already implemented in at least one major browser (most of them in two or more), and what Modernizr does is—very simply—tells you whether the current browser has this feature natively implemented or not. This is an indispensable tool that gives you fine control over the experience through JavaScript-driven feature detection.

After the first phase of detecting features, Modernizr creates a JavaScript object with the results and adds classes to the HTML element for you to target with your CSS. It’s a gorgeous solution, because it makes it easy for you to write conditional JavaScript and CSS to handle each situation, whether a browser supports a feature or not.

Modernizr supports these browsers: IE6+, Firefox 3.5+, Opera 9.6+, Safari 2+, Chrome, Mobile Safari, Android WebKit browser, Opera Mobile, and Firefox Mobile.

You can download the full version of the library and implement it according to your specifications. However, if you only needs to test the compatibility of CSS3 in your browser, you can set the various options offered by the library and create your own compressed code. Paste the code into an external .js file and include it at the tag of your HTML document. The Modernizr team recommend to include the library just after importing CSS.

You should have this code:



 
  Your title
  
 
 Your content

Now you have a JavaScript library that indicates you whether the CSS3 or HTML5 functions you used are supported or not. Let the page run on the browser and look at the code with Chrome developer tools or Firebug.

You should see something like this:


....

adapt.960.js

The third solution that we consider is very different from the previous two, especially because it does not make use of CSS3 and accordingly of media queries. However, the concept is very similar to the CSS3 media queries.

If we use CSS3 in a single file, this library requires us to separate the code into several CSS files, one for each device type. The library parses the resolution of the device and calls the CSS designed for that specific screen resolution.

We can download the script and see immediately how it works. Activate the library on your page with the following line:

Then, copy the following code:

We see the list of CSS files within the “range,” one for each group of resolutions. Each of these files contains CSS properties related only to a specific device, just as the code enclosed within the CSS media queries.

The common CSS—that is the CSS that should apply to all screen sizes—should be included in a different CSS file, which for convenience we can call master.css and retrieve it before the integration of this library, just like normal CSS file:

Conclusion

Which of the three solutions should we adopt? They are all valid, sensible approaches. If you choose to apply the first solution (respond.js), you’ll have to write and manage a single CSS file, unlike adapt.960.js, which requires multiple CSS files. Finally, if you choose to try Modernizr, you’ll take advantage of new CSS3 capabilities in the browsers that can support them and still have easy and reliable means of controlling the situation for the browsers that cannot.

If you believe that, within few years, older browsers will be irrelevant and that mobile browsers will supersede their desktop counterparts, I believe that it is better to work with media queries and extend support for older browsers with JavaScripts plugins that are available.

Remember that there are also web-based services to test a responsive website and simulate resizing of the browser window. Two of these are responsive.is, which is very easy to use, and studiopress.com, which, after entering the web address, makes different views of your website appear side-by-side.

In addition to web-based solutions, there are also applications that can be installed directly on your personal computer. Among them, we find Opera Mobile Emulator, which is available for Mac, Linux, and Windows. After installing and opening the application, you’ll have a list of devices that it can emulate (with the unfortunate exception of Apple devices).

To conclude this article, I’d like to share a very useful online tool to test the compatibility of your live website: crossbrowsertesting.com. You must choose an operating system and a web browser, and that’s all. A series of well-organized screenshots on multiple browsers will allow you to have a complete view of your site, and in this way, it will be easier to understand on which elements you should modify to make your project perfectly compatible with any platform.

Want to learn more about Responsive Web Design? Check out SitePoint’s new book, Jump Start Responsive Web Design!

Build Multilingual Android Apps Using Custom Localization

Christa Joe — Tue, 12 Mar 2013 22:23:46 +0000

In today’s tech-savvy world, companies are craving actionable feedback from their customers, typically in the form of surveys and other customer feedback mechanisms. This has become a common, efficient practice that provides organized data for the company and an easy, straightforward process for the customers themselves. Just a single click saves the data to the common server and eliminates the hassle of paper-based survey forms. Multilingual survey apps are even more useful and powerful, as they help surveyors gather region-specific data and conduct international surveys from a single system.

The concept of Custom Localization in Android SDK plays a major role in providing strong support for multilingual interactivity. Custom Localization means that the user should be able to change the app language using the app settings without having to change the language of the entire mobile device. One of the limitations is that the multilingual support for Indian languages is not a part of the Android SDK, which poses a major challenge for developers performing custom localization on Android OS.

Using the Android SDK platform, the concept of localization can be easily handled, but the major challenge is the insufficient support of localization for Indian native languages. For any foreign language, the device locale can be set to the language name. For example, users from France can change the language of their device to French, and all of the written content will be converted to the French language. One of the advantages of the following survey-based application is that it supports the regional languages of India, such as Tamil, Marathi, Hindi, and many more.

Description

Android SDK provides an API function that allows the usage of external fonts. These fonts allow rendering of characters and symbols used by different languages. To use this approach, each and every component is initialized in an activity class, and its font type is set to ensure that the correct font is rendered. This approach solves the problem of regional language support, but it cannot be considered a perfect solution, as it creates large amounts of unnecessary objects and references in the activity class.

The following points should be noted to develop a multilingual support application:

The Android SDK provides a resource type to create custom attributes for views. A custom attribute can be created as a “langtext.” Please refer to the following code snippet for clarity:

In the strings.xml file, the string values were created in a key-value pair manner. Below is a demonstration.

error Error // text in english गलती //text in hindi తప్పు //text in telugu

These strings are created in such a way that by adding the language type (e.g: en, hi, tu) in the value of key_, it will return the actual string value in the selected language.

A custom view can be created, which extends the TextView class of Android. In this class, override the setTypeface. Using this method, set the required font file to the textview. Please refer to the following code snippet:

package com.wb.mobile.android.ot.ui.customviews;
import android.content.Context;
import android.content.res.TypedArray;
import android.graphics.Typeface;
import android.util.AttributeSet;
import android.widget.TextView;
import com.sample.mobile.android.ot.R;
import com.sample.mobile.android.ot.ui.activities.SplashScreen;
import com.sample.mobile.android.ot.utils.Constants;
import com.sample.mobile.android.ot.utils.Helper;
/**
 * Custom implementation of textview for supporting multiple languages.
 *
 * @author magarwal
 *
 */
public class MultiLingualTextView extends TextView {
	private String mLangText;
	public String getLangText() {
		return mLangText;
	}
	public MultiLingualTextView(Context context) {
		super(context);
	}
	public MultiLingualTextView(Context context, AttributeSet attrs) {
		super(context, attrs);
		TypedArray typedArray = context.obtainStyledAttributes(attrs,
				R.styleable.CustomTextView, 0, 0);
		String lang = SplashScreen.getUserSettings().getString(
				Constants.LANG_CONSTANST_STR, Constants.LANG_CONSTANST_EN);
		String langText = typedArray
				.getString(R.styleable.CustomTextView_langText);
		mLangText = langText;
		if (Helper.checkString(langText)) {
			this.setText(Helper.getStringResource(getContext(), lang + "_"
					+ langText, "string"));
		}
	}
	public MultiLingualTextView(Context context, AttributeSet attrs,
			int defStyle) {
		super(context, attrs, defStyle);
	}
	@Override
	public void setTypeface(Typeface tf) {
		String lang = SplashScreen.getUserSettings().getString(
				Constants.LANG_CONSTANST_STR, Constants.LANG_CONSTANST_EN);
		if (lang.equalsIgnoreCase(Constants.LANG_CONSTANST_EN)) {
			super.setTypeface(tf);
		} else {
			super.setTypeface(Helper.getTypeface(getContext()));
		}
	}
	@Override
	public void setTypeface(Typeface tf, int style) {
		String lang = SplashScreen.getUserSettings().getString(
				Constants.LANG_CONSTANST_STR, Constants.LANG_CONSTANST_EN);
		if (lang.equalsIgnoreCase(Constants.LANG_CONSTANST_EN)) {
			super.setTypeface(tf);
		} else {
			super.setTypeface(Helper.getTypeface(getContext()));
		}
	}
	public void setLangText(String langText) {
		mLangText = langText;
		String lang = SplashScreen.getUserSettings().getString(
				Constants.LANG_CONSTANST_STR, Constants.LANG_CONSTANST_EN);
		if (Helper.checkString(langText)) {
			this.setText(Helper.getStringResource(getContext(), lang + "_"
					+ langText, "string"));
		}
	}
}

Now we need to consider the function that retrieves the value of a string resource, which is demonstrated in the following code snippet:

/**
* get the translated string value associated with a key.
*
* @param context
*            -- activity reference for accessing API's
* @param name
*            -- key for which string is needed.
* @param type
*            -- "string" as in R.string.sth
* @return -- translated value.
*/
public static String getStringResource(Context context, String name,
String type) {
try {
int id = context.getResources().getIdentifier(name, type,
context.getPackageName());
return context.getResources().getString(id);
} catch (Exception e) {
Helper.printStackTrace(e);
return name;
}
}

Applied to the Android OS, this code will render text content in the user’s language of choice, even if that language is one of the unsupported Indian languages. Our custom code makes for multilingual interactivity that could be used anywhere in the world.

Conclusion

If you’re not catering to users beyond your own nation’s borders, you’re likely missing out on huge opportunities. If you’re intimidated by making your app multilingual, hopefully this demonstration shows Android’s multilingual capabilities, as well as custom coding that can accommodate even the unsupported languages. If you’re looking for more users, a bigger audience, or entry into international marketplaces, you’d be crazy not to build multilingual support into your Android app.

Build a Contacts Management App Using HTML5, JS, CSS3, and Wakanda Studio

Saad Mousliki — Thu, 07 Mar 2013 18:32:09 +0000

Many years ago, JavaScript developers were considered second-class citizens in the programming world. JavaScript was only used to perform some easy client-side tasks such as alert messages, form validation, and style manipulation. Nobody was convinced to use it for intensive programming applications due to its limitations and several serious security problems.

But, in the past few years with the arrival of HTML5, JQuery, NodeJS, WebRTC, Google API, and others, JavaScript has become a mature language for developing a robust business applications via server-side coding, NoSQL Databases, JSON format, REST for communication and many other worthy methods.

In this article, we will prove how possible (and even easy) it is to develop a mobile web application that retrieves the phone contacts on disconnected mode and retrieves contacts from a remote server in connected mode using HTML5, JavaScript, and CSS3. We’ll package it using PhoneGap to build to a native mobile app that will work online and offline.

Background

Before starting using this guide, you should have some basics on HTML5, JavaScript, and the mobile development world. In this article, I’ll also use the Wakanda DataStore as a NoSQL database that will be remotely added by our native app to get data using REST/HTTP and JSON format, so having some basics on Wakanda could be very helpful.

Using The Code

Application Architecture

The PhoneGap build input for this mobile application is freely available for download. It’s a zip file developed using the Wakanda Studio smartphone part. The bundle contains numerous noteworthy files.

First and most importantly, it contains the index.html file, which is the main page of our application. This page has three views: one for the homepage that contains two buttons to choose between connected or disconnected mode, a view containing a grid that will load data from the remote Wakanda Server, and a third view that contains a richText widget, which will load the list of mobile contacts using the PhoneGap contact API.

The second file worth mentioning is the config.xml file. This XML file provides some necessary settings to the PhoneGap build service. which to package the app and prepare it for mobile devices. Below is the config.xml data.


    GET CONTACTS
        An application that gets contacts from DataStore and also from phone
        Saad Mousliki

(You could take a look to the official PhoneGap documentation to learn more about how to write this file.)
Two additional noteworthy files are splash.png and icon.png. These two files serve as the splash screen and the icon that will be displayed when installing the packaged app on your mobile device.

Next is the walib folder, which contains the WAF (Wakanda Application Framework) API—a set of JavaScript libraries used to manipulate UI, HTTP/REST communication, mapping, etc.

And, of course, the widely-used scripts and styles folders, which contain the JavaScript and CSS files used by the mobile app.

(Note: To learn more about how to create this application using Wakanda Studio and pre-package it to be accepted by PhoneGap, take a look to this guide and this blog.)

The HTML5 Interface

The HTML5 page is generated using the Wakanda Studio GUI Designer with the dragging and dropping of widgets and careful styling using the properties tabs. Below is an example of a Wakanda HTML5 interface in progress; lets go through the surprisingly-easy process of designing the interface for our mobile app.

Step 1

After installing the Wakanda Studio version 3, open the studio by double clicking its icon. Click on the “Create New Solution” button.

Step 2

Give a name to your solution e.g. “CreateHTML5Page.” Check the “Add a blank project to the solution” checkbox and click the “OK” button.

Step 3

Now, click on the “WebFolder” folder and double-click on the index.html file.

Step 4

Go to the right side of the studio; you will find an arrow to choose between platforms: desktop, tablet, or smartphone. Choose the smartphone page.

Step 5

At this step, the page is empty and should be designed using the widget tab on the left and the properties tab on the right. First, we will add a navigation widget to the page by dragging and dropping the desired widget onto the page.

Step 6

After that, we must add some views (navigation options) to the navigation views widget using the properties tab of this widget.

Step 7

Now, we will add a pair of buttons to the first view.

You could modify the button titles and other properties (width, height, color, etc.) using the properties tab on the right side.

Step 8

To specify an event to the button, we should click on the events button on the right side tab and choose the “onClick” event.

Step 9

For example, we could add code that allows switching between views. We will use the navigation view method “goToNextView”, so when we click on this button we will go to the View number 2. Look below for clarity.

button1.click = function button1_click (event)
{
$$("navigationView3").goToNextView();
}

(Note: To learn more on how to create a mobile web app using Wakanda Studio, take a look to this video for a step-by-step description of how to create and test mobile apps on an iPod.)

After creating a page, we should pre-package (prepare it to be packaged by PhoneGap build) it using the step-by-step described in this blog.

Retrieving Contacts Using the PhoneGap Contact API

The following JavaScript code will be executed when the “Get contacts from phone” button is clicked.

var options = new ContactFindOptions(), name, phoneNumber;
options.filter = "";
options.multiple = true;
var fields = ["name", "phoneNumbers"];
function onSuccess(contacts) {
var res = "";
for(var index = 0, len = contacts.length; index < len; index++) { name = contacts[index].name; name = name != null ? name.formatted : ""; phoneNumber = contacts[index].phoneNumbers; phoneNumber = phoneNumber != null && phoneNumber.length > 0 ? phoneNumber[0].value : "";
res += name + "   : " + phoneNumber + "n";
}
$$('textField2').setValue(res);
navView.goToView(3);
}
function onError() {
alert('onError!');
}
navigator.contacts.find(fields, onSuccess, onError, options);

For more details about this code, take a look to the PhoneGap contact API.

Package the App Using PhoneGap Build

This video will show you how to package the web app, starting by uploading the .zip file to getting the .ipa file. For the complete description, we’ll start by downloading the .zip file offered at the beginning of this article and unzipping it.

Take the “Client_Side” folder within the .zip file and zip it to get the desired input file for the PhoneGap build service.

You should have an account on PhoneGap build to upload and build the application, so if you don’t have an account yet, you could create one.

After creating an account, go to the apps page, upload the zip file (Client_Side.zip), and build it! Look below for clarity.

Setting Up Server-Side Elements

For the server-side application, you should take the “Server_Side” folder and run it on Wakanda 3 Server, using a command line or Wakanda Studio. The command line is:

“C:Wakanda Server.exe” ”C:Download the applicationServer_SidegetPhoneContact SolutiongetPhoneContact.waSolution”

After that, you should go to the “Client_Side” folder, and within the “scripts” folder, open the index-smartphone.js and add the IP address of the machine where you have hosted your Wakanda application on the following lines:

WAF.config.baseURL = "http://@IP_of_the_Wakanda_Server:8081";
WAF.core.restConnect.defaultService = 'cors';
WAF.core.restConnect.baseURL = "http://@IP_of_the_Wakanda_Server:8081";
WAF.onAfterInit = function onAfterInit() { // @lock
// @region namespaceDeclaration// @startlock
var documentEvent = {}; // @document
var button2 = {}; // @button
var button1 = {}; // @button

Now, you could access the Wakanda DataStore remotely using the WAF API.

(Note: To build the .ipa for your iPhone, you should provide a provisioning key and the password of your Apple store account.)

Conclusion

This application is a simple demonstration of Wakanda Studio, as well as a much greater testament to the capabilities of HTML5, JavaScript, and CSS3 for the creation of powerful mobile apps. Using the process of development used in this example (from HTML5, JavaScript, and CSS to native app), we could deliver a cross-platform native mobile application in very little time, so by using PhoneGap, a developer with little background in Java or Objective-C can start developing native mobile apps for many mobile platforms simultaneously. Developing this application, testing it, and packaging it using PhoneGap build took be less than a day’s work.

Build a Currency Converter with jQuery Mobile and Cordova: Finishing The App

Aurelio De Rosa — Tue, 05 Mar 2013 16:42:54 +0000

In the previous part of this series, I showed several other functions of the functions.js file, highlighting their key points. In this sixth and final part, I’ll describe the last function left and the Cordova configuration file that we will use to set properties for our project and define several directives for the Adobe PhoneGap Build service.

Initializing the Application

First, within the index.html file, I’ll attach the function, initApplication()—which I’ll describe in a few moments—to the deviceready event, which is fired when Cordova is fully loaded.

$(document).one('deviceready', initApplication);

Once started, the function translates the multi-language written copy described in Build a Currency Converter with jQuery Mobile and Cordova: Translation and Conversion Logic, calling the translateMainPage() function if the user’s preferred spoken language is available. Then, it calls the openLinksInApp() function to manage external links, as described in part 5. These two actions are independent from the rest of the application, even if the device doesn’t satisfy the requirements.

translateMainPage();
openLinksInApp();

After running the two operations mentioned above, “Currency Converter” tests the device against the requirements (discussed in part 4), and if they aren’t satisfied, it disables the “Convert” button and exits the function.

if (checkRequirements() === false)
{
  $('#submit-button').button('disable');
  return;
}

Now that the basic operations have been executed, we can run the other and more heavy (actually, they’re not really that heavy) functions. So, to give the user a feeling that something is happening behind the scenes, one function displays the loader widget. Then, it continues updating the interface, filling the two select boxes with the stored currency values by calling fillCurrenciesSelection(), the function to update the rates, updateExchangeRates(), and the final function that updates the labels by reading the date and time of the last currency exchange rate update, updateLastUpdate().

$.mobile.loading('show');
fillCurrenciesSelection();
updateExchangeRates();
updateLastUpdate();

At this point, all the necessary processes have been called, and we need to attach handlers to some of the pages’ elements and events. The first handler will update the rates as soon as the online event is fired. The latter, as you may guess, fires when a Cordova application detects that it’s connected to the Internet.

$(document).on('online', updateExchangeRates);

The next handler is very important, since it’s the one the execute the money conversion and because it’s attached to the “Convert” button. After it has retrieved the values of the money and the two currencies selected from the interface, it calls the convert() method of the Currency class to made the conversion calculation. Then, it calls the numberToString() to localize the result based on the user preferences and injects the end result into the page. Finally, it updates the app settings with the last currencies chosen by the user.

$('#submit-button').click(function(event) {
  event.preventDefault();
  // Convert the value
  var result = Currency.convert(
    $('#from-value').val(),
    $('#from-type').val(),
    $('#to-type').val()
  );
   // Localize the result
   navigator.globalization.numberToString(
    result,
    function(number)
    {
      $('#result').text(number.value);
    },
    function()
    {
      $('#result').text(result);
    }
  );
  // Update settings
  var settings = Settings.getSettings();
  if ($.isEmptyObject(settings))
    settings = new Settings();
  settings.fromCurrency = $('#from-type').val();
  settings.toCurrency = $('#to-type').val();
  settings.save();
});

Having finished the “Convert” button functionality, we can now move on to the “Reset” button. Its behavior is quite straightforward. If the user clicks it, we set the input field for the money to convert and the conversion result to zero. We also reset the last chosen currencies by changing the selected currency types for both the select boxes to the first currencies listed.

$('#reset-button').click(function(event) {
  event.preventDefault();
  $('#from-value').val(0);
  $('#form-converter select').prop('selectedIndex', 0).selectmenu('refresh');
  $('#result').text(0);
});

The last handler we need to put in place is for the “Update data” button—the one at the top-right of the main screen. The attached function simply tests for an Internet connection, and if it’s found, runs the updateExchangeRates() function. Otherwise it notifies the user that it’s not connected to the Internet.

$('#update-button').click(function(event) {
  event.preventDefault();
  if (navigator.network.connection.type === Connection.NONE)
  {
    console.log('The connection is off. Can't update exchange rates.');
    navigator.notification.alert(
      'Your device has the connections disabled. Can't update exchange rates.',
      function(){},
      'Error'
    );
  }
  else
    updateExchangeRates();
});

Now that all of the pieces are in their place, we can hide the loading widget from the user so that they’ll know that that all background operations are finished.

$.mobile.loading('hide');

As a conclusion of the whole discussion, here is a screenshot of our “Currency Converter” app:

Create the Cordova Configuration

Since we’ll use the Adobe PhoneGap Build service to package our project, in order to set its metadata (the version, the name, the author, and so on), we’ll use a configuration file called config.xml. Explaining the format in detail is outside the scope of this article, but I’ll highlight the main concepts and focus on the important tag. To have an in-depth look of what you can do with this file, you can read the official documentation page.

The cited file follows the W3C widget specification and must reside in the root of the project files, at the same level as the index.html file. The root of the whole document is a tag that has several attributes, but the mains ones are id (the unique identifier of the app) and version (that specifies the version of the app). Inside the tag, you can include several elements:

name (required): Specify the name of the application. It doesn’t have to be unique.
description (required): Specify the description of your work. This will be shown in the app’s marketplace listing.
author (optional): The app’s author. Unfortunately, you can only specify one author, so you can’t have details for multiple authors.
icon (optional): The icon to display on the devices that will install your app. If you do not specify it, the Cordova logo will be used.
feature (optional): Specify the features you want to use. Some operating systems, before installing the app, ask the user to provide permissions for those features. In “Currency Converter”, the only required feature is access to the Internet connection.
preference (optional): A set of preferences you want to apply, such as the Cordova version, to use when packaging the project.
splash (optional): This tag sets the splash screen of the application—the image to show while it’s loading.

The tag is very important because, citing the documentation, it provides your app with access to resources on other domains—in particular, it allows your app to load pages from external domains that can take over your entire webview. Recalling what we discussed in the section “Managing External Links” of the previous part, in order to open the external links in the Cordova WebView, we must add them to the app whitelist. Using the tag, you have several ways to add links. In fact, you can specify each link you want to add individually. Consider the following example:

For each of the above approved domains, you can also include all the subdomains using the subdomains attribute:

Since our app won’t retrieve links from external and unsafe sources, we can shorten the process allowing for any external resource using the * special character like the following example:

Now that I’ve pointed out the key points of the format, you can understand the source of the configuration file of our project. The complete file is below.



   Currency converter
   Currency converter is a simple app that helps you convert from a currency to another. You can update the exchange rates anytime you want so you'll have always an up-to-date conversion.
   Aurelio De Rosa

Conclusion

I have to compliment those of you who completed the whole series. The growing number of hybrid apps released, including the one we just built, prove that you can build amazing games and utilities using web technologies that you’ve already mastered. There are pros and cons in choosing to develop a hybrid app, but this is definitively one additional tool in your development tool belt. My last contribution is giving you the link to the Currency Converter repository. Here you’ll find and download the full and ready-to-work package. For those of you that are too lazy to build the app, I have also created a public page where you can download the installer for every platform supported by the Adobe Build PhoneGap service. As a final note, Currency Converter is released under the CC BY 3.0 (“Creative Commons Attribution 3.0″) license.

I hope you enjoyed the series and have more comfort and confidence with hybrid apps. Thanks for following!

Build a Currency Converter with jQuery Mobile and Cordova: Rate Updates

Aurelio De Rosa — Fri, 01 Mar 2013 01:07:15 +0000

In the previous article in this series, I described the classes and functions needed to perform currency conversions within our app. I also illustrated the Cordova Globalization API and how we can use it to translate the written instructions on the main page of “Currency Converter.” In this next installment, I’ll show you the remaining functions of the functions.js file and a brief overview of the Cordova Connection and InAppBrowser APIs.

Utility Functions

Updating the “Last Update” Label

In the introductory article of this series, I explained that our project will store the downloaded currency rates so that the user can use the application offline. Since the currency exchange rates change every day, it’s important to notify the user of how old his exchange rates are. If he feels that they are too old, he can run an update and download the latest. For this reason, the main page has the following code:

Last update of exchange rates:

The having id="last-update" is where we’ll inject the date of the last update. Th date will be written in the format that best suits the user preferences determined by the Globalization API, which I explained in the previous article. Recalling the third article where we talked about the user settings, you should recall that we update and save the date each time the user request an exchange rates update via the Settings class and its methods.

The function that updates the text of the above tag is updateLastUpdate(), and its markup is the following:

function updateLastUpdate()
{
  if (typeof Settings.getSettings().lastUpdate === 'undefined')
  {
    $('#last-update').text('-');
    return;
  }
  // Show the last time the rates have been updated
  navigator.globalization.dateToString(
    new Date(Settings.getSettings().lastUpdate),
    function (date)
    {
      $('#last-update').text(date.value);
    },
    function ()
    {
      $('#last-update').text('-');
    }
  );
}

Updating the Rates

The method that deals with the actual updating is updateExchangeRates(). At the very beginning of the method, there is a test to verify whether the device is connected to the Internet or not. The test is done using the Cordova Connection API—an object that gives access to the device’s cellular and wifi connection information. It has one property called type that checks the active network connection that is being used and can assume the following values (as constants):

Connection.UNKNOWN
Connection.ETHERNET
Connection.WIFI
Connection.CELL_2G
Connection.CELL_3G
Connection.CELL_4G
Connection.NONE

If the device has an active connection, the function makes a call to the European Central Bank RSS feed to retrieve the rates using the jQuery ajax() method. Once retrieved, the rates are stored using the Currency class, and the lastUpdate data of the user’s settings is updated as well, so the user knows that they’re working with the latest currency exchange rates.

The two select boxes and the “last update” label of the main page are updated using this current data. Then, the two select menus are filled using a function called fillCurrenciesSelection(), which I’ll describe in a few moments. As a final note, if the rate update fails, the user is notified with an alert of this failure shown using the Cordova Notification API.

So, what exactly will happen if the first test fails? Well, if the device does not have an active Internet connection, the app will check if there are any stored rates. If there are no stored currency exchange rates, the user is notified of the issue, and the “Convert” button is disabled, because there aren’t any ways to run any currency conversions.

The code that implements this functionality is listed below:

/**
 * Update the exchange rates using the ECB web service
 */
function updateExchangeRates()
{
  if (navigator.network.connection.type !== Connection.NONE)
  {
    $.mobile.loading(
      'show',
      {
        text: 'Updating rates...',
        textVisible: true
      }
    );
    $.get(
      'http://www.ecb.int/stats/eurofxref/eurofxref-daily.xml',
      null,
      function(data)
      {
        var $currenciesElements = $(data).find('Cube[currency]');
        // The EURO is the default currency, so it isn't in the retrieved data
        var currencies = [new Currency('EUR', '1')];
        var i;
        for(i = 0; i < $currenciesElements.length; i++)
        {
          currencies.push(
            new Currency(
              $($currenciesElements[i]).attr('currency'),
              $($currenciesElements[i]).attr('rate')
            )
          );
        }
        currencies.sort(Currency.compare);
        // Store the data
        for(i = 0; i < currencies.length; i++)
          currencies[i].save();
        // Update settings
        var settings = Settings.getSettings();
        if ($.isEmptyObject(settings))
          settings = new Settings();
        settings.lastUpdate = new Date();
        settings.save();
        fillCurrenciesSelection();
        updateLastUpdate();
        $('#submit-button').button('enable');
      },
      'XML'
    )
    .error(function() {
      console.log('Unable to retrieve exchange rates from the provider.');
      navigator.notification.alert(
        'Unable to retrieve exchange rates from the provider.',
        function(){},
        'Error'
      );
      if (Currency.getCurrencies().length === 0)
        $('#submit-button').button('disable');
    })
    .complete(function() {
      $.mobile.loading('hide');
    });
  }
  // Check if there are data into the local storage
  else if (Currency.getCurrencies().length === 0)
  {
    console.log('The connection is off and there aren't rates previously stored.');
    navigator.notification.alert(
      'Your device has the connection disabled and there aren't rates previously stored.n' +
      'Please turn on your connection.',
      function(){},
      'Error'
    );
    $('#submit-button').button('disable');
  }
}

Filling the Select Boxes

The function to update the select boxes isn’t very hard to grasp. It simply retrieves the stored currencies using the getCurrencies() method of the Currency class and then insert each of them using the jQuery append() method. It’s worth noting that after all the currencies are inserted, this function searches for the last origin and destination currencies saved within the user preferences If these last used currencies are found, they are automatically selected. In this scenario, the listview widget needs to be refreshed, which accomplished using the method selectmenu() and passing the string refresh to it.

The complete source of fillCurrenciesSelection() is listed below:

/**
 * Use the stored currencies to update the selection lists
 */
function fillCurrenciesSelection()
{
  var currencies = Currency.getCurrencies();
  var $fromCurrencyType = $('#from-type');
  var $toCurrencyType = $('#to-type');
  // Empty elements
  $fromCurrencyType.empty();
  $toCurrencyType.empty();
  // Load all the stored currencies
  for(var i = 0; i < currencies.length; i++)
  {
    $fromCurrencyType.append('
' +      currencies[i].abbreviation + '
');
    $toCurrencyType.append('
' +      currencies[i].abbreviation + '
');
  }
  // Update the selected option using the last currencies used
  var settings = Settings.getSettings();
  if (!$.isEmptyObject(settings))
  {
    var currency = $fromCurrencyType.find('[value="' + settings.fromCurrency + '"]');
    if (currency !== null)
      $(currency).attr('selected', 'selected');
    currency = $toCurrencyType.find('[value="' + settings.toCurrency + '"]');
    if (currency !== null)
      $(currency).attr('selected', 'selected');
  }
  $fromCurrencyType.selectmenu('refresh');
  $toCurrencyType.selectmenu('refresh');
}

Managing External Links

As you’ve seen in the interface design of “Currency Converter”, the aurelio.html file have several external links within it. Those links aren’t very useful, but I do need to explain an important concept.

Until a few versions ago, Cordova opened external links in the same Cordova WebView that was running the application. So, once it opened a link, when the user clicked the “back” button, the last project’s page was shown exactly as it was before the user left it. But, in the most recent release of the framework, this behavior was changed; now, the external links are opened by default using the Cordova WebView if the URL is in your app’s whitelist. URLs that aren’t on your whitelist are opened using the InAppBrowser API.

Citing the official documentation, the InAppBrowser is a web-browser that is shown in your app when you use the window.open call. This API has three methods: addEventListener(), removeEventListener(), and close(). The first allows you to listen for three events (loadstart, loadstop, and exit) and allows you to attach a function that runs as soon as those events are fired. The second method, as you might guess, is used to remove a previously-attached listener. Finally, the close() method is used to close the InAppBrowser window.

If the user opens a link that is shown in the InAppBrowser or the system browser and then goes “back” to the application, all the CSS and jQuery Mobile enhancements are lost. This happens because the external link doesn’t the reference the cited files and when the user goes back into the app; the file is loaded as it were requested for the first time, but without passing through the main page. Obviously, this is something you’ll want to avoid, which highlights the importance of the the whitelist within the Cordova configuration file and the next function come in help.

The aim of the openLinksInApp() function is to catch the clicks on all the external links (recognized by using the target="_blank" attribute), preventing the unwanted default behavior and opening them using the window.open() method. As you’ll see in the code shown below, I’ll use the _target parameter so that the links will be opened using the WebView, because I’ll put these URLs in the Cordova whitelist. Using this technique, we’ll avoid the issues described above, and your app will continue to look and function as expected.

/**
 * Open all the links as internals
 */
function openLinksInApp()
{
   $("a[target="_blank"]").on('click', function(event) {
      event.preventDefault();
      window.open($(this).attr('href'), '_target');
   });
}

Conclusion

In this article, I described several other functions of the functions.js file, highlighting the key points of each. I also explained the Cordova Connection and the InAppBrowser API and how they work. As we’ve seen, dealing with external links is extremely important when you’re using jQuery Mobile to build your mobile app interface. In the next and final article in this series, I’ll show you the function that initializes the application, called initApplication(), and the Cordova configuration file that we will use alongside the Adobe PhoneGap Build service to package our “Currency Converter” app.

Understanding Responsive Web Design: Responsive Imagery

Annarita Tranfici — Wed, 27 Feb 2013 17:34:32 +0000

In this fifth part of our Understanding Responsive Web Design series, I’ll show you one of the typical problems that a web designer faces when building a responsive website: the management of the images. As you’ve seen so far, the challenges that a mobile designer faces are numerous, and it’s not so strange or unusual to think that one of the biggest is serving multiple image formats to multiple screen sizes. There are currently three strategies that a developer can choose when it comes to responsive imagery: he can choose between: “fighting” the browser, “resigning” himself, or relying on the server. Let’s try to understand the advantages and downsides of each option.

Fighting the Browser

Most front-end developers choose to apply the first strategy and fight the browser. What does “fighting the browser” stand for? It means doing your best to give the “right” image (that is, the image that has the correct size for the device used to view the website) to the browser so that it can be loaded before the browser had downloaded the “wrong” one (that is, the “default” or the desktop version of the image). This is an increasingly difficult task, as modern browsers and ever-quickening bandwidth means that users try to download images as quickly as possible.

Resigning

Sometimes the simplest and most comfortable strategy is the only viable option: admit defeat. Generally, this approach involves loading the default image onto small screens, and secondly, if necessary, loading a larger image for screens with larger dimensions. While this method is easy and straightforward, it’s not recommended, because in the second case, two requests are sent to the browser when only one is necessary.

Relying on the Server

The third strategy involves the use of the server, a server-side programming language and some basic forms of detection to determine which image to load. All of the logic is executed before the browser is able to see and interpret the HTML code. Unfortunately, this strategy has its own flaws: the act of maintaining an ever-growing list of mobile devices and screen sizes would become very complicated and require constant upkeep.

To help you understand better what this technique does and how it can be used, let’s consider an example. In the following example, I’ll show you a few lines of PHP, but don’t worry, you don’t have to me a PHP expert to create responsive images, and you’ll understand the example even if you haven’t worked with PHP before. Let’s assume that you’re creating a page dynamically and that you’re injecting an tag using the following line of code:

echo '';

As you might already know, mobile connections aren’t nearly as fast as their desktop counterparts. So, to speed up the rendering of your page for mobile devices, you’d like to inject a lightweight version of the image if the user is using… perhaps an iPhone. What you can do server-side is check the user-agent that made the request and—if the device was an iPhone—inject the smaller image. The next snippet demonstrates this technique:

if (strpos($_SERVER['HTTP_USER_AGENT'], 'iPhone') === false) {
  // Not an iPhone
  echo ';
}
else {
  // An iPhone
  echo ';
}

As you can see, the method is very easy to implement, however this approach isn’t very reliable because the user-agent information itself isn’t 100% reliable. If the method fails, you could have some glaring problems with your imagery.

Is One Method Better Than The Others?

Obviously, each approach has its own unique advantages and limitations, and it’s unlikely that one single method will be the ideal choice for all of your mobile projects. However, there are some additional techniques and resources that a developer may use to create responsive images.

Sencha.io Src

The first option is very fast and simple. It is a service developed by James Pearce that returns the image you choose to load resized to fit your exact needs. Its name is Sencha.io Src, and all you have to do is put the Sencha.io Src URL location of your image as the image’s source.

The service uses the user agent string of the requesting device to determine the desired image size and resize the image accordingly. By default, the image is scaled to 100% of the width of the screen. Sencha.io Src has a high level of customization; it’s possible to set a specific width or any other parameter. For example, if you want to set the image width to 250 pixels, you have simply to add the size into the URL as follows:

The service also caches the request, so the image will not be reloaded each time the page is loaded.

Adaptive Images

A similar solution is proposed by Matt Wilcox. It involves determining the size of the screen first, and then creating (and caching) a scaled version of the correct image dimensions. This is an ideal technique to make the images of an existing website responsive. After downloading the code (which you can find at adaptive-images.com), to make this solution operational and running properly, you need to follow three simple steps:

Add two files, .htaccess and adaptive-images.php, to the root folder;
Create a cache folder and allow write permission;
Add the following line of Javascript code at the beginning of your document:

Thanks to this one line of code, the screen resolution is captured and stored in a browser cookie. It’s possible to configure multiple options in the file adaptive-images.php, but the primary purpose of the file is setting the variables for the resolutions ($resolutions).

$resolutions = array (800, 480, 320);

These resolutions are the “breakpoints” of images based on the screen resolution (a width to be measured in pixels). In this case, This tool will serve out a small, mobile-friendly image for devices with a pixel width of 320 or smaller. If the display exceeds 320 pixels, the new reference value is 480, which is the next numerical value in the array above.

Once created, the images will be stored in the cache folder (where you can change the filename), so that you will no longer need to generate them.

In addition to what I showed, I want to highlight that the key point of the discussion on adaptive images concerns their size. This is certainly an important factor, but we often forget that it is not the only one. For example, resizing an image for smaller displays often reduces the impact and the recognition of the image. In these cases, it may be necessary to modify the image. Even a simple cropping of the edges or of the superfluous elements can help the image retain it’s impact and significance at a smaller size.

Conclusion

In this article I described three ways to work with with images from a responsive design point of view. The first is fighting the browser—that is, doing your best to give to the browser the “right” image to download. The second is choosing services like Sencha.io which use the user agent string of the device from which the request is sent to understand screen size and resize the image accordingly. The last involves to adaptive images—in this case, the developer only needs to determine the size of the screen and the image will scale to accommodate.

In conclusion, between the three approaches discussed above, the one of the adaptive images is probably the best solution as it requires no dependency to another site or link. In the next articles in the series, we’ll examine other methods that a developer can use to manage all the images of a responsive website.

Want to learn more about Responsive Web Design? Check out SitePoint’s new book, Jump Start Responsive Web Design!

5 Essential Elements of a Successful Business App

Kyle Sanders — Mon, 25 Feb 2013 18:10:57 +0000

The ever-growing population of smartphone owners has led more and more companies to develop mobile business apps to cater to customers and generate leads. What used to be an optional “nice to have” mobile component is now becoming an essential part of any business, regardless of industry. But, to build a great mobile presence for your business, you need a lot more than just the realization that you need an app or the decision to build it. Many poorly-conceived small business mobile apps end up as nothing more than an expensive novelty.

If you don’t take time to develop a fully-functional, properly-planned app that offers real value to users, all of your efforts will go wasted. We’ve learned some important lessons through creating countless mobile apps for small businesses; here are the five essential elements that play pivotal roles in the building of successful business apps.

A Professional Developer

The first thing your mobile app needs is a professional developer. It’s tempting to view mobile development as a commodity—it’s not. Seeking the lowest price for your development (and ending up with the lowest quality) can result in major headaches, glaring software glitches, and brand damage. You should never try to cut corners and costs by hiring someone with little experience in mobile application development. Professional, seasoned developers know the ins and outs of mobile operating systems, version control, optimization, best practices, and the latest web technologies. With a veteran (or veterans) working on your project, you’ll be assured a mobile app that’s a strong benefit to your business instead of a frustrating hindrance.

An Adequate Budget

You can’t start the development process without an adequate development budget; having a half-built app and no funding to finish is arguably worse than having never started. You’d be amazed at just how complicated it can be for a developer to breathe life into what initially seemed like a simple design. The process often involves a designer, a project manager, and input from executives, marketers, and salesman. You have consider all of the moving parts of your design and how much it will cost to incorporate all of the multifaceted needs of each stakeholder. If your budget is not enough to cover these development costs, you might not be able to make your app as functional as you wanted it to be, and both customers and stakeholders could end up disappointed.

Original Content That Will Keep Your Customers Coming Back

You are not going to have thousands of customers lining up to download your app—even if it’s free—unless you have something truly valuable to offer. Many businesses expect a lot of exposure from their app without a real investment into the app’s content. Others make a substantial commitment of content upfront, but then consider the app a completed project instead of an ongoing project. Neither is a good long-term strategy for maintaining and leveraging a mobile app to benefit your business. You’ll want a steady stream of special offers, updates, or other reasons to revisit your business app.

A good litmus test of your app’s appeal is to simply play the role of the prospective user. Ask yourself why you’d notice the app, why you’d want or need it, and what would cause you to keep it on your mobile device’s small screen and limited storage. If you struggle with the answers, you may want to remedy the problem with original, valuable, regular content updates.

Careful Branding to Grab Your User’s Attention

You will need to find ways to grab your user’s attention the first time they load your business application. Clever loading screens and new user tutorials are a great way to do this, but you need to make sure you do not go overboard with your introduction efforts. Mobile users are inherently busy multitaskers; you never want to keep them from their purpose without good reason. You are not dealing with a captive audience; Users can leave your app or turn off their phone at a moment’s notice. You’ve already won the competition for their attention and gotten your app installed on their device; offer them some carefully-designed welcome messaging that’s just as easy to use as it is to bypass.

Loading Indicators that Keep Your Users in the Loop

There is nothing more frustrating than trying to navigate through an application just to be directed to a blank, unresponsive screen. One of the first thing your users will think if you do not have loading indicators is that the application is frozen or malfunctioning. Loading indicators and animations let your users know that the app is fully-functional, working, and waiting on your phone’s network or hardware to respond. A process indicator might be even more useful, because it tells the user how much of the process has been completed and the specific steps involved. This may sound like a small, inconsequential addition to an app, but in the minds of many users, it’s the difference between a buggy, crash-prone app and a snappy, responsive, user-friendly one.

Conclusion

“We need a mobile app” is just the beginning of your planning process. You need to take time to think about what you want your users to accomplish and how you design to suit their needs. Do not cut corners during your design, development, funding, or testing—your shortcuts will likely be noticed in a very public way. But, if you test your app thoroughly, design it thoughtfully, and keep the essentials in mind, it will be a valuable asset worthy of your time, investment, and brand.

Do you have any essentials to add to the list? Have you worked on mobile projects that lack thorough planning? Do you have any hard-earned development lessons to share?

Build Menus in Android with Java and XML: Contextual and Popup Menus

Abbas Suterwala — Fri, 22 Feb 2013 12:32:41 +0000

In the previous article in this series, we learned how to create standard options menus for your Android app using XML or built directly through Java programming. Besides these typical options menus, Android developers can also create specialized menu types such as the contextual menu and the popup menu within their Android apps.

A contextual menu is a menu which affects (or appears on) specific items and generally has options that affect only that particular item. The contextual menu in Android appears when a user presses and holds on a specific item. The contextual menu will be presented to the user, and he or she will be able to choose from the array of options.

Android also lets you create popup menus in your application. A popup menu is a modal menu that can be programmed to appear when a button is clicked.

In this article, we are going to demonstrate how we can create contextual and popup menus within our Android apps.

Registering the View for Contextual Menus

To start, we are going to build a basic example by creating a contextual menu on one single item. A contextual menu is created within a view, so we will register that view for the contextual menu first and then move on to the menu itself.

Bu, lets first create an Android activity within layout main.xml file as follows:



Username"
android:layout_width="fill_parent"
android:layout_height="60dip"
android:text="Hold For contextual menu"
android:padding="4dip"
/>
ffffff"
android:layout_width="400dip" >

In the above layout, we have just created one TextView and one edit view within the layout. Now, we’ll write the code for the activity is as follows:

package com.contexualandpopupmenudemon;
import android.os.Bundle;
import android.app.Activity;
import android.view.Menu;
import android.widget.EditText;
public class ContextualAndPopupmenuDemo extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
EditText UserNameEditText = (EditText)findViewById(R.id.usernameEdittext);
registerForContextMenu(UserNameEditText);
}
}

In the activity above, we have overridden the onCreate method in which we have set the main layout. Then, we find the EditText using the function findViewById.

Once we get the EditView, we call registerForContextMenu on that view. This function registers the view and allows us to display a context menu.

Creating the Contextual Menu

Once we have registered the view for a contextual menu, we will create a menu in XML for our contextual menu. To create a menu in XML format, create a contextual.xml file in the menu folder of your resources. Add the following code to your contextual.xml file:


Username" />

In our contextual menu, we have created two items: one to acquire usernames, and one to check for duplicates. Once we have created the menu in XML format, we will have to override the onCreateContextMenu function as follows:

@Override
public void onCreateContextMenu(ContextMenu menu, View v,
ContextMenuInfo menuInfo) {
super.onCreateContextMenu(menu, v, menuInfo);
if (v.getId()==R.id.usernameEdittext) {
getMenuInflater().inflate(R.menu.contextual, menu);
}
}

In this code, we determine if the ID of the view is the specific one we are looking for. If it is, we initiate the menu as described in the previous article in this series.

Now, if you hold for a few seconds on the EditText, you should be able to see the following contextual menu:

If you don’t want to build this menu in XML, you can build an identical menu in Java using the following programming:

@Override
public void onCreateContextMenu(ContextMenu menu, View v,
ContextMenuInfo menuInfo) {
super.onCreateContextMenu(menu, v, menuInfo);
if (v.getId()==R.id.usernameEdittext) {
menu.add(0, 1, 0, "Fetch New Username");
menu.add(0, 2, 0, "Check For Duplicate");
}
}

Now, if you run the app again, you will see a very similar menu to what we created through XML formatting.

Responding to Clicks on Contextual Menus

To respond to user selections on our contextual menus, we must implement the onContextItemSelected function within our activity. To respond to our menu items, we implement the onContextItemSelected as shown below:

@Override
public boolean onContextItemSelected(MenuItem item) {
switch (item.getItemId()) {
case R.id.fetch:
showToast("Fetch Clicked");
return true;
case R.id.check:
showToast("Check Clicked");
return true;
default:
return super.onContextItemSelected(item);
}
}
public void showToast(String message) {
Toast toast = Toast.makeText(getApplicationContext(), message, Toast.LENGTH_SHORT);
toast.show();
}

In the programming above the menu item that’s chosen is passed to the function onContextItemSelected, and we can call getItemId to identify which menu item was clicked. Then, we call the appropriate function (that matches the user’s choice) to handle this menu click . Currently, the only functionality that results from selecting a menu option is a toast with a message. So, now if you click on the “Fetch New Username” option, you should see the following:

Creating a Popup Menu

A popup menu (supported only after Android API level 11) is a modal menu that you can create and display near a view. For demonstration purposes, we will create a popup menu when an “Options” button is clicked on the activity. First, let’s add this “Options” button to our layout.xml file, as shown below.

This will create the necessary “Options” button for our popup menu. When selected, the function CreatePopupMenu will be called. Then, we create a new popup.xml file in our res/menu folder with the following content:

In our popup.xml file above, we have created two menu items: option1, and option2. Then, we add the function CreatePopupMenu to our activity using the following programming:

public void CreatePopupMenu(View v) {
PopupMenu mypopupmenu = new PopupMenu(this, v);
MenuInflater inflater = mypopupmenu.getMenuInflater();
inflater.inflate(R.menu.popup, mypopupmenu.getMenu());
mypopupmenu.show();
}

Above, we create a new PopupMenu object and then include our popup.xml menu within it. Then, we show the popup menu by calling the show function.

So, now if we run the app and click on our new “Options” button, you should be able to see the menu shown below.

Responding to Popup Menu Clicks

To respond to popup menu clicks, you have to set a menu item click listener, which is a class that implements the OnMenuItemClickListener interface. It has one method in it—onMenuItemClick. We will implement this interface in our activity itself. So, we must change the class definition as follows:

public class ContextualAndPopupmenuDemo extends Activity implements OnMenuItemClickListener{
Then we change CreatePopupMenu and implement onMenuItemClick as follows
public void CreatePopupMenu(View v) {
PopupMenu mypopupmenu = new PopupMenu(this, v);
mypopupmenu.setOnMenuItemClickListener(this);
MenuInflater inflater = mypopupmenu.getMenuInflater();
inflater.inflate(R.menu.popup, mypopupmenu.getMenu());
mypopupmenu.show();
}
@Override
public boolean onMenuItemClick(MenuItem arg0) {
switch (arg0.getItemId()) {
case R.id.option1:
showToast("Option1 Clicked");
return true;
case R.id.option2:
showToast("Option2 Clicked");
return true;
default:
return super.onContextItemSelected(arg0);
}
}

In the function, onMenuItemClick—depending on the menu item clicked—will display the appropriate toast. If we click on one of the menu options, we should see the toast shown below.

Conclusion

In Android, you can create a wide variety of menus for various settings and circumstances. You can define those menus in an XML file, or you can add them via java code directly. You can respond to the menu items depending on the type of menu (contextual, popup) you have created. When you offer application-wide settings, you should typically use the “Options” menu. If you want to offer specialized options or settings for a particular item, then you probably should use the contextual menu.

For the contextual menu to appear, the user has to hold for some time on the desired option. If you want to show a menu on some other user action such as a click of a button or tapping an image, you can use popup menu for that purpose as well. Regardless of your app idea or the functionality that you have in mind, you now have the tools needed to capture user input and build a sensible, intuitive app experience. Have fun while implementing these various menu types in your next Android app.