First, create your meta element, be sure to add an id.

<meta id="viewport" name="viewport" content="" />

Now, add some simple JS to modify the value to whatever your conditional needs may be:

 
if (screen.width < 768){
     var vp = document.getElementById('viewport');
     vp.setAttribute('content', 'width=device-width,
     initial-scale=1,minimum-scale=1,maximum-scale=1');
}

(NOTE: line break added to attribute value for readability).

Ideally this should be setup with the javascript requirement on the phone side, as you are are much more likely to see javascript enabled on phones. However the other way around would still work.

This can also be achieved by using server side checks using something like wurfl to validate your target device, but since live modification of the meta tag is supported so effectively in the browsers we are targeting here, this is a much simpler solution.

Many products exist at varying levels of complexity for delivering a pre baked,  configurable dashboard for your business. The costs on these can go from moderate to exorbitant depending on what the end product delivers. However, for most platforms, in particular where BI is only a portion of what the platform is expected to deliver, the lower end of the spectrum of dashboard providers is where most businesses will end up considering. If you are in this realm, the reality of a roll your own product is potentially an option, and one that should be considered.

The first task to deal with has nothing to do with your dashboard deliverable. Before you can build chart one, you need a data warehouse, and even if the vendors you are considering offer the service of configuring your data warehouse for you, the best option for this critical piece of the puzzle is to build it yourself, with an on site contractor if you don’t have the skill set in your staff already. The reality is no one understands your data needs better than you, and handing off this portion of the work to a vendor doesn’t usually make sense unless they are entrenched with you for three to six months. And let’s face it, they won’t be unless your willing to pay, at which point a contractor makes more sense anyway. So before you even start down the reporting path, isolate your data in a properly designed warehouse, configure your refresh processes, and then you’re ready to move on to the dashboard itself.

There are many obvious reasons to go with an off the shelf solution, and a cursory glance at vendors’ websites will state clearly what you have to gain – mobile optimized reports, engaging charts, easily exportable data. And with a prepared internal team, ready to hand off that body of work to your vendor of choice, you can be up and running in a few months. But what happens next? who handles maintenance? If the vendor does, at what cost? If your team does, what about training? And what are platform upgrades going to cost you in the long run? Perhaps most importantly, what features does the platform lack, or goals does the vendor lack, that will hinder your business in the longrun?

For all of the reasons above, building your own dashboard is an option worth considering for lightweight solutions, and are inherently more agile. If you’re building SaaS products, you probably already have solid front and backend developers, so the dev skillset is at the ready. So, invest in some components and purchase a charting tool. There are many cutting edge HTML5 based tools out there to leverage. If your goals and team are the right fit, 2-3 dedicated developers can deliver a dashboard, custom to your needs, and expandable for your needs, within the same delivery window as an outside vendor. It’s more a matter of defining specs and solid project management.

It’s worth noting the risks associated with a custom build. If you find the need for an OLAP cube for example, the development gets much more complicated. Most important overall, as with any build, is a well educated team leader and project manager, and a clearly defined deliverable.

iOS6 features something that will feel like a bug to most web developers out there, but in reality is Apple trying to enforce a definition in the HTTP spec that has never been utilized before. See this on Stack Overflow:

http://stackoverflow.com/questions/12506897/is-safari-on-ios-6-caching-ajax-results

In regards to POST data, the HTTP spec defines this little gem:

“Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.”

Translation: your coded requests may never leave the browser, instead the browser will return whatever it got the first time it hit your server and never reach out again. Which completely defeats the purpose of whi ajax is used in most cases. Just when you thought resource caching was your worst browser nuisance, enter iOS6, where suddenly this is the default functionality. And without a hint of notice from Apple that I’ve seen to provide heads up that this change was coming, or more importantly why now.

Luckily, we can easily squash this wholesale. I just updated A5 to do this at its core, so none of your requests allow caching unless you specify so in the parameters of the request. All you need to do is one of two things:

1. Change your server side code to respond with a response header of cache-control : no-cache

or,

2. For a nice all encompassing fix of something you likely never planned for, wrap all your ajax requests in a handler that adds cache-control : no-cache to the request header. Problem solved.

One of the most frustrating use cases is from rogue IP requests – a server pings your web app, often in a way it is never meant to be accessed, such as an url that requires a logged in session for example, and subsequently it triggers an error in your app. So what are these requests, and where do they come from?

Crawlers are a common use case, and these are easily resolved with robots.txt rules and/or robots noindex metatags as described here. Another easily identifiable major source is virus scan firms. Trend Micro, for example, is well known (t0 those who deal with these issues) to log requests from some software products and cache them on servers that then track trust levels. To do this, those cached urls are then requested directly  from their servers in japan. IF you’ve seen IP’s hit your server from Trend Micro, this is why. They’ll indiscriminately hit your urls directly and trigger errors if the urls require user sessions. There are of course, many other potential sources of rogue requests. So what do we do about them?

One way to resolve the issue is to just block the offending IP’s. But this is potentially troublesome as it may both block real traffic accidentally and/or may affect how, in Trend’s case, your trust score is rated, and could also potentially block real traffic. One way to address the issue is to build some trust into your own app logic: validate IP’s. If a session is logged into by a user, the odds are pretty good that request isn’t a bot. So track the IP and flag it is a known IP of human users. Then, instead of blocking requests, simply filter the errors to only show from IP’s that have come up as trusted for urls that require user sessions.


<%@ page contentType="text/cache-manifest" %>CACHE MANIFEST
# rev 0
file.html


It’s important to keep CACHE MANIFEST on the same line as the contentType property – manifests are discarded if they don’t start from the first character with that declaration.

One last thing – this works better cross browser (where some browsers dont respect a manifest not ending in .manifest) by setting grails.mime.file.extensions to false, which will allow your mapping to be directly to cache.manifest, returning the rendered gsp.

Think about it RIM, for the greater good.

Thank you for your time.

Really, killing apps is the only reason to have the multitask bar anyway – since multiple instances of running apps isnt possible in iPhone OS, you could simply return to the running app by re-tapping the app icon on the home screen. The multitask bar exists solely for a shortcut to running apps and to kill them from running.

No more stressing in the blogs about apps being killed only by the OS! You do have control if you want it. Likely what Scott was implying is that you just don’t have to monitor it if you don’t choose to.