In most cases a UIView is as large as the iPhone screen or smaller. But, in a few cases you may want a view that is larger than the normal iPhone screen size. Such a case might be when using the view within a UIScrollView which is a view that can manage subviews of arbitrary size. Interface Builder makes it exceedingly easy to configure views in the majority of cases but in special cases it falls flat and specifically in the case of the views size. The issue arises when a UIView is associated directly to a UIViewController.

As you can see from the screenshot the view labeled ‘SampleView’ is shown in IB as a subview to a view controller. Interface Builder seems to like to treat a UIViewController as some sort of pseudo view which can contain subviews. This is fine from a conceptual standpoint but this pseudo view has no controlls for size, location, etc. What ends up happening is that the views size is locked into a maximum size of 320 x 480. Again this is fine for most cases but falls short for those times when you want a view larger than is standard. What’s worse is that the Inspector for a UIView will allow you that change the width and height of a view attached in this way but in reality it is limited. You can see this when running your application. This behavior also makes it impossible to design anything but the top 480 pixels of your view in Interface Builder since it will only display a view design window that is fixed to what it thinks is the maximum size. In short attaching a view as a direct ’subview’ of a view controller in Interface Builder can lead to some major limitations.

The solution to all of this is actually quite simple. Simply do not add your view as a subview to the view controllers ‘pseudo view’. Instead add your view as a standalone view in your NIB.

As you can see from the second screenshot my view is not listed as a subview of the view controller but rather as a standalone view in its own right. You can then associate your custom view with the ‘view’ outlet of the controller. Now, your view can be resized to any size that you want, you can design the entire view in IB, and it will show up with the correct size when you run your app.

“However, the NDA has created too much of a burden on developers, authors and others interested in helping further the iPhone’s success, so we are dropping it for released software.”

Since I have been mainly focusing on iPhone development for the past few months my posts of Cocoa related development have fallen off. Now that it appears that we can write about released portions of the iPhone SDK I hope to be writing more about Cocoa Touch and of course Cocoa. I truly hope that the lifting of the NDA will help to build the iPhone developer community along a path parallel to that of the Mac developer community. I think that a golden opportunity has been missed to create the same sort of Mac developer goodwill and attitude in the iPhone developer community because of the NDA. Hopefully, now that developers are free to discuss the platform a rich and vibrant developer community will form with the same dedication to helping each other out.

This year for the keynote I stepped into line outside of Moscone at 5:30 am. As fortune or fate would have it I was just barely ahead of the same place in line last year when I had arrived at around 7:00 am. So, maybe that could be used as some sort of judgment on the size and enthusiasm of the crowd this year.

Why get in line so early and would I do that again? Yep, I think I would. Just being able to get up somewhat close to the stage for the big event makes it that much more exciting. Even more than that though you have some fun and make some friends as the line compresses and expands exposing you to different groups of people. If none of that matters to you though you can show up an hour or less prior to the keynote and watch it from one of the overflow rooms.

Unfortunately I can’t talk about the content of any of the WWDC sessions that I attended. However, I will say that, for me at least, most of the content seemed to be either way too high level (getting started) or way too low level (audio API’s). In any case, good info is there to be had and I picked up a lot of tips and got exposure to parts of the platform that I haven’t touched yet. Amazingly at every WWDC I have attended the speakers are first rate. They’re developers, managers, evangelists, and the like and I must say they all do an excellent job at presenting.

I spent a lot more time this year taking advantage of the labs that were available. The labs were divided out into major platform components and each had a dedicated area of the conference floor. Within each lab experts on a particular topic would be scheduled to be on hand during a particular time slot and all that you needed to do, in most cases, was just drop by and talk with them. Bring questions, code, or design ideas and it’s a good bet that you can talk with the guy or gal who actually wrote the code for some part of the system that your interested in. That in itself is worth the price of the conference ticket in my opinion.

Outside of the conference sessions, labs, and lunchtime speakers there are still plenty of Apple and non-Apple sponsored events. As for non-Apple events this is where your networking comes into play. Keep your ear to the ground because every night after the normal WWDC hours the real party begins. This year I made it to the VMWare party at ‘The Thirsty Bear’, the Cocoa Heads meeting at the Apple store (awesome), the Austin area Cocoa Coders get together at the ‘W’ (hi Jim!), and the Big Nerd Ranch party. Each and everyone was a lot of fun and I didn’t even scratch the surface of the events that I could have attended.

