DailyWorkLog - a new ipad app!

Hi guys,

I've spent a few hours (days) putting together an application to manage my tasks daily on my ipad. Far from being a simple todo list manager, this app is calendar based and day centric. It's something between a calendar and a todo list manager. Though, it's neither of these! Please check it out on the app store, it's free for now: DailyWorkLog

I'll provide the direct link as soon as Apple have accepted it.

If you find a bug, please email me at the following address: twingocerise (at) gmail.com or add comment on this post.

Android browser jumping up and down!

No, you haven't gone crazy. Your beloved app is jumping up and down on android when you type something on the keyboard! ..... I had the problem 2 weeks ago when I was dealing with an input field in an absolute div. The problem came from another div in the page (fixed)  ... Believe me or not, this a z-index related problem. The rule seems to be: a fixed div have to have a higher z-index than ANY absolute div in the page.

So, find out the higher z-index of the page and set a higher number to the z-index of your fixed divs. This should stop the screen from jumping around for no reason.

Android web view - Inputfields refuse to work properly!

Today, another funny adventure developing HTML/CSS applications for android... I built a simple application called wrapper that people can install on their device to run our HTML app. This wrapper is very useful as it can be deployed to the market place so that potential users can find it. This application consists of a simple Webview pointing to our service (a public URL basically). This seems quite straightforward from an developer perspective and you'd expect this to run straightway but... we experienced weird stuff (for a change...)
In the HTML app, we've got a login pop up with 2 fields (login/password) displayed on top of the page when the use clicks the big login button in the app. It seemed to be working fine in the device browser but not in the wrapper...(?!) The input fields were properly focused when the user taped on them though the device refused any input from the keyboard. Mmmmm... Doesn't sound good really...

Well, let's be honest, in this very case there is not a lot of options. I unluckily googled the problem and nothing interesting came out... So, I rolled my sleeves and broke down the HTML page to an absolute minimum in order to reproduce the bug and... I got to the source of the problem! Hence the following rule someone should send to Google so that they can fix the bug:

If in your page you've got a fixed positioned div with none-default positioned nested divs (i.e. absolute, fixed, etc.) any of the following absolute positioned div containing input fields will get the unexpected behaviour.

So, how can we fix it now? Actually, there is no real fix from my point of you as this is unsupported valid HTML/CSS but here's some ideas for you:

• Use static positioning inside absolute or fixed divs in your page. This is good practice anyway as this is easier to understand and lighter for the phone to render. Most of the time you can position your elements using extra divs + margin/padding auto, width %, etc.
• Put absolute divs containing input fields before the fixed div containing extra funny positioned divs (or put the fixed positioned divs at the end of the page if possible)
• Don't use fixed positioning if that's possible for you - this mostly depends on the client doesn't it?

Hopefully this will work. Please don't hesitate to comment on this as obviously I'd enjoy some feedback from you guys... Speak soon!

Sencha touch - wow!

You might have heard about Sencha touch and you might be thinking: is that something for me? Good question. The other day I was asked to build a prototype very quickly in order to sell a new app to a client. I had 2 days and I didn't know how to get this done so quickly. Well, I had a look at the frameworks available and I picked up Sencha touch. In my views, Sencha touch is a very good framework for prototyping:

• It's easy to pick up
• It's all front-end and runs nicely without an app server or a servlet container, etc.
• It's phonegap compatible
• You get all the nice components and the native feeling out of the box
• You can easily hardcode everything - which is what you'd expect when you are prototyping
• It's very slick on iPhone and iPad

Though, it's got a fair few drawbacks which makes me think it might not be the right framework for a full-blown complex application: 

• It's all Javascript and Javascript is a pain
• Customisation could be painful as you've got loads of styling going on already
• It seems quite CPU heavy for the phone
• It's far from being slick on Android and Blackberry
• The code can get messy if you don't put safeguards straightaway
• The code is not compiled which means you need more QA - and they will bump into low-level bugs as developers might not spot them straightaway

So, in my views, Sencha touch is the way to go if:

• Your app is iOS only
• Your app hasn't got dozens of screens
• Your app requires native feeling
• Your app doesn't need a lot of customisation

OR if you only need to prototype a few pages.

