HTML5 Databases & Palm Pre Development

Recently I have been working on a Palm Pre project in the Obtiva Studio. A feature arose where we needed to know if the user had arrived in the application (or at a certain page with in the application) for the first time. After doing some searches we discovered that the Palm Pre supports HTML5 which allows for some pretty awesome database setups and calls.

So here is what our code looks like:



We needed to use this code at two different places on the application and so pulled it out into it's own class. The initialize function does just what you would think it would do, and the beginning of the new interesting stuff is on line 4

this.db = openDatabase("Database Name", "1.0", "Display Name", 10000);

This openDatabase command is a new HTML5 window method, so it starts to get interesting. This method takes 4 things:

1. The database name: here brillantly named, Database Name (I didn't say it had to be interesting)
2. The version of the database: 1.0
3. The display name: Display Name (again....interesting naming isn't the game)
4. The estimated size in bytes of data that will be stored in the database: 10000

Now, we move on to some more interesting things, and what to do with this now opened Database. We need to note if the user has been at that particular page in the past, and if they haven't then they need to see different information than a user that's been around the block a few times.

The two things we did were to call a transaction on the database object and then execute some SQL statements on that transaction. All the interesting happens in these lines:



In general to execute the SQL you do this:



Where the function(tx,result){} is going to hold the action of what you want to do if the SQL instructions passed and likewise the function(tx, error){} will hold the instructions of what to do if your SQL fails. In our case the error actions are just logging the error messages while the successes are dealing with figuring out if the user has been to the page before.

We didn't get any deeper into the HTML5 database things, but being able to create databases and check for users on the fly was a fun and exciting find.

Don't Mix Your Mocks!

Yesterday while pairing with Jake Scruggs we came across the strangest problem. We added in some tests for a new component that we were adding, and were going to check the new code in. And what do you do before you check in boys and girls? That's right! You run your specs. So we run the specs and all of a sudden there are two failing tests. Wait....what? Those tests aren't even near anything we changed

So we did the poor man's roll back by commenting out every line of code that we had changed, and ran the specs again. Still two failures. We did some rubber ducking with Dave Hoover, who tried to just comment out the failing specs. We ran the tests again...Now there were 8 failures. What the What? Commented those back in....and now we have a total of 10 failures. We had everyone on the project get up to date and run the specs. Every single person had a different number of failing tests.

It came down to the fact that somehow we had two different mocking frameworks in place. We had some rspec tests, and we had some mocha tests. They lived in harmony for a long time and then all of a sudden...KABOOOOM. The tests looked like they were trying to overwrite class methods and so I guess the two different fameworks started bumping heads. We moved everything to the rspec mocking model and everything was back to playing nice.

So. In short. Make sure you keep an eye on what mocking framework is being used in your project and stick with it. Strange erros indeed!