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.