Seiten

Wednesday, December 8, 2010

In the first part of this article I was talking about the problems when mapping date/time to a database table using Hibernate. In part two I will talk about the solutions.

The quick Way: Use Property Access Type and implement the Setter

Tell Hibernate to use setter and getter methods for field access, instead of using reflection to modify the entity object's fields directly. To do so, you have to put the Hibernate annotations above the getter methods, instead of the class attributes. You MUST move the annotation of the @Id field to the getter to enable property access. But you should do it with all field annotations, for better clarity. You can find a more detailed discussion of Hibernate property access here and here.
Once you did so, you can implement a setter method for the calendar field, which takes the calendar object provided by Hibernate, and creates a new object with the right time zone and date information from it:

Because the time zone information is the only thing that is wrong in Hibernate's calendar object, we simply create a new calendar object in the correct time zone, and then copy all required fields from Hibernate's object to our new object. The final call to getTime() will recalculate the calendars internal time milliseconds based on the field and time zone information. Unfortunately, the actual recalculation-methods are protected in java.util.Calendar for reasons I just don't know. So we have to use this less elegant workaround.

The elegant Way: Create a custom Hibernate User Type

If for any reason you cannot use Hibernate property access, you will have to stick to the advanced art of programming and create a custom user type, which does the mapping from DB result set to Java object for you. Explanation of user type implementation would be beyond topic of this article. But you can find a very good introduction here. Just be aware, that you have to create a mutable user type, as java.util.Calendars are mutable objects.
To put everything short, here is the user type implementation that will serve our purpose:

// we cannot do it like this, because it would initialize the calendar // in the jvm's default timezone: // Calendar cal = (Calendar) Hibernate.CALENDAR.nullSafeGet(resultSet, // columnNames); // return cal;

The nullSafeSet method will inject our Java object into the SQL statement. As Hibernate handles Calendars correctly when persisting, you simply delegate this task to Hibernate here. But since I'm using MS SQL Server in this example, I have to deal with the different precisions of Java dates (1 millisecond prec.) and SQL Server datetime types (1/300 second prec.). I choose the simple way here and simply cut the millis.

The nullSafeGet method does a little more of tweaking. This is where the result set is mapped to our Java Calendar object. If we would use Hibernate's built in mapping here (as in the commented block in this method), we would get the Calendar with the JVM time zone set. So we have to treat the datetime from the SQL result set as a string, and parse the date in GMT from it and create a new GMT GregorianCalendar.

Once we've finished our UsertType, all we have to do is to annotate our GMTDateEntity object to use it:

Friday, November 19, 2010

Go ahead to part 2 of this articleHave you ever tried to persist a date with Hibernate, which is supposed tobe in a different time zone from the one of the system your applicationis running on? I'm pretty sure that you will get into trouble whiletrying this. There's a number of obstacles to pass. Let's get them onone by one and figure out appropriate solutions.

The SetupI'm using JBoss 5.1 with Hibernate 3 and JPA for this tutorial. The data base isMicrosoft SQL Server Express 2008 with the JDBC driver fromsqljdbc4.jar. Both, JBoss and SQL Server are running on the samemachine in time zone Europe/Berlin with Central European Time (CET) asactive time schedule. We want to persist a Date to the data base wich shows up there in GMT time.We will need two Java classes. First there's the entity data object to bepersisted to the DB. As we want to persist GMT date records, it is calledGMTDateEntity:

Now let's persist a date object to the DB using our two classes. For this example I will create a java.util.Date representing the 9. November 2010, 12:00h GMT which we want to store to the DB. Now we do something like this:

What happened? The time is shifted by an hour! This is because java.util.Date stores dates in a time zone independent fashion, but for SQL data bases there dosn't exists the notion of time zone independent dates. You can store date records to a SQL DBMS only with a specific time zone. So what Hibernate does, is using the time zone schedule of its JVM (which runs in CET) to convert the time zone independent java.util.Date to the time zone specific date string in our DB record. Because CET is one hour ahead of GMT, one hour has been added to our DB date.Unfortunately, there exists neither an Hibernate or JPA annotation nor any other simple way to tell Hibernate in which time zone to persist java.util.Date objects. So if we cannot set the time zone schedule of our JVM to GMT, we must figure out other ways to tell Hibernate what we want.

2. Obstacle: Hibernate doesn't use Calendar's time zone for readingThe sensible way for attaching time zone information to dates in Java is the use of java.util.Calendar. So let's tweak our entity class a bit and add a Calendar field:

cal.setTime(date); entity.setCalendar(cal); dateTestDao.persistGMTDateEntity(entity);//Now read back what we persisted, and store it againGMTDateEntity readEntity = dateTestDao.retrieveGMTDateEntity(entity.getPk());GMTDateEntity newEntity = new GMTDateEntity();//just to be sure we set the time zone to GMT againreadEntity.getCalendar().setTimeZone(TimeZone.getTimeZone("GMT"));newEntity.setCalendar(readEntity.getCalendar());newEntity.setDate(readEntity.getCalendar().getTime());dateTestDao.persistGMTDateEntity(newEntity);

The DB now looks like this:

What the hell?! Obviously we got a Calendar out of the DB which is different from the one we previously stored to it! And that's true. When reading from DB, HIbernate creates a completely new Calendar object, and uses the system's time zone again for converting the date.

3. Obstacle: There are solutions, but it won't be easy!

Well, if you're as naive as I am, you might just shout out: "Of cause it didn't work! We didn't tell HIbernate about the target time zone of our entity class!" And then you would go and tweak the GMTDateEntity like this:

Just to shorten this: It will not work! Hibernate uses Reflection to set the entity's fields, and when it comes to do so, the date conversion is already done. So instead of asking yout entity's field: "What kind of time zone would be welcome, Sir?", it just creates a new Calendar instance in system's time zone and squeezes the DB date into it.However, there are some more complex solutions to this problem, which I will explain in the second part of this article.

Delete Picasa Account

Tap
the [Edit] button or swipe over an account horizontally to delete it.

Edit Picasa Account

Tap
the disclosure button to the right of an account to open the Edit
Account view.

Use Picasa Account for Upload

Tap
somewhere on the account name to select it for upload and open the Upload
Queue view.

Add Photos to Upload Queue

Tap the [+] button in
upper right corner to bring up the image selector. If there are no
images in the upload queue, yet, you can even simply tap somewhere on
the screen to bring up the
photo picker.

Choose the
photo/image you want to upload from the photo picker.

Once you selected a
photo from the photo picker, you can enter a photo caption and then tap
the [Add to upload Queue] button.

When
you're finished adding all desired photos to the upload queue, tap the
[Done]
button in the upper right corner of the photo picker.You can
add a maximum of 20 photos to the upload queue.

Remove a Photo from Upload Queue

Swipe over a photo horizontally to reveal the
[Delete] button.

Select Picasa Album to upload to

Tap the [Select
Album] button to bring up the Picasa Albums Selector. This is the time
when the app connects to Picasa and tries to log you in. All previous
steps you could even execute without an internet connection.

If you did not
save your account password, PicUpp will ask you to enter it here.

On
the Picasa Album Selector, use the picker wheel to select the album you
want to upload your photos to. If you'd like to use a new album
instead, enter the new album name in the textfield at the bottom. The
new album will be created as a private album.
To confirm album selection or creation, tap the [Select Album] button.

Upload your photos

Once you added
photos, and selected the Picasa album, the [Launch Uppload!] button
appears. Tap it to start uploading the photos.

The photo currently
uploading is displayed on the upload screen. If you want to cancel the
upload, tap the [Cancel Uppload] button.

Saturday, August 14, 2010

When you need to store data securely from within your iPhone application, sooner or later you will step over the iPhone keychain. This is the super-duper built-in iPhone safe, kindly provided to you by the fruit company.