On the Apple sponsored events side of the coin you’ve got the ADA awards (not to be missed), Stump the Experts (which I did miss this year in preference to sleep), and of course the Thursday night beer bash. Apple’s beer bash is the ‘must do’ event of the week. The food and drink selection is a couple of notches above what you’ve had all week and, prior to the entertainment coming on stage, is a decent networking opportunity. I mean when you’re standing shoulder to shoulder its kinda hard not to meet the person next to you. This year the entertainment blew me away. I’ve always been a Barenaked Ladies fan and guess who stepped on stage? Yep, BNL! I was right down front just about center stage and managed to take this shot with my iPhone:

… tons of fun and the Barenaked Ladies were a blast as they talked and jibed about Apple.

All in all it was a great conference. I’ll definitely be back next year. Now to sleep for a few days and dream of that new code I’ll be writing.

I’ll be at WWDC again this year and I can’t wait. It should be a blast assuming that the sold out conference doesn’t take away from the overall experience. June is going to be one hectic month. I’ll be flying from Mexico back to Austin and then hopping on a plane 3 hours later for WWDC. A late arrival in San Fran will be followed by an early rise to sit in line for check-in and wait for the SteveNote. I’m a bit bummed that I’ll have to miss some Sunday night get togethers but c’est la vie. Post WWDC holds more travel as well but it’ll be more of a local nature.

If you’re going to be at WWDC drop me a line and maybe we can hook up for a beer or three.

Update

The latest Mac Developer Roundtable covers some really great tips if you’re attending WWDC for the first time (or even if you’re a veteran). Marcus Zarra,  Bill Dudney, John Chaffee and of course Scotty all provide some excellent insight into WWDC from an attendee perspective. Highly recommended.

A Means to An End

One of the great things about CoreData is the ability to model your entity objects in XCode’s data modeler and automatically have access to its attributes and relationships via Objective-C 2.0 properties or the standard Key Value Coding (KVC) methods. Simply gain access to an NSManagedObject instance for your entity and away you go. This magic is pulled off by virtue of CoreData dynamically generating efficient accessor methods for the properties that you define. These internally generated methods take the form primitiveKey (e.g. for the property ‘title’ the method ‘primitiveTitle’ would be generated). CoreData then effectively injects itself into the KVC mechanisms by checking for unbounded property exceptions on calls to valueForKey: and then calling its own generated ‘primitive’ methods in turn.

Another very important part of the CoreData voodoo is that NSManagedObject disables automatic key value observing change notifications. In addition, the generated primitive methods do not fire these notifications for you. Therefore, it is very important for subclasses of NSManagedObject providing their own accessor method implementations to fire the relevant access and change notification methods whenever accessing entity properties. The important methods to note are:

- (void)willAccessValueForKey:(NSString *)key;
- (void)didAccessValueForKey:(NSString *)key;
- (void)willChangeValueForKey:(NSString *)key;
- (void)didChangeValueForKey:(NSString *)key;

Now, finally armed with knowledge of CoreData’s intimate details we can implement our own NSManagedObject accessor methods. More importantly, the properties that those accessor methods represent do not actually need to exist on the entity definition and we can bind to them in Interface Builder.

Virtually Yours

In order to demonstrate this wizardry we evoke our now ubiquitous blog application example. For this incarnation we want to automatically generate a title based on a posts author and date. A dubious example to be sure but it serves our purposes.

Our first order of business is to create a BlogPost entity using XCode’s data modeler. The entity will contain only two real properties, an ‘author’ property of type String and a ‘postDate’ property of type Date. The ‘title’ property will be considered as virtual and will automatically be created as a custom combination of the current value of the ‘author’ and ‘postDate’ attributes. Next, we need to create a subclass of NSManagedObject and assign that class to our entity (See CoreData’s default date value for details on doing this). The primary purpose of our subclass is two fold. First, it defines accessor methods for our virtual ‘title’ property. Second, it overrides the setter methods for ‘author’ and ‘postDate’ in order to notify the system that the ‘title’ property has changed whenever one of these two properties changes. If our title property worked in reverse and was write-only there would be no need to override the author and postDate setter methods. Here’s the code:

@implementation BlogPostEntity