Where do you stand? Did you develop a full-blown complex app with Sencha touch? With hindsight, what's your opinion?

Gwt and Blackberry OS7 don't play well together

If you ever wonder why your GWT app doesn't start on a blackberry OS7, you might be experiencing the same problem I had a week ago. I spend a couple of hours investigating and basically, if you try to perform a Integer.parseInt, it fails miserably. Nothing in the logs, nothing in the console, etc. Debugging the JS gwt code I found that it's checking on the min/max value of an int. And guess what? OS7 browser doesn't support them. That looks like a dodgy bit overflow problem... I put a little test case together on StackOverflow for you to understand the problem. Here's a copy of it:



<html>
  <body>
    test page
    <script>
          i = 0;
          if(i < -2147483647) {
             alert("very low")
          } 
          if(i < -2147483648) {
             alert("very very low")
          } 
          if(i < -2147483649) {
              alert("very very very low")
          }
     </script>
  </body>
</html>


Surprisingly, the phone comes up with the message "very very low".

So, solutions are:

• Don't use Integer.parseInt - use Long.parseLong instead or something like that - well... that might be acceptable for some people...
• Override the Integer class and change the parseInt method to check the value on a bit less than -2147483648 - or enforce the use of a long.
• Hope and pray that RIM will fix it asap... and that everybody updates... 

Hope that helps.

ShareProj - a mobile project!

Big news! I'm starting an open-source project! It's a social-network aiming at sharing information on projects. The user will be able to connect via various channels such as iPad, iPhone, Android tablets, phone browsers and desktop browsers.
The potential users are people working on projects from different locations / companies. As usually it's quite complicated to give feedback to clients / ask for feedback to a supplier, this could make a few people's life easier.
Bear in mind that the project's first goal is to get me learning things and sharing this with others developers. If it happens that people are interested in the features and want to use it, I'll try to put a roadmap together. For time being it will be highly dependant on my free time and imagination. Feel free to join the fun! :)  

Technologies are the following:

• Spring / RESTful webservices
• Objective-C with UIKit on iOS
• Java on Android
• HTML5 / CSS3 in browsers - possibly jQuery touch to ease development

Speak soon.

HTML manifest: Desktop Browser vs Mobile Browser

HTML manifest files are a hot topic. It’s powerful, convenient and easy to implement but they come with a lot of new rules you have to bear in mind when using them. Let’s keep it simple for the moment. First here’s a very simple thing for you to remember when you use manifest files on a mobile phone: A mobile browser is not a desktop browser. Even if that goes without saying, this means a lot to the way we can develop and distribute mobile web apps. J

A manifest file is used in a mobile web application to create a consistent set of files your app runs from. These files are cached locally and the phone doesn’t need any network connection to run the app. But what happens if a file is requested but not part of the manifest bundle?

The browser can try and get the missing resource from the server if there is one, therefore creating a connection. This would ask the user to connect to the network if he is not and come up with either the file, a 404 or connection error. This would trigger a fair few annoying pop-ups every time you use the app in the tube. I have to say this proactive approach is good when you have a reliable and permanent connection like on desktop browsers. And they seem to behave just like this.

On a phone it’s a different story. Most of the mobile browsers went for another option: fail fast. Nothing happens and your file is considered missing even though it’s available on the server.

This leads me to one simple fact: your mobile app might run just fine on a desktop browser but might not work at all on your phone. This means that you should test on mobile browsers as early as possible! It’s convenient to test against a desktop browser but never forget the target.

Cherry on the gateau, implementation of the manifest files are not flawless on handsets:

• iOS 4 / 5 and Android seem to be working-ish. Though, I had to force the manifest to expire straightaway to make sure it’s checked against the server at every startup. On Tomcat, you can use an expiryFilter for that.
• Blackberry OS6 and Nokia S60 V5 don’t seem to support anything but offline web apps. I haven’t managed to get the manifest file being checked against the server at every startup. It seems like once it’s got a manifest and the associated set of files, there is no way to update it apart from deleting the cache manually from the browser options.

So, if you are considering using a manifest in a mobile web app, consider your real needs and the platforms you’re targeting. This will save you massive headaches. If what you need is JUST caching images, don’t snob off-screen caching…