Now - take your time to praise Apple for being so wise and foresighted to supply you with the cooked equipment for secure data storage...

..did you do well? Did you rag on some dump Windows users? Fine, then here is one more thing: The stuff ain't that simple to use. Of course, as a blessed Apple user you would expect a simple interface in the fashion of "[keychain getMySecretData] [keychain storeMySecretData]". But when you take a closer look at it you will find that it is rather half-baked - and implementing keychain access might take a little more than a one-buttoned mouse.

First of all, there ain't an easy-to-use keychain API in any of the frameworks delivered with the iPhone SDK. You would have to deal with weird C function calls. For instance, to retrieve data from the keychain you have to invoke something called SecItemCopyMatching, passing in a dictionary as parameter. Completely self explanatory, isn't it? If you're getting curious, you can dive into the secrets of keychain services here. Though in this programming guide the Apple guys are not getting bored emphasizing the straightforwardness and ease of use of the keychain API - there seems to be a little doubt, though. Cause in the code examples accompanying the guidelines, they build an object-oriented wrapper class around all this cute C-function magic. And this is where we join the game..

The complete example application provided by Apple can be found here. But the only thing of interest to us is the KeyChainItemWrapper. You can think of a keychain item as a record stored in the keychain database. Each keychain item consists of unencrypted attributes, and the actual data, which is encrypted. For instance, a password keychain item could have the account name set as one of its attributes, and the password itself be stored as keychain item data. Apple defines these types (aka classes) of keychain items:

Generic Password

Internet Password

Certificate

Cryptographic Key

Digital Identity

Keychain item classes differ in the attributes and structure of item data.

The KeyChainItemWrapper is a kind of object-oriented wrapper around a Generic Password keychain item, providing methods for item creation and modification:

Creates a Generic Password keychain item. If an item with provided identifier is already stored in the keychain data base, it will load its data. If not, it will create a new one and initialize it with empty strings. The identifier should be a string identifying the account the password stored in the keychain item belongs to.

The access group can be used to share the keychain item among different applications. So in most cases, you will not need it, and it can be set to nil.

- (void)setObject:(id)inObject forKey:(id)key

Depending on the value you provide for key, it stores theinObject as keychain item attribute, or encrypted keychain item data. To gain reasonable results, you MUST use the constants defined in the keychain services API for the key. For example, to store an ecrypted password, kSecValueData must be the key, and the actual password must be the inObject. To store a login name as keychain item attribute, use kSecAttrAccount for key, and the login name for inObject.

No later than here you recognize, that even the "object-oriented" KeyChainItemWrapper is not object-oriented, but at most "objective". In a serious object-oriented language, they would have given us methods like [keyChainItem setPassword] and [keyChainItem setAccount]. In reality, we have to tell what we want by passing cryptic constants to generic methods. Well, you will have to get used to it: It's the Apple guys - they don't care about user requirements, they define them themselves.

- (id)objectForKey:(id)key

Get an attribute or data out of the keychain. Just as mentioned in the previous section, you will have to use the pre-defined keychain services API constants for key.

- (void)resetKeychainItem

Delete all attributes and data of the keychain item, and initialize them with empty strings. Note: This does not delete the keychain item itself! Deleting a keychain item is not implemented in the Apple example.Here is a small code example of how to write to and read from the keychain:

Well, now you should be equipped with the basic knowledge to integrate a secure, keychain-based password storage into your iPhone application. Don't forget to add the Security.framework to your Xcode project if you want to use the KeyChainItemWrapper!

One important thing to mention is, that with the latest version 1.2, the KeyChainItemWrapper also works on the iPhone simulator. In prior versions it did not. The programmers just forgot to mention this in the revision history. The only thing you cannot use on the simulator is the ability to share keychain items among different applications using an accessGroup.

I think, you'll get over it..

You can find a very good, more detailed overview of the keychain API in this blog post.