Responsive webdesign

2013 is the year of responsive web design (RWD). But what is responsive web design and how can we use it?

Not even five years ago almost everyone was browsing the Internet with laptops or a desktop computer. The life of a web developer was relatively easy, from 800x600 till 1900x1440 screen sizes you needed to cover but not much more. You could create a totally static page with just one set of layout rules and everybody would be happy, and every browser would display the page the way you made it.

Today however, people browse from thousands of different devices, from phones to tablets, Eee pads, laptops, computers and even iPods. All of which have different screen sizes. This drastically changed the web development approach, introducing media queries and a new way of designing websites: responsive web design.

What is responsive web design?

Responsive web design is a design approach with which we try to create one website for all devices. The basic elements of responsive web design include a fluid grid concept, flexible images and media queries.

Fluid grids

A fluid grid is a grid of elements usually divs, that all have proportional sizes (percentages instead of pixels). When all the elements of the grid have their width and or height proportional to the size of the screen it scales on all devices. This is already a nice thing, though we should also make sure that the content of the grid is resizes as well.

Flexible images

​If there is something to be flexible then this is in the first place the images we use. Flexible images are images with their width in percentages instead of pixels. Usually they have their width to 100% of their container. This way the image will never run outside its boundaries. Drawbacks can be though that the image becomes too large on HD screens, resulting in a pixelated appearance. Or the image becomes so small on small screens that it becomes useless.

Media queries

With media queries in CSS you can apply specific CSS rules only when certain conditions apply. You can for example create a media query on Max-Width. 

@media screen and (max-width: 600px) { img{ width: 100%; }}

Now the image on this site will appear 100% of the container width if the screen width is smaller or equal 600px. If the screen is larger, the image will not have the 100% rule. This way we can for instance make a web page with an image and a few lines of text appear on small screens like:

And on big screens like:

This we can do with the Media query max-width, and by setting "float:left;" for the image.

We can also use media queries for a whole css stylesheet. To do so we need to add the media query declaration in the head of the html file.

<link rel="stylesheet" media="screen and (max-width: 600px)" ...

We can do many more media queries so to adapt our design for all kind of devices.

On this site from CSS-Tricks you can find a nice list.

Text in responsive designs

Text in responsive websites can give problems. For instance the text might be too big for the container that holds it. To solve those problems we can make sure that the containers height varies depending on the text, but sometimes this is not what you want. If you want to keep the restrictive height the only solution is cutting the text nicely and making sure the whole text can be seen in another way. A solution could be a "more" button for example that enlarges the container when clicked.

Clipping the text we can achieve by applying the following css rules:

overflow:hidden;

text-overflow:ellipsis;

The first rule makes sure the text is not visible outside the container, the second line makes sure that the clipping of the text is rendered like "...".

This can also be handy with titles in headers for example. If the title on a mobile phone header is too big,  it is usually not a problem whether the text is clipped. If the text is not clipped however it will run out of the header and might break the style of the page below.

An introduction to Android 2d Game Development

Ever wondered how you could develop a game in Android? Do you need to start from scratch with OpenGL and code the wheel yourself?
No you don't have to do that, instead you can use a vast improving engine written for you: AndEngine.

We as app developers at Van Stein & Groentjes use this engine in most of our interactive Live Wallpapers (like the GolfLive Wallpaper) and in some of our games (HoverRace). As a small contribution to AndEngine developers team We'd like to explain a little bit how it works and to give you some tips and tricks.

To set up a new AndEngine project the best thing to do is follow a tutorial from: AndEngine Forums.
I recommend to use the Eclipse environment and specifically the one android offers with ADT.

When you followed these tutorials, set up your new game project and when you linked the AndEngine libraries to the build path of your project we can start with the code.

Scenes and cameras.
First of all let us explain something about the structure of OpenGL in general.OpenGL uses scenes. A scene is basically what you think it is. Every level in a game is a scene. Just like on the movieset, in every scene you have a setting or world in which your game takes place and a desired flow of events. To navigate in a scene, OpenGL uses a camera, this camera is usually centered around the main character/object in the game, and as it moves the camera moves with it. Below is an explanation of these two elements and their relation to each other. Every level, menu, movie etc can be seen as a scene.

