Best practices? there is no such thing.

There's one thing everyone knows about Perl: There's more than one way to do the same.
And that, that same single thing, is viewed as a good thing for pro-perl people, and as a bad thing for anti-perl people.
There are obviously good ways to do something, and bad ways. There can be better ways. But there's no way a single way should be the best.
Perhaps, and only perhaps, there could be a best known way to do something. Perhaps Bresenham's algorithm was the best one to draw a line, until a better one came. Which is the best one nowadays? Well, it depends on the lenght of the line. And on the slope. And on the machine executing it.
I'm sick of hearing people preach of best practices to do something or the other where using these best practices means a much larger code to write, bloat, inefficient code, etc, while providing absolutely nothing better than a different way to do it. They sure are better in some cases, but not always. And when something is not always better, even if there is a single case of not being better, it's of course not the best.
Anyway, having a best something would, by definition, kill all innovation and improvements, because... how could someone even imagine doing something better than the best?

Managing complexity

Is never easy, and that's why so many people fail to do so correctly.
I've been somewhat forced to develop an application using a framework. I really hate this framework. Any little change, any tiny modification, anything which could be done in half an hour takes us days to acomplish. Why? because this framework is the wrong tool for our problem.
The framework was developed internally to solve one problem, and I hope it's right for that. But now a completely different team must use it for a completely different problem. And nothing works. Of course.
We don't know it, we have never used or even seen it before. We don't have documentation (because there isn't any, of course).
Most of our work is via trial and error. We also do some reverse engineering, and study the sources we have, and studying the sources is what makes me ill.
I can see how much work has been put there. How great attention to small details has been put there... for very concrete, special, narrow cases...
The moment where you try to do something slightly different than that which was expected... everything fails.
You want to filter your data? it's easy, you place that filter there and everything works automatically.
Ok. Now how do I put this other filter there?
what? which other filter?... well,  that was not thought of, it's not possible.

So, after spending days to try to know how something worked, when I want a slightly different solution... it's simply not possible. The only way? study the sources and replicate everything with the small changes required for the new specific case.

Hiding complexity for a specific case will never work. When will many of these high qualifications, high rank, high pay "software architects" realize they are doing it wrong?

adjusting your webApp to iPhone screen size still giving problems.

Well, the workaround I published here some time ago works perfectly on my test app.
Obviously, only when starting a real webApp do the problems present themselves.
The "real" webApp (so simple it even souldn't be called real) didn't have any header or footer. And neither any "content" as defined on my previous example. All content were some absolute positioned divs, and a background-image scaled to 100% of both width and height (that means that at least in one orientation it was distorted, but it was so by design).
Any of the hacks which worked for my test app produces unsuccessful results, but as I didn't want to place any empty placeholder divs, was short on time, and the webApp was designed to be added to the home screen and using all screen space, I left it as is, without hiding the navigation bar when in browser mode.
Some day I'll try to find some more answers about successfull iPhone screen size detection...

Developers, developers, developers

Anyone should remember the stellar actuation of Steve Ballmer reciting these words.
Developers were important for microsoft. Having developers tied to their platform meant software being written for it.
Well, now Microsoft is losing developers, while Apple is always winning more of them (I won't talk about GNU/Linux which is king supreme on the server side, but not yet on desktop).
Why is that? Well, many thing must be taken into account. The iDevices for example. There are many developers writing iPhhone, iPod touch and iPad applications. You only can do that from a mac, and once you have learned that (as officially most software must be written in objective-c using xcode) you are ready to easily write mac applications too.
Switching to intel architecture was a very very clever thing for Apple to do, because people have the possibility to run Windows on their macs too, either native via BootCamp or on a virtual machine. Many people were afraid of switching to a mac because they were relying on some windows software, which now they can use without problems.
But, the best... any developer who now uses a mac has their development environment ready, and free of cost. And when start to use it and step the learning curve of a new language, because objective-c isn't used much outside of the mac world, they start to appreciate the beauties of Cocoa, the heir of Next.
Let's be clear, Microsoft has done some wonderful things too, but when you have to deal with the absurd complexities of a system which was, in theory, designed to hide them... you find that something isn't working as it should.
If microsoft is losing developers which are going to other platforms, there's noone to blame more than the own Microsoft. They are doing things difficult for their own developers, while others have been trying sine years to make averything easier, more clear and more confortable for them.
Microsoft, you are slowly but steadily loosing points there. If you want to rise again, you know what you need: Developers, developers, developers...

Tips: Adjusting your webApp to iPhone screen size.

On mobile webApps, we should care a lot about screen space, because it's very limited.
My test app consisted on a fixed positioned header, an optional fixed positioned footer, and a scrollable content. I wanted it to fill the whole screen space, of course, both in portrait and landscape mode.
As anyone knows, it's possible to hide the navigation bar on iPhones's safari, and that gives us 60 extra pixels. That's a lot. But there's one thing... the navigation bar can only be hidden (it's really scrolled up) when the content is larger than the available screen space.
I thought... on orientationchange event I must only read window.innerHeight to get the total window height, adjust my div sizes, and hide the navigation bar. Fail
window.innerHeight reported the available window height considering the navigation bar was there...
Easy then, first I hide the navigation bar, and then read window.innerHeight. Results?
When switching from portrait to landscape mode everything was right. But when switching from landscape to portrait it wasn't.
Of course, when switching, the content height was the total height in landscape mode, 300px (the always present top status bar is 20 pixels height), and of course it wasn't enough to scroll the navigation bar up. What to do?
Easy. First, set the content height to screen.height (which is always 480 in the iphone) so it is high enough. Then, hide the address bar, and once hidden, set the right height depending on the window.innerHeight (which will be 460 in portrait mode when the navigation bar is hidden, the whole screen.size minus the 20 pixels of the status bar which is always visible).

Don't fear reinventing the wheel.

It's considered one of the most popular mistakes between programmers. Reinvent the wheel. Again and again programmers are constantly reinventing things. It's a big waste of time, and usually the resulting code is of a much lower quality than "wheels" which have existed for a long time, which had most of their bugs solved, which have been used and abused for all kinds of things...
But there are exceptions. Some times, reinventing the wheel is useful. Sometimes we don't need an overengineered wheel. We don't need the fast wheel for a formel-1 car, we don't need the strong wheel of a  big transport device, we need a simple, small wheel which just can carry our luggage. In that case, simplicity over all, our own wheel, although technically worse in many aspects, can be good for our project.
And of course, there is a time where reinventing the wheel has a clear advantage: learning. There is no better way to ler how a wheel works than reinventing it (even though after doing that we can see that existing wheels are better than our, but then we can use them with knowledge of doing the right thing).

More experiences on mobile(r) webApp development

Any mobile webApp should be simple, and if it is mobiler, it should be simpler.
I really like iScroll, it provides native app like scrolling, it's really easy to use, and customizable enough, so after (well, while) using it for the iPad framework, I've decided to go mobiler. What's mobiler than the iPad? iPhone (and iPod), of course. Using it on a real device is always much better than on the simulator (as I don't have a real iPad).
I like it so much that I'll probably start writing my own real iDevices framework (with the experience obtained with the iPad one). If everything is well deigned, minimal code changes will be needed to support the diferent optimal layouts for iPad and iPhone (which includes iPod and android devices too).
If added to the home screen (on iPhone at least, don't know about iPad or android) and given the good performance of iScroll (which is no so good on android due to the lack of hardware acceleration) any webApp designed to take advantage of offline operation and local databases can be made indistinguishable from a native application.