- (NSString*) title
{
    [self willAccessValueForKey:@"author"];
    [self willAccessValueForKey:@"postDate"];

    NSString *titleAuthor = [self primitiveAuthor];
    NSDate *titleDate = [self primitivePostDate];

    [self didAccessValueForKey:@"author"];
    [self didAccessValueForKey:@"postDate"];

    NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
    [dateFormatter setDateStyle:NSDateFormatterMediumStyle];
    [dateFormatter setTimeStyle:NSDateFormatterNoStyle];

    NSString *title = [NSString stringWithFormat:@"%@ (%@)", [dateFormatter stringFromDate:titleDate], titleAuthor];

    [dateFormatter release];

    return title;
}

- (void)setAuthor:(NSString *)newAuthor
{
    [self willChangeValueForKey:@"author"];
    [self willChangeValueForKey:@"title"];

    [self setPrimitiveAuthor:newAuthor];

    [self didChangeValueForKey:@"author"];
    [self didChangeValueForKey:@"title"];
}

- (void)setPostDate:(NSDate *)newPostDate
{
    [self willChangeValueForKey:@"postDate"];
    [self willChangeValueForKey:@"title"];

    [self setPrimitivePostDate:newPostDate];

    [self didChangeValueForKey:@"postDate"];
    [self didChangeValueForKey:@"title"];
}
@end

Take particular note of the usage of willAccessValueForKey:, didAccessValueForKey:, willChangeValueForKey:, and didChangeValueForKey:. In the ‘title’ accessor we notify the system that we will be accessing the values of the author and postDate attributes. Likewise, in the setter methods for author and postDate we notify that we will be changing the requisite property along with title (which we are in effect changing). An additional item of interest are the calls to primitiveAuthor, primitivePostDate, setPrimitiveAuthor:, and setPrimitivePostDate:. These methods are dynamically generated by NSManagedObject and therefore are not known at compile time thus producing warnings. These warnings can easily be taken care of by creating a category which defines those methods.

@interface BlogPostEntity (PrimitiveAccessors)
- (NSString *)primitiveAuthor;
- (void)setPrimitiveAuthor:(NSString *)newAuthor;
- (NSDate *)primitivePostDate;
- (void)setPrimitivePostDate:(NSDate *)newPostDate;
@end

As you can see nowhere did we define an actual ‘title’ property on our BlogPost entity in the data modeler. Yet, we can now bind to that property in Interface Builder and allow our interface to diverge from the underlying data model when needed.

For those that want to take a closer look the example XCode project can be found here: Virtual Accessors Example Project. For the rest, keep this little technique in mind for those occasions when you know that the user interface should be this way or that but you just don’t want to torque your data model. Code on.

Update

Scott Stevenson has provided an improvement to this technique. The end result is the same but the implementation is more elegant and much more maintainable. In essence, instead of overriding the accessor methods for author and postDate we provide an implementation for +keyPathsForValuesAffectingTitle. This lets the system know that a modification to either ‘author’ or ‘postDate’ should also trigger a change to ‘title’ thus eliminating the need to override their accessor methods. Sweet. In addition, since we still need to access the values for author and postDate we go ahead and define them as Objective-C 2.0 properties of our NSManagedObject subclass with the implementation tagged as @dynamic. This prevents compiler errors while still allowing us to access the values as provided by our superclass. Very nice indeed. An updated project can be found here: Virtual Accessors Example Project Improved

Within the core data modeler the default value for a date type attribute exists as a rather ambiguous empty text field. Documentation on what can be entered into this text field are, shall we say, rather hard to come by. With a bit of experimentation and extensive Googling it can be found that the values “now’”and “today” can be entered into the field (quotes needed).

As expected this will automatically fill in the current date as the default value for the attribute. However, there seems to be little difference between “now” and “today” in that the time portion of the date is always set to 12:00:00. You might expect the “today” value to work this way but it would certainly be nice if “now” truly meant ‘right now’ and not ‘now more or less kinda’. But, if this will work for you then you’re done.

If having a fixed date is what you need then you could always provide a natural language string as defined in the documentation for [NSDate dateWithNaturalLanguageString]. In fact, ALL of the following default values for a date type seem to work:

Yes, you read that right. Even “last Tuesday at dinner” works here:

Amazingly, we can easily get the time for last Tuesdays dinner but the current time is a mystery. Leave it up to us software developers to be focused on meals.

In the end if you need to set the default value of a date attribute to the current date and time you’ll need to subclass NSManagedObject. It’s an easy thing to do so here it is:

First, define a subclass of NSManagedObject. We’ll call this class ‘BlogEntryEntity’. Next, we need to override the NSManagedObject method ‘awakeFromInsert’.