Camera size can vary depending on the goal you have. For example if you have a game in which a character can walk and can run, you might want the camera to `zoom out' when the character is running such that the player can better see what is coming.

In your gameactivity .java file we need to implement several functions.

• public EngineOptions onCreateEngineOptions()
• public void onCreateResources(OnCreateResourcesCallback pOnCreateResourcesCallback)
• public void onCreateScene(OnCreateSceneCallback pOnCreateSceneCallback)
• public void onPopulateScene(Scene scene, OnPopulateSceneCallback populateSceneCallback)

onCreateEngineOptions()

This method is were we define the options to the game engine, the options are for example that we want to run the game fullscreen, in landscape mode and with a resolution policy of 1024*800 and that we use a particular Camera object to look at the scene.
In code that looks like:

return new EngineOptions(true, ScreenOrientation.LANDSCAPE_FIXED,
         new RatioResolutionPolicy(CAMERA_WIDTH, CAMERA_HEIGHT), this.mCamera);

Where this.mCamera is a camera object of the AndEngine Camera class.
You can use a fixed camera but also dynamic camera types like a boundCamera is possible. A boundCamera object can follow entities on the scene.

onCreateResources(OnCreateResourcesCallback pOnCreateResourcesCallback)

The second method that we run into is the loading of resource files. If you want to create a game you need graphics usually. In AndEngine you can load an image by using TextureAtlas and TextureRegion objects.
A texture atlas is a big texture map where you can define several texture regions that you want to use in your game. The advantage of using a TextureAtlas object is that you only have to load 1 image that contains all the images you need. This image is loaded into memory and the AndEngine can then take what it needs from this image by selecting texture regions..
We initialize the texture atlas objects like:

BitmapTextureAtlas mTexture = new BitmapTextureAtlas(this.getTextureManager(),2048, 512, TextureOptions.BILINEAR_PREMULTIPLYALPHA);

With this code we initialize a texture atlas of the size 2048x512 and with the texture option BILINEAR_PREMULTIPLYALPHA. This option has effect on how an image is scaled if it needs to, and determines how the color values are calculated. After defining the texture atlas we need to load the atlas into main memory. We do so by calling the load() function.

mTexture.load();

Now we are ready to load our images into texture regions:

mTextureRegion = BitmapTextureAtlasTextureRegionFactory.createFromAsset(this.mTexture, this, "sky.jpg", 0, 0);

With this line of code we load an image from the assets folder that is called sky.jpg and probably contains some cloudy artwork. We load this image at the top left corner of our TextureAtlas (0,0). If this image is 20x20 for example, we can load the next picture in the same atlas at coordinates (21,0).
After we are done loading all the images we have to let the engine know that we are done and want to move on with the rest of the work, we do this by calling the callback function.
pOnCreateResourcesCallback.onCreateResourcesFinished();

onCreateScene(OnCreateSceneCallback pOnCreateSceneCallback)

In the onCreateScene method we define the scene of our game.

Scene scene = new Scene(); //Create the scene object
Furthermore we can define a heads up display (HUD) and attach it to the camera.
HUD MainHud = new HUD();
mCamera.setHUD(MainHud);

In the HUD we can add images and controls that will not move if the camera moves and is always drawn on top of the scene.

After we created our scene object we can tell the engine what the scene is in the callback.
pOnCreateSceneCallback.onCreateSceneFinished(scene);

onPopulateScene(Scene scene,
    OnPopulateSceneCallback populateSceneCallback)

In the onPopulateScene function we can populate our just made scene object. The main building block that we can use is the Sprite object. Sprites are basically just image objects that we can draw on the screen and manipulate.We define a Sprite as below:
Sprite mSprite= new Sprite(300, 400, this.mTextureRegion ,this.getVertexBufferObjectManager());

The object is initialized with a specific TextureRegion (sky.png in our case) and with specific X (300) and Y (400) coordinate values. Depending on your camera, the object will be placed at 300 pixels from the left and 400 pixels from above the top corner of the screen (if the camera matches the screen).
Once we have loaded a Sprite we can either attach it to the scene or to the HUD with:
scene.attachChild(mSprite);
or
HUD.attachChild(mSprite);

When we are done populating the scene we can call the callback function to tell the engine we are done.
populateSceneCallback.onPopulateSceneFinished();

Now you have created your first 2D project using AndEngine!

Tips & Tricks

• Never use images bigger than 2048x2048, harware acceleration does not support it.
• Reuse variables that you use every screen update instead of creating new ones, memory management in java relies on the garbage collector and unfortunately this is slow.
• Try to use images with a power of two size with their own textureAtlas, this reduces the change on glitter.
• Check out the awesome extensions that exist for the engine!
• For animated images use animated sprites. AndEngine has some cool functions to display a select part of an image.
• AndEngine can take care of most of the worlds physics (gravity etc) So don't reinvent the wheel.

Hardware Acceleration in Android

Beginning in Android 3.0 (API level 11) we have the option to enable hardware acceleration.
Now what is hardware acceleration and why should we use it?

Hardware acceleration means that we use the GPU to do the drawing work instead of the CPU. The views on canvas will be exported to textures that will be drawn to the screen by using OpenGL libraries. This process is much faster then drawing them by using the CPU, however also much more memory consuming. Loading the OpenGL libraries takes 2 to 8 MB of main memory, if we eat even more memory by using large images or a lot of objects then on phones with limited memory we run into problems.

Because of the memory consumption Android does not allow images larger than 2048x2048 to be used during hardware accelerated events. Note that the actual image size might be even smaller since the image is first transformed to a texture, it is wise to not use images above 2000x2000. This means that if you want to work with larger images coming from camera's for example, you have to disable it.

Hardware acceleration can be switched on globally for the entire app in the manifest file.

<application android:hardwareAccelerated="true" ...>

But you can also enable it per activity and in the near future per window (not supported yet though), which would be more preferable since most applications would not profit from accelerated hardware in the main menu for example.

Crossplatform apps and hardware acceleration

In HTML5/JS cross-platform apps made by, for instance Phonegap/Cordova, hardware acceleration can improve the app significantly.
If we create a simple webapp with jQuery mobile and run it using Phonegap on a phone, we see that the transitions between pages are a bit staggering, the scrolling is not smooth and the reaction time is a bit slow, even on high-end phones.
Now we enable hardware acceleration and run the same app again. The transitions look amazing, scrolling is super smooth and the app reacts in no time!
 

In short: Hardware acceleration is an awesome new feature that Android 3.0 and above offers, but only use it when needed.

Are html5/javascript apps the future?

Nowadays html5 / javascript apps can be found a lot on the internet.
Also on mobile platforms as Android and iOS, html5 apps appear in the markets more and more often. The question is are these webapps the future or are they too limited and slow?


Webapps for mobile phones.
We can make webapps for mobile phones with the help of Phonegap/Cordova. Phonegap gave us the ability to convert our webapps into applications for mobile phones. Although applications made this way are noticable slower then native made applications, and they cannot acces all native features (yet), they are developed easily and can be used on all platforms without the need to rewrite code.

With libraries like jQuery Mobile you can create a nice looking app for Android and iPhone without the need to know anything about Objective-C or Android Java. All you have to do is write a web application in your favorite editor, test it in the major browsers and then with the help of Phonegap convert it into a native application.

So for mobile phones webapps are doing better and better. There are some advantages and some disadvantages. Lets create a little list.

Advantages:

•  Easy to develop
•  No knowledge needed in Java / other native language
•  Crossplatform

Disadvantages:

•  Slower
•  Less native features

Now lets look at the disadvantages. Slower many people say, yes this is true a native application is faster then a html5 app and this will always be the case, you cannot make a faster app then doing it native. Though, new phones have faster and faster cpu and load html5 apps so fast that you almost see no difference with native apps.

Less native features, it is true that even by using phonegap you cannot access all native features from every device with the same html5 / javascript code. But, luckily here we can use phonegap plugins.
A large collection of already made plugins can be found here.
With phonegap plugins you can basically connect your javascript code with native code. This makes the options endless! Although it seems that the whole effect of crossplatform html5 apps is gone when you still need to implement native plugins. For now though this is a good solution for the few things that are not available yet in html5/javascript apps.

Webapps for desktops
In desktops webapps are not common and well used at the moment rather then by using a browser to go to the webapp. With the coming of Windows 8 this will already change quite a bit. Windows 8 will support webapps and even let users sell them in there kind of appstore. It is easy to convert your own webapp for Windows 8 with Visual Studio 2012 for windows 8.

Now I hear you say, If I don't have windows 8 (and there are also many reasons not to have it), I can not execute my webapp? You can!You can create an executable for windows, Linux or Mac OSX in seconds with appJS. This little tool simulates a localhost browser with your webapp inside. You can specify settings like title, screen size and others in the javascript file in the zip folder you can dowload from their website.

So now we can make webapps for internet, mobile phones / tablets and desktop PC's!
Are webapps the future? I think they are, although sometimes you cannot go without native.

We ourselves are working on a totally crossplatform product with an approximate release date of Januari 2013. Check our site to find out more.