Since quite a while now we're developing a NIWEA based app for one of our clients. If you don't know what NIWEA is you can read our
earlier blogpost.
It was a very interesting new challenge. At first I thought cool, now I can use all the fancy HTML5 and CSS3 things I read so many articles about. Later I realized that creating a native-looking app with just web technologies is not all sunshine.
There are a few issues you may experience that are typical to webapps. These concern:
- - Rotation & Calculation issues
- - App Resume
- - Offline availability
- - Singlepage Problem
-
Rotation & Calculation
Whenever you rely on winHeight for your overlays, widgets, flyouts or lightboxes you will run into trouble. This caused by the constantly changing window height in iOS.
There are 4 possible states you need to be aware of:
- - URL bar hidden
- - URL bar out
- - URL bar overlapping (during a request)
- - Carrier bar overlapping in Add2Homescreen (standalone) Mode
-
All those situations may occur in landscape and portrait mode. Therefore there are 8 different heights & widths you need to be aware of and test your calculations with. Now you could just hardcode values for those 8 possibilities but that's not a good plan if you also want to support Android, WebOS and Win7 Phones.
A generaly good advice is to use :
window.scrollTo(0, 1)
before you're doing any calculations that rely on winHeight. This will hide the scrollbar and reduce the possibilities.
When you're in standalone mode you can just subtract 20px from your winHeight and add 20px padding to your content div.
if (true === window.navigator.standalone) {
winHeight -= 20;
Y.one(#content).setStyle('marginTop', '20px');
}
Rotation
All the places where you use calculated values need to be rotation aware. That means whenever the device rotates, you need to recalculate. This is best done by listening to the orientationchange event. Most devices also fire the resize event, but in my experience it didn't prove very reliable. Sometimes the phone is too busy and it doesn't fire any event at all. This bug has been resolved in iOS 5.
Singlepage
Whenever you're in standalone mode and click on a link, it will open in Safari. I'm not sure what Apple thought was the use of that but it's one of those problems you just need to fix.
To avoid this issue you can create a CSS class that is applied to all links that should not open in Safari. Add a delegate event handler that is listening to all click events on those elements.
Whenever a link is clicked, prevent the default behaviour with e.preventDefault(); then extract the URL and request the content through Ajax. That way Safari does not open.
Another workaround is to do POST's with hidden forms. This is helpful for logouts or other things you want emediate redirect and don't want to wait for the Ajax response to bounce back.
App Resume
We're used to multitasking and we expect apps to stay in the same state as they were when we left them. This works great if you use your NIWEA App inside Safari. In standalone mode it works different. Whenever you close or switch to another app, iOS forgets about the state of your app. Once you relaunch or switch back it will reload the entire app. Not on the last active url but on the url it was bookmarked too. The solution to that problem is simple. Whenever you request an url in your Singlepage code, put the last active url into localStorage. Once the app relaunches, check if a url is in localStorage before loading the starting page. This makes it necessary to have a so called loader Seed which is a construct that holds the navigation elements but loads the content after the initial load is done. The loader seed is also helpful if you want your app available offline.
Scrollviews
There are some nice libraries to make a scrollable div for mobile devices. You might ask yourself why not just do overflow: scroll. It does indeed work, but you will have to scroll it with 2 fingers. One of the most famous library is iScroll.
If you don't care for iOS 4 there's a very easy alternative called overflow scrolling:
.scroll-x, .scroll-y {
-webkit-overflow-scrolling: touch;
}
This will allow you to have the element scrollable with 1 finger.
Offline availability
The concept how we solved the offline concept would enlarge this blogpost way to much. I already described what we did there on
my blog. If you're interested
check it out there.
Tools
Simulator
The obvious one is the iOS Simulator. It comes in very handy when you need to check your application on iOS 4 and 5. You can easily switch between versions and devices. Also you can reset the entire device. This is very useful if you want to clear the cache and the local database. The Simulator comes bundled with XCode. Once you've installed XCode, navigate to /Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone\ Simulator.app and put the App into your Dock.
iWebInspector
This tool allows you to inspect your html inside the Safari of your Simulator. You can change classes, edit markup and access the local databases. It's also possible to access the apps in standalone mode. Basicly you can do everything you can do in the Chrome Developer Toolbar.
Retrospective
All in all is it a nice challenge to develop NIWEA applications. It's nice to use new technologies and face problems that differ from the usual "it looks weird in IE" problems. But what you and your customer need to be aware of is that it's not going to be as fast as a native app out of the box and some things will need more time than in a native app. What you get in return are multi-platform capabilities with much less effort than the "traditional" native approach.