- (void) awakeFromInsert
{
[super awakeFromInsert];
[self setValue:[NSCalendarDate date] forKey:@"postDate"];
}

As you can see it’s just two lines of code after overriding the method. Be sure to invoke the superclass’s method first as per the NSManagedObject docs. To make things simple we make use of NSManagedObjects excellent KVC abilities and use the setValue:forKey: method. Finally, we need to set the class of our BlogEntry managed object. This is done by simply changing the ‘Class’ field of the class attributes in the core data modeler from NSManagedObject to BlogEntryEntity.

That’s it. Now, whenever an instance of BlogEntry is created the postDate attribute is set to the current date and time. Have fun, and let us know in the comments if you find any other interesting default values that work.

]]> http://shanecrawford.org/2008/57/coredatas-default-date-value/feed/ 3 http://shanecrawford.org/2008/56/java-on-the-iphone-say-it-aint-so/ http://shanecrawford.org/2008/56/java-on-the-iphone-say-it-aint-so/#comments Sun, 23 Mar 2008 14:14:44 +0000 shane http://shanecrawford.org/2008/56/java-on-the-iphone-say-it-aint-so/ Almost as soon as the iPhone SDK was released Sun announced its plans to develop and release the JVM for the iPhone. As a long time Java developer I should be ecstatic about this news. However, rather than causing sleepless nights dreaming about the possibilities of a JVM on the iPhone it somewhat depresses me. Now, I must say that I do enjoy developing in Java and have been doing so professionally since early 1999 with code still being used in large projects ranging from Swing front ends to J2EE backends. In all fairness my J2ME experience has been little more than a hobby but I have had some fun with it.

So, does Java on the iPhone make sense to anyone other than a pre-supernova Sun? Mmmm… well, I’m sure that the thousands of J2ME application developers out there would be pumping for it. There might also be a few users who rely on some mission critical application. Anyone else? None spring to mind, certainly not Apple.

A post-apocalyptic JVM enabled iPhone would soon become a litter ground for the multitude of J2ME apps. Some of these apps, such as the ones developed by Google, are indeed beneficial and well done. They are, however, far from the norm. With Apple’s tight control over the platform any J2ME apps would surely need to be provisioned directly from the iPhone AppStore which might help to eliminate some of the cruft. But, a free for all iPhone application bonanza is not likely to happen in this universe and that includes J2ME apps.

As a fledgling iPhone developer I must also say that a massive influx of J2ME apps to the iPhone would severly dampen my enthusiasm for the platform. All those J2ME apps would immediately have first mover advantage in a lot of important application categories – thus castrating many native iPhone applications. One of the draws to iPhone development is that it is a green field… there are thousands upon thousands of apps that need developing and for the uninitiated that spells “opportunity”.

Java on the iPhone proponents see the iPhone as another smart phone market for J2ME applications. However, the iPhone is much more than just a smart phone. It’s a completely new platform and more than any other device that has come before it is a powerful computer in your pocket. In order to make full use of all that the device offers only native code can deliver. Witness this quote from Eric Klein, vice president of Java marketing at Sun (source ars technica),

“We’re going to make sure that the JVM offers the Java applications as much access to the native functionality of the iPhone as possible,” he said.

Why would we even settle for anything less than complete access to the native iPhone functionality? Do some J2ME apps not need all that the iPhone has to offer? Well, then they aren’t iPhone apps and users will know the difference.

So, why throw my vote towards native Objective-C iPhone apps rather than building on my already deep Java knowledge and J2ME? It’s simple. Hands down the best user experience will be had by witting applications which make use of the unique and powerful native iPhone API’s. As a developer with a user experience mindset I only want the best and adding J2ME to the mix only waters it down.

Even though developers like myself have been drinking in the SDK for the past several days Apple has silenced open discussion of the SDK via an NDA (required to get the SDK). Hopefully, this restriction will be lifted once the SDK goes public near the end of June so that we can dig into some meaty code details. One thing that I will say is that it appears that Apple has really put a lot of work into producing the SDK. The documentation on the iPhone Dev Center is excellent and hints at a well planned out release.

