Patrick Mueller is the man behind the Weinre tool – remotely inspect and debug mobile web applications. Here is a video of him talking about Weinre at PhoneGap Day US 2012.
If you would like to know more about Weinre and how to debug mobile web applications I have a few post on it. You can start from here.
And if you do not like setting up Weinre and working with servers you can have a look at Adobe Shadow which is a tool developed by Adobe on top of Weinre, functions similarly but you do not have to set up the dirty part. You can start from here.
Here’s a sneak peak at the touch version of the Coverflow animation. The app is fully touch enabled, you can swipe across the screen to move the images or tap on any image individually to move it. The app works fine in iPhones, iPod touch and iPad’s. Have not tested it in Android 4.0 or greater. Since iOS browsers supports CSS3 3D transformations so it runs very smooth. In Androids < 4.0 it gives a horrible look n feel.
Here’s the link to the demo. Check in an iOS device (open up in mobile safari),
I had been updating my examples and tutorials off lately and trying to create a more general approach to application development – Write a single app that runs in mobile browsers as well as computer browsers. Following the same approach, this time I am updating one of my previous tutorials – 360 Degree Car/Product rotation for iPhones. So, I worked on a 36o degree car rotation code that runs in both mobile and desktop browsers.
This tutorial is an update to my previous one, I also present a new demo. I will not go into the details, which I have talked about in my previous tutorial. Have a look at the demo, open it in either an iOS browser or a computer web-kit browser.
Other than that just try the example link in a computer web-kit browser – Chrome/Safari or an iOS device browser which is also a web-kit browser. Android devices need some changes and the same code might not work. I have talked on this in my previous post.
I started mobile web development around eight months back and at times found it very difficult to debug my apps. Normally everybody would start off with a desktop browser, look up the app in a desktop web inspector and then try to debug it and finally make it ready for the mobile browser. Even I used to do the same. I used to check my mobile app in Chrome’s/Safari’s developer tools. There I used to inspect HTML elements, change DOM style properties and check the result out and also see the java script console log messages in the console tab. This would normally serve my purpose but I had to adjust a lot due to resolution differences. Still there was a frustration and a feeling of had there been a tool to directly debug the app in the mobile device itself. And after a little head scratching and Googling I discovered an open source package called Weinre – Web Inspector Remote. With Weinre I could debug my mobile web app remotely – the app would run on the mobile browser and I could modify the DOM remotely, see log messages of it on the Weinre inspector that runs on my computer. And I must tell you, it has helped me immensely. It’s a wonderful tool to have and in this tutorial I will share my experiences of debugging with Weinre. First I will start off with How to configure Weinre and then talk on debugging a mobile web app, but before that let’s see some basics – Weinre and its components.
Weinre is a remote debugger for web pages and if you are familiar with Firefox’s Firebug or Google Chrome’s Web Inspector, then you will find Weinre very similar. What it means is that you can debug a web app that is running on your mobile device remotely i.e on your computer. So, in your computer you can select any DOM node, make changes to style properties of the mobile web app and it will reflect in the mobile device on the fly. You will get more familiar with the things once I talk in details later in the article. First let’s see what Weinre is composed of.
Weinre consists of three basic components/programs – Debug Server, Debug Client and Debug Target interacting with each other. Let’s see what each of them means,
1. Debug Server: This is the HTTP server that you run from the weinre.jar file. It’s the HTTP server that’s used by the Debug Client and Debug Target. I configured the server on a Windows machine so all the steps I will talk about are in reference to Windows. For Mac users details of configuration can be found in the Weinre site.
2. Debug Client: This is the Web Inspector user interface; the web page which displays the Elements and Console panels, for instance.
3. Debug Target: This is your web page that you want to debug running on the mobile device – iPhone, Android phone or iPads.
Both the Debug Client and the Debug Target communicate to the Debug Server via HTTP using XMLHttpRequest (XHR). Typically, you run both the Debug Client and the Debug Server on your desktop/laptop, and the Debug Target on your mobile device. The image below should help you.
This tutorial speaks about a simple sliding touch photo gallery for iPhone. The app is meant to run on the mobile safari web browser. We start off by looking at a demo first and then talk about the code in details. Note that the same logic and implementation will work even on Android devices, you just need to correct the dimensions/positions and place the elements according to screen resolution.
The images used in the demo are not of great quality or appeal as I am not a Photoshop expert. Once you have cool assets you are good to go.
The demo is all about having two panels, one with the thumbnail images and the other panel with the corresponding bigger image of the thumbnail selected in the first panel. The two panels have been placed side by side – horizontally and they slide in and out of the viewport to give a sliding effect. The sliding of panels uses the same concept (using CSS3 transitions and transformations) that I discussed in one of my earlier post. Here in this tutorial I will not go into the details of how to create sliding touch panels. You can refer my previous post.Read More »
This is one situation which baffles me sometimes and I face this one regularly while developing mobile web apps – I want to know whether the device is held in portrait or landscape mode when the page first loads and then based on the result I change the look n feel. Remember landscape mode of the device is more wider and the screen width increases, so does the viewport width so you have to adjust your page layout accordingly.
I thought of writing this post due to increasing number of search queries that I found out on my site stats. A 360 degree product view for mobile web is important now as lot of manufacturers are starting to move towards mobile web apps for displaying their products.
In two of my earlier posts I have already talked about a 360 degree product view for desktop browsers with examples – post 1, post2. For the 360 degree to run on a mobile browser I had to make some adjustments – make the sprite much smaller in size, add touch gestures. The rest of the concept is same. So, in this post I will talk on how to make the 360 degree for iOS devices (iPhone,iPod and iPads).
I have already discussed about the core concept of changing the position of the background image (sprite image) with the movement of the mouse in my earlier posts. And how it detects the distance moved and the direction of movement and based on that the car is rotated. So I will not go into it once again. You can refer my earlier tutorial. I will just talk a little on the touch gestures and how to convert the already developed example (from my earlier post) so that now it listens to finger gestures on the mobile device.
Before moving further you deserve a demo, open the following link in your iOS device browser and drag your finger over the car.
The swipe gesture image gallery that we talked about in one of the earlier post had a strange flickering issue. There was a slight flickering of the image that was being swiped along with the movement of finger. I observed the flickering mostly in iOS devices – iPhone, iPod touch and iPad’s.
After a lot of head scratching and looking around in forums I finally got a solution. One of the guys (he is divine for me now) in StackOverflow suggested to add two lines of CSS to all the elements that moved using CSS3 transition. I tried it out and guess what, it worked!. I just added two lines to the CSS style for the images. This is what solved it,
#wrapper ul li img
Add this style block to the CSS file and the issue will be a gonner. The link to the fixed demo is below (I have merged the fix with the original demo. So there is no separate demo). Check out in an iOS device’s browser. Note that the demo’s run in an Android browser as well. But I observed the flickering in iOS devices only.
Also try removing the above CSS lines and checking out the demo again. You will notice flickering.
1) Images linked to URL – Now you can click or tap on the images to go to a URL. I have made a new post which describes the changes made. This was requested by one of the reader. I felt the importance of having the ability to link the images to URL so came up with an extension of this post. You can fine the post here. There is a demo and also a download link.
3)Circular swipe gesture gallery – I have a new tutorial where I have talked about a circular swipeable gallery. So the images keep on looping. The tutorial also includes a new demo. Read it here.
4) Auto scrolling gesture gallery – Sometimes users may want a auto scrolling gallery along with the normal swipe gesture feature. I have a new post with a demo. Read it here.
1) Coverflow for iOS with touch gestures: Sneak Peak at the touch gesture enabled Coverflow for mobiles(iOS) is ready. Have a look at it here. There is a demo and download link.
Back to the actual post:
Recently I worked on the famous Coverflow animation using CSS3 3D Transformations, and I must tell you that the results were very impressive. I was actually working on a mobile web version of the Coverflow animation meant for iPhone,iPod, Ipad. Well, I am still working on it and finishing on adding touch gestures to the animation.
Disappointingly, Android device’s web-kit browser does not support CSS3 3D animations as of now so the coverflow that I am trying to build is not working on Android devices. However, I read it somewhere that the next version-Android 3.0 will have support for it. So till then I could support only iOS device’s web-kit browser.
In this post I am presenting a desktop version of the Coverflow (no touch gestures). Right now it runs only in Safari. I must tell you once again that the app I built is mainly meant for web-kit browsers (since iPhone’s and Android’s run web-kit browsers). I have the link to the demo app below,
The demo has only 7 images as of now and the code has pre-defined values in it but it is fully functional. I am working on making it more dynamic so that any number of images can be used. I am finishing up on some nuances of the app and refining the code further, and till then I am posting only the demo. I will talk about the code in details later (very soon). Also I will come up with a part2 of this tutorial series where I will talk about the mobile version with touch gestures.
For the full code you can view the source of the demo.
Here are some of the features of the desktop version of the demo,
Click on any image to bring it to the center.
Use the previous and next button to see other images.
Image Reflections using CSS3 reflections.
CSS3 3D Transforms as I have already mentioned. This gives 3D look and feel.
Smooth movement of images using CSS3 Transitions.
Here I talk about writing a full screen mobile web app for iPhones/iPods (320 x 480). But similar concepts can be applied to any mobile device out there. Read the post below,
The main idea behind a full screen mobile web app is to hide the Address/URL bar so that the app looks like a native app and occupies the most of the space available within the browser window. Note that we are talking about a mobile web app and your app will run in the browser of your touch device.
Now, what is a viewport? Seems like a word that you might have heard before. Well, the actual visible area to the user that is available for the app is the viewport. Below is an image of my iPod’s mobile safari browser window in portrait mode. I have pointed out the labels and the sizes of each of the components. The dimensions are same for the iPhone as well. In portrait mode the resolution is 320 x 480 pixels. You can see from the image that in portrait mode the viewport is only 356px in height. The Status bar and the Button bar cannot be hidden from the user and will always be displayed. So, at the best we can hide the URL bar from the user to make the app look like a full screen app and give it a native feel.