Computing / iphone / Mac OS X1 Comment
30
Jan 11

Private methods in Objective-C

Coming from the Java world, I love, care and embrace all things private, including private methods. Objective-C supports the feature but it appears to me (based on very shallow Googling) that there is not too much familiarity (or use) with it. I looked in a book I recently acquired, Learn Objective-C for Java Developers (Learn Series). While not a book a perfect book, it does cover the how-to of private methods in Objective-C.  

The key to the approach is to leverage Objective-C categories. Categories are a mind-blowingly nifty in the fact that they allow you, among other things, to augment objects you did not create with your own methods. While there are other ways of 'hiding' private methods, most of them result in warnings in Xcode. So here goes…

Say you have an object called CoolWidget. You create the header file (CoolWidget.h)for it as usual, i.e.:

@interface CoolWidget:NSObject
{
    int publicVar;

    @private
    int somePrivateVar;
}

// public methods
-(void) doSomething:(BOOL)cool;

@end

To add private methods to it, you would create a category for the object in a separate header file (CoolWidget+Private.h):

@interface CoolWidget (Private)

// private methods
-(void) doSomethingPrivate:(BOOL)cooler;

@end

All that's left for you to do is to include the additional header file, CoolWidget+Private.h in your implementation file, CoolWidget.m (though categories are often/normally implemented in their own .m file).

Update:

As my friend Glenn Barnett points out in his tweet, there is no such think as private methods in Objective-C. Unlike C++ or Java, there is no real 'enforcement' of access to the methods. Privacy, overall, is purely by convention. 


13
Aug 10

Spring Bean Validation: Error code list for Custom Error Message

In my charge to regain my coding skills, I am using Spring MVC and trying to run it on Google's App Engine.

As with any web application, I have a form which I was looking to validate. Spring appears to be very high on its integration of Hibernate's implementation of a budding Java standard, JSR-303, In essence that means annotating a POJO bean file and then having your Spring MVC Controller (@Controller is the annotation) use another annotation (@Valid) to trigger validation. If errors are found, the form is returned with error messages. Pretty awesome. Yet JSR-303 has a rather big omission: if you have to fields in a form that must be identical – as in the case of password a password confirmation field, you need to write custom code. Luckily, that capability is covered by *the other* Spring-related validation framework – The Spring Modules project's Validation library.

Configuring Spring Modules' validation is covered insanely well by Willie Wheeler. Spring Modules Validation (SMV hereafter) has the ability to compare fields to each other as a validation condition and also apply a validation rule based on prior validation success (look here for table 17.11). Very very cool powerful stuff. 

Where his article needs a bit of help is in how to set up custom error messages. See, SMV detects a validation error, it looks to create an error message that your Spring MVC form will display to the user. The default error messages are intentionally lacking, as you *are* expected to provide your own version for an error. And while the Wheeler article talks about how to set the errors up in a Properties file, he does not (nor is he expected – again thank you) cover all possible validation error codes that are necessary for you to define the error messages. This is why I am writing this post.

So, your custom error message properties file will consist of lines like the following:

SimpleClassName.propertyBeingValidated[validationRuleViolated]=your custom error message

So if you had a class called ApplicationUser with a field called email, your annotated class code will look this:

@Email private String email;

And your error message properties file will have a line like:

ApplicationUser.email[email]=Please enter a valid email address

You need to ensure that your class name (no package needed) is correctly capitalized. What's not clear – and drove me nuts, is what exactly are the error codes you put within the brackets – for example – [email].

Thanks to this incredibly useful post on the SpringFramework discussion boards, the error codes are based on default strings that are embedded in each one of the validation classes inside the org.springmodules.validation.bean.rule package.

To spare you digging through the source, here are the validation rules and the default error code strings associated with them:

Validation Rule Error Code Description
@NotNull [not.null] This rule validates that the validated value is not null.
@NotBlank [not.blank] This rule checks that a string value is not blank (that is, it holds some characters).
@InTheFuture [in.future] This validation rule checks that the validated date/calendar/instant occurs in the future (relative to the time of validation).
@InThePast [in.past] This validation rule checks that the validated date/calendar/instant occurred in the past (relative to the time of validation).Attributes are value that"Specifies the condition expression " and optionally, expressionScope. Defines the evaluation scope of the condition expression. global will define the validated object as the scope, while property will define the property value as the scope. Using the property scope enables the definition of conditions that apply directly on the property value (e.g. "length > 5"). The global scope enables the definition of conditions that apply on other properties of the validated object (e.g. "equals some_other_property")
@Email [email] This rule validates that a string value holds a valid email address.
@Expression [expression] This annotation represents an expression based validation rule. See Table 17.11
@Length [length] This rule checks that the range of a string's length is within specific bounds.See Table 17.13 for extra attributes
@MaxLength [max.length] This rule checks that the range of a string's length is less than or equals a specific upper bound. Must have a max attribute that "Specifies the maximum length the string value can have"
@MinLength [min.length] This rule checks that a string's length is greater than or equals a specific lower bound. Must have a value attribute that "Specifies the minimum length the string value can have"
@NotEmpty [not.empty] This rule checks that a collection/array is not empty (that is, it holds at least one element).
@size [size] This rule checks that the size of a collection/array is within specific bounds. See Table 17.16. Essentially, min and max attributes
@MinSize [min.size] This rule checks that the size of a collection/array is greater than or equals a specific lower bound. Must have a value attribute that "Specifies the minimum size of the collection or array ".
@MaxSize [max.size] This rule checks that a java.lang.Comparable value is within a specific range. Must have a value attribute that "Specifies the maximum size of the collection or array".
@Range [range] This rule checks that the size of a collection/array is less than or equals a specific bound. Must define either a min or a max attributes or both. Specify the lower and upper bounds of the range, respectively.
@Min [range] This rule checks that a java.lang.Comparable value is greater than or equals a specific lower bound. Must define a value attribute that "Specifies the lower bound of the range"
@Max [range] This rule checks that a java.lang.Comparable value is less than or equals a specific upper bound. Must define a value attribute that "Specifies the upper bound of the range"
@RegExp [regexp] This rule checks that a string value matches a specific regular expression. Must define a value attribute that "Specifies the regular expression"
@Expressions [expression] This annotation enables defining multiple @Expression annotations on a property.
@ConditionRef [spring.condition] This rule uses a condition that is defined in the application context to perform the validation check. Must define a value attribute that "Specifies the name of the condition bean as defined in the application context."

Hope this is of help to others.


06
Oct 09

Google App Engine: Brief First Impression

Started playing with the Google Apps Engine last night. Now that Java is supported, even I can be lured after the magical charm of what is close to the infinite scalability holy grail. These are my impressions spending a couple of hours with the tutorial:
1. Eclipse makes it easy
Google created a pretty nifty plugin for the latest generation of Eclipse to help you with app engine development. It generates some of the code you need and hides the boring stuff. It also contains a Jetty app server that helps you deploy apps locally for debugging.

2. Old Java, new tricks?
Google appears to want to simplify the uptake and adoption. Therefore the tutorial uses old school servlets and JSPs. Need to test deeper to see if there is any reason not to use more modern Sping framework and templating engines like Velocity. Doubt that.

3. It’s JDO, JPA: not your average ORM
This will take some getting used to. To gain access to the bounty of ‘infinite’ no headache (supposedly) storage you will need to get cozy with JDO or JPA. These mainstream Java standards are less popular than Hibernate and other ORM libraries. You will need to learn yet another framework. Had one nit here with an annotation specifying the type of primary key causing a bug.

Overall, though, things appeared polished and working. Cannot wait to play more.