There has been a lot of discussion surrounding the new AppStore and the 70/30 split Apple is making with developers. On the surface the developer deal sounds great and a 70/30 split with Apple taking care of hosting, processing fees, and a lot of the marketing seems fair assuming that millions of potential users get exposed to an app. However, as they say, the devil is in the details and we have a lot of details yet to flesh out. I’ll reserve my final judgment to the time when the SDK and the developer program go public and we’ve had a few months to see how it all works out. Until then I remain cautiously optimistic about the business deal and ecstatic about a cool new platform to develop software for.

As you can see our ‘Blog’ entity knows about multiple ‘BlogPost’ entities but not the other way around. XCode refers to these other relationships as the ‘inverse relationship’. So, for our simple example there is no inverse relationship between BlogPost and Blog.

“Well, ok, so what’s the big deal?”, you may be thinking. The big deal is Warnings my friend. If you’re like me you like your code to compile without a bunch of warnings. That way when something does come up it is easily spotted. It seems that Apple really, really wants you to have those inverse relationships. In fact, they pretty much say so in the Core Data documentation: 

“It is possible for relationships to be navigable in only one direction (if you are never interested in finding out from a department object what employees are associated with it, then you do not have to model that relationship), however you are strongly encouraged always to model relationships in both directions.” 

In fact, Apple feels so strongly about this that your build will produce a warning for each relationship that does not have an inverse.

So much for my clean build. Or is it? A little digging reveals that the kind hearted folks at Apple thought ahead and created a build setting to turn these warnings off if you so desire. Note that they are on by default. Simply open up the build settings for your project in XCode and search for ‘momc’. The utility momc is the XCode model compiler which can also be run from the command line if needed (see the XCode User Guide for more info)

Simply check the box to ‘Suppress momc warnings on missing inverse relationships’ and you’re done. No more warnings on a data model that you know is the way you want it. How thoughtful. Props to the guy (or gal) who fought for  this setting!

The essence of most implementations for an action button rely on NSPopUpButton and this implementation is no different. Where things start to diverge is that this implementation can be completed entirely within Interface Builder – no subclassing or custom rendering needed. So let’s get started and we’ll crank out this puppy.

NSPopUpButton operates in two different major modes which are ‘Pop Up’ and ‘Pull Down’. For this implementation we’ll be relying on the ‘Pull Down’ behavior which gives us a button with the requisite down arrow. So, just drag an NSPopUpButton onto your application in the desired location, choose ‘Pull Down’ from the inspector, choose the arrow to be along the bottom edge, and ensure that the ‘Title’ attribute is empty. Following is a thumbnail of the full inspector for a properly configured NSPopUpButton (click to enlarge).

You should now have a popup button with a blank title area and a down arrow. Sizing of the button is a hit-or-miss exercise and is probably the biggest drawback of this technique. As you will see even though we will have the gear icon in the built application we will not see it rendered in Interface Builder. The next major step is hooking up the menu that we will use. By default NSPopUpButton comes with a menu that has three items in it. For whatever reason if you try to modify this menu by adding new items things start to get out of control. So, we just bypass the default provided menu and create our own. When in ‘Pull Down’ mode NSPopUpButton utilizes the first NSMenuItem in the menu as the title for the button. Herein lies the trick that makes the whole thing work.

To start off this phase of the button development drag an NSMenu from the Interface Builder pallet into your NIB file. Name it something exciting like ‘ActionMenu’ in order to distinguish it from other menus in your NIB (you can do this via the ‘Identity’ tab in the inspector – see the Interface Builder Identity ‘Name’ attribute). Next build up your menu as desired reserving the very first menu item for our popup button custom use. You can connect your menu items to Actions in your code as needed (the blank menu takes no action – its used only by NSPopUpButton). Now, in order to get our gear icon to show up on our popup button we need to configure the attributes of that very first menu item. The key is to configure the menu item to have a blank title and to set the ‘Image’ attribute to have the value ‘NSActionTemplate’ (you will need to type NSActionTemplate into the text field).

The value NSActionTemplate sets the image of the menu item to be the gear icon. This comes from the new Media Library in Interface Builder 3. To see this for yourself bring up the media library, find the gear icon and click on it. You will see that its name is NSActionTemplate.

Now for the final connection. To bring the menu and the popup button together find your popup button and bring up its inspector. Connect its menu outlet to your NSMenu. That’s pretty much it. You’ll probably need to play with the actual size of the button (sans image) in order to get things to look right when you build and run the application. You can also play with some of the NSPopUpButton attributes to control the default location that the menu popups up at etc. However, you now have the often desired action popup button without any subclassing or custom rendering. Enjoy.