Archive for the ‘Xcode’ Category

« Older Entries

Handling UIDeviceOrientationFaceUp & UIDeviceOrientationFaceDown

by marc hoffman, June 29th, 2010, Categories: Cocoa, Xcode, iPad, short

If your iPad (or iPhone) application uses UIDeviceOrientationDidChangeNotification to detect device rotation, there might be a couple cases you forget to think about. If your device is lying down flat (or upside down), there is still an implied “felt” orientation, based on how the iPad was last held before it went flat. How will iOS let you know about this? Here is what i found out when writing Dwarfland Photos:

After you sign up for UIDeviceOrientationDidChangeNotification, if your device is flat, you will receive 3 notifications. The first one will be with a value if UIDeviceOrientationFaceUp (or UIDeviceOrientationFaceDown), matching the actual current physical location of the device. Right afterwards, you get another notification, and this one will specify one of UIDeviceOrientationPortrait, UIDeviceOrientationPortraitUpsideDown,  UIDeviceOrientationLandscapeLeft,  or UIDeviceOrientationLandscapeRight – depending on what the UI was showing before your app started (and indicating how the user will think of the device as being rotated). This is followed right up with a third notification that brings you back to either UIDeviceOrientationFaceUp or UIDeviceOrientationFaceDown.

Essentially, the device is pretending the user really quickly shook it back to an upright position, and back down.

The best way to handle this that i found in my app was to never ever use the actual reported orientation do fo any drawing or calculation, but instead cache the last “felt” orientation, within an handler as follows:

- (void)orientationChanged:(NSNotification *)notification
{
  UIInterfaceOrientation orientation = [[UIDevice currentDevice] orientation];
  if (orientation == UIDeviceOrientationPortrait ||
      orientation == UIDeviceOrientationPortraitUpsideDown ||
      orientation == UIDeviceOrientationLandscapeLeft ||
      orientation == UIDeviceOrientationLandscapeRight)
  {
    if (!currentOrientation)
    {
      currentOrientation = orientation;
      [self prepareScreen];
    }
    currentOrientation = orientation;
  }
  [[UIApplication sharedApplication] setStatusBarOrientation:currentOrientation animated:YES];
}

All my code will use currentOrientation, so it will always have a proper orientation value. Also any screen initialization that depends on having a proper orientation (in Dwarfland Photos that is the initial drawing of the startup logo, once Default.png disappears)  i do in prepareScreen, which is not called until i obtained the proper “felt” rotation.

by marc hoffman, June 29th, 2010

Posted in Cocoa, Xcode, iPad, short | No Comments »

Improvements to RemObjects SDK and Data Abstract for iOS 4

by marc hoffman, June 22nd, 2010, Categories: Cocoa, Mac, ROFX, RemObjects, Xcode, iOS, iPad, iPhone

 

iOS-4

Yesterday, Apple shipped iOS 4, the latest version of its operating system for iPhone and iPod touch. As you’ve undoubtedly read abut elsewhere in detail, iOS 4 brings with it many improvements for developers, mostly (as far as it affects us) in regards to multi-tasking and background operation.

We’ve been busy updating our “for OS X” products to take advantage of some of these new features in iOS 4, and there’s two areas in particular that i would like to highlight.

Background Tasks

As you probably know, iOS 4 adds support for multitasking of third party applications, but does it in a restricted fashion that ensures background applications do not negatively affect battery life or performance. Regular applications will be completely suspended when the user switches away from them, and get no time to execute – no iOS 4 multitasking is no opportunity to keep working and talking to your servers in the background, as you please.

However, iOS 4 provides a handful of opportunities for apps to keep running in the background. Most of these (VoIP, Audio Playback and Navigation) do not really affect our libraries, but there is one that does: Background Task Completion.

Background tasks basically allow your app to say “hey, i’m kinda in the middle of something, do you mind”, and let iOS give your app a chance to finish what it’s doing. Normally, this is a manual action your code has to take to request this, but RemObjects SDK encapsulates this for you: every asynchronous request (you are using asynchronous requests, right? if not, you really should) you make will automatically participate in iOS’s background task completion system, so of the user does happen to quit your app, RO will try and keep your request running until it completes (yours app will still be suspended, once it does, but you can pick up with the result of your call, once the user switches back).

Now, keep in mind that background task completion is no guarantee. The OS might still go ahead and suspend your app completely, if your request is taking too long (were you uploading a 30MB video in one large chunk, maybe?). Or your app might even be killed completely, if memory runs low. But in most scenarios, background task completion will let your request succeed, even though the app was terminated.

If iOS does happen to suspend your app ahead of time, you will of course get proper failures for your request, once your app wakes back up. If you have code in place to handle connection failure gracefully (for example in case of signal loss) now, you should be well covered.

There’s nothing you need to do in your code (except build against the iOS4 version of RemObjects SDK) to take advantage of this. the iOS4 version of RO will also gracefully fall back to not mess with background task completion if it finds that it’s running on an older iPhone OS, in case your app supports multi-targetting with iPad (3.2) or iPhones running 3.x.

Blocks and Grand Central Dispatch

Not strictly a new feature of iOS 4, Blocks and GCD were initially introduced in Mac OS X 10.6 (Snow Leopard) and now made it into iOS as well. We’ve enhanced RemObjects SDK and data Abstract thruout, to take advantage of bCGS where possible, and to provide overloaded methods that work with blocks.

For example in addition to using any of the existing beginGetDataTable* methods on DA’s Remote Data Adapter that will call back your delegate, we now have versions where you can pass a block, to be called once the request as completed, and your table has been downloads. e.g.

[rda beginGetDataTable:@"Customers" withBlock:^(DADataTable *customers){
  for (DADataTableRow *row in customers)
    NSlog(@"Name: ", [row valueForKey:@"Name"]);
}];

This helps keep request and response code in one place, and makes asynchronous remote calls a lot easier in general.

On RemObjects SDK level, RODL-generated code for your services will also get extra overloads that allow calling your own methods with a block to receive the response.

Deployment Changes

Most of the changes described here will be in the next beta builds for Data Abstract and RemObjects SDK, which should be available for customers later today. They will ship as “final” version with our July release.

We’re also making some changes to our binary deployment, alongside this.

We have switched our build machine to the new iPhone SDK 4, so we’re now building and shipping iPhone OS 3.2 (iPad) and iOS 4 (iPhone & iPod touch) binaries only; the 3.2 binary does nor use any 3.2-specific APis, so you will be safe using that for 3.x projects (and even the 4.0 binary will downgrade gracefully for older deployment targets), but if you do need binary versions built for specific older versions of iPhone OS, you can always build from source. The binaries we do ship are now in the Bin/iOS folder; you might need to adjust your projects’ Library Search Path setting

We have also changed the default build target of our Mac OS X libraries to 10.6 (Snow Leopard) and the framework binaries we ship are built for that and include full support for GCD and Blocks. Of course you can still rebuild the framework from source, if you need to deploy to 10.5 (Leopard), and don’t use GCD.

 

Ok, so that is a quick summary of what’s coming of in RODA/OSX for iOS 4 with the July release. If you are doing iOS 4 development (or even if not yet), please give the beta (available later today) a try, and let us know what you think!

yours
marc

by marc hoffman, June 22nd, 2010

Posted in Cocoa, Mac, ROFX, RemObjects, Xcode, iOS, iPad, iPhone | No Comments »

Join us at Data Rage 2

by Sebastian, May 15th, 2010, Categories: .NET, Cocoa, Delphi, Mac, Relativity, RemObjects, Tools, Visual Studio, Windows, Xcode

RemObjects will present Data Abstract in a vendor showcase session at the Embarcadero DataRage 2 online conference, that will take place May 25-27, 2010.

Currently our session “n-Tier in a Box: Data Abstract in Action” is scheduled on Thursday, May 27th from 06:00 to 06:45 PDT.

In this session you will see how easy it is to create a Data Abstract server in Delphi, access that from a Delphi Client and we additionally show you how to create a Relativity-hosted DA server, access this via REST from a browser and at the same time from a native Mac application written with DA/OS X.

I like to invite you to the online conference and I’m excited to see (well, rather read or hear ;-) ) you at Data Rage 2.

by Sebastian, May 15th, 2010

Posted in .NET, Cocoa, Delphi, Mac, Relativity, RemObjects, Tools, Visual Studio, Windows, Xcode | No Comments »

WWDC

by marc hoffman, April 28th, 2010, Categories: Cocoa, Mac, Personal, ROFX, Xcode, iOS, iPad, iPhone, non-tech, short

Apple finally announced their annually World Wide Developer Conference, WWDC, today, after much anticipation and delay. Of course I bought my ticket right away, and am looking forward to the conference already.

I’m also looking forward to meeting any of our customers and/or readers of this blog – if you are going, drop me a message here, via email or twitter, and we can meet up!

See you in San Francisco!

Sent from my iPad

by marc hoffman, April 28th, 2010

Posted in Cocoa, Mac, Personal, ROFX, Xcode, iOS, iPad, iPhone, non-tech, short | No Comments »

“Der Entwickler” Article

by marc hoffman, April 17th, 2010, Categories: Cocoa, ROFX, Xcode, iOS, iPad, iPhone, short

The latest issue of german software development magazine Der Entwickler is out, containing among other good stuff an article by yours truly on database development for the iPhone with Data Abstract for OS X.

Let me know what you think!

by marc hoffman, April 17th, 2010

Posted in Cocoa, ROFX, Xcode, iOS, iPad, iPhone, short | No Comments »

The Missing Link: Schema Modeler for Mac

by marc hoffman, April 14th, 2010, Categories: Cocoa, Mac, Platforms, ROFX, Relativity, Xcode, iOS, iPad, iPhone

In this previous post, i talked about the current state of Data Abstract for OS X, and also promised a follow-up with a roadmap of where we are going next.

Where We’re at

To recap, when Data Abstract for OS X originally shipped last winter, it was client only. Basically, you needed to have existing servers written in DA/.NET or DA/Delphi (or write new ones using those same tools). This basically made DA/OSX a solution mainly for our existing Delphi and .NET customers, allowing them to expand their current solutions with native Mac and iPhone clients

In the following Spring release last month, we added Relativity Server running on all three platforms, giving developers the option to host Data Abstract services on Mac (in addition to Linux and Windows), without needing to know .NET or Delphi (or even having those tools).

This took care of two thirds of the picture, but there is still one hole in a complete Mac solution: Schema Modeling (and Relativity Administration). While Relativity server runs on the Mac, developers are still dependent on Windows based tools both to configure and control their Relativity server, and – more importantly – design and work with their schemas.

What’s Coming Next

As hinted at before, we’re working on closing this gap, and are writing a new tool for Mac developers that provides two things. First, it builds on the functionality in Relativity Server Admin for Windows, and expands it to a new concept, to what we are calling the Server Explorer. Secondly, it will allow Schema Modeling thru Relativity server, essentially providing the full functionality of Schema Modeler for Windows.

Let’s have a quick look at both of these aspects.

Server Explorer

Server Explorer will provide a single unified place for you to keep track of and administer all your Data Abstract servers. You can see a preview of what the current beta of Server Explorer looks like, here: (note that many things may still be subject to change before this ships):

Server-Explorer-(small).png

Server Explorer will automatically find ZeroConf servers on your local network, and you can manually register servers at remote locations, using their Target URL. It can handle Relativity and custom servers alike, although it will show slightly different options and features for each.

In the screenshot you see two servers folded open – one custom server (this is our Continuous Integration system, OnyxCI), and one Relativity server.

Custom DA servers don’t provide much room for configuration, so Server Explorer restricts itself to showing a list of all services it finds, and allowing you to browse data (including running DA SQL queries, if the server supports it) and view the readonly schema. That is provided you have a login to the server that authorizes data access. In this case, you can see there’s 2 data services and four other services exposed by our server.

For Relativity servers, there’s a lot more to see. As the screenshot shows, you can dive into the different Domains configured on the server (we’re looking at one called “OneSpace” here, which is a personal project of mine). You can look at the schemas (as well as browse and query the data they expose) and connection strings, and you can of course configure the Relativity server itself, such as to create new Domains.

Where things get interesting is on the Connection and Schema nodes, both of which allow you to open dedicated editor documents for what essentially are the .daConnections and .daSchema files.

Schema Modeler

Combined, these two editors give you the same abilities you have in Schema Modeler for Windows: You can define new connections and browse the actual contents of the database they connect to. And you can visually create and edit schemas, both by manually defining data tables and other elements, or by dragging tables from a Connection to the Schema document.

Connections.png

There is two core differences between what you (may) know from Schema Modeler for Windows, and how the Mac version of Schema Modeler handles things.

For one thing, while DASM/Win combines both the Schema and the Connection list into a single document window, DASM/Mac keeps them separate. The reason is simply that a Domain has one list of connections, but might have more than one schema defined. Having both in separate windows makes it more intuitive to edit several schemas at the same time – you will have one shared Connections window, where you can edit the connections, and from which you can drag objects into any of the schemas.

The second difference is more important. The current DASM/Win contains both DA/.NET and DA/Delphi server code that talks directly to the databases to retrieve metadata such as table names. If you are writing a Delphi server, it uses DA/Delphi drivers, if you are writing a .NET server or creating a schema for Relativity, it uses DA/.NET ones. This logic is embedded right into DASM/Win.

For DASM/Mac we have changed this, and have moved modeling support into the Relativity server. Relativity now exposes APIs (password protected, of course) that allow Schema Modeler to create connections for and obtain meta data from any database supported by the instance of Relativity it is talking to – over the network.

This means that you don’t need to worry about the proper drivers being installed and properly configured on your development machine, it also means that your database does not even have to be exposed to the network your development machine is on (you might have both your Relativity server and the backend database hosted somewhere on the internet, and expose only Relativity thru the firewall, for example. As long as you can talk to your Relativity server, you can work).

As a side effect, this allows Schema Modeler to be a 100% native Cocoa application and to still model and validate schemas against all the DA/.NET drivers available in Relativity.

Schema-Modeler-(small2).png

As you can see in the screenshot of the Schema document above, DASM/Mac also already exposes the new DA Scripting feature, which allows you to use JavaScript to define business rules that will run inside Relativity (but also in custom DA Servers).

The Add Event drop down provides quick access to stubs for all the available events, in this case the schema implements (well, pretends to) the beforeProcessDelta event, which gets called before any chunk of updates received from the client would be applied

When?

Work on DASM/Mac is well under way, and we’re confident it will ship with the upcoming “Summer 2010″ releases. The same is true for DA Scripting in DA/.NET and Relativity (the feature is completed as we speak).

Stay tuned to see both features in beta drops, very soon.

yours,
marc

by marc hoffman, April 14th, 2010

Posted in Cocoa, Mac, Platforms, ROFX, Relativity, Xcode, iOS, iPad, iPhone | 1 Comment »

“Making Apps”

by marc hoffman, March 20th, 2010, Categories: ROFX, Xcode, iOS, iPhone, short

Both Olaf Monien and Daniel Magin have blogged about the first in their “Making Apps” series of events on iPhone development, which RemObjects Software had the great honor of sponsoring.

This first event last week was in Munich; from what i hear there might still be a couple of seats available for the encore in Hamburg, next week…

by marc hoffman, March 20th, 2010

Posted in ROFX, Xcode, iOS, iPhone, short | No Comments »

What’s New and Cooking…

by marc hoffman, March 6th, 2010, Categories: .NET, Delphi, Delphi Prism, Mono, ROFX, Relativity, RemObjects, Visual Studio, Xcode

The past week has been a busy one, here at RemObjects. On Tuesday, we shipped our new “Spring 2010” releases, updating our entire product suite. We also started work on three major new projects that will significantly shape Data Abstract over the coming year.

Let’s start with a quick look at the “Spring 2010” releases. On first sight, this round looks like a minor update – and in many ways it is, as a large portion of the past product cycle has been concentrating on QA and documentation (which is making great strides in the wiki, i must say – kudos to the entire team for keeping up with their documentation writing). But we also shipped a few great new features and key technologies that will play an important role moving forward.

Script

Firstly, there’s the new RemObjects Script for .NET that Carlo talked about the previous week. Right now, RemObjects Script is is shipping as a standalone library product (like its close sibling Pascal Script for Delphi, and like Internet Pack, it ships free and with complete source, and is available in our public SVN). So that alone, i believe, is pretty cool – but RemObjects Script fits into a greater plan, and that is the expansion of Business Rules Scripting in Data Abstract.

A little known and often overlooked feature we have had in Data Abstract for Delphi for a long time is the ability to define business rules inside the schema, to be run on the client. Not really meant to enforce security, but more to provide a better client experience, the idea was that constraints and business logic could be specified – using Pascal Script – right inside Schema Modeler, and clients will retrieve and run these rules automatically, and would always have the latest set of rules, without needing to update the client .exe.

RemObjects Script is an essential piece in our plan to take this to the next level, and we are currently working on full Business Rules Scripting support, both client and server side, and for all three editions of Data Abstract. The idea is that right inside Schema Modeler, you will be able to specify JavaScript based rules that can run either on the client (be it .NET, Delphi or OS X), the server, or both.

Server side rules can be used for the actual enforcement of rules, making it possible to replace a lot (if not all) of the code that currently makes up a common DA server. Client (and shared) rules can complement these to enhance the local editing experience, by “enforcing” adherence to rules while editing data, without requiring a roundtrip to the server for final validation.

This DA Scripting feature is in the works now, and will ship for the various editions over the remaining course of the year, starting with Data Abstract for .NET in May.

Relativity

Next up, we shipped the first release of Relativity. Relativity is our new standalone Data Abstract application server, replacing the aging (and Delphi based) DAServer.

The idea behind Relativity is that the vast majority of Data Abstract servers don’t really need much custom code (beyond business rules), yet the common Data Abstract approach today is to create a custom server .exe that needs to be built, deployed and maintained. With Relativity, this can now be a thing of the past, and you can deploy Data Abstract services in a ready-made server application, simply by uploading the appropriate .daSchema file.

Relativity is based on Data Abstract for .NET, but it ships with all three editions of Data Abstract. This means it gives Delphi developers the chance to use .NET drivers and the advanced server-side functionality such as DA SQL, without needing to purchase (or learn to work with) DA/.NET. It also allows Mac and iPhone developers to create and host servers (since we don’t ship a server library in DA/OSX).

And of course Relativity will also take full advantage of DA Scripting, starting in May.

More Stuff

In addition to these to “big ones”, we’ve also shipped a range of smaller new features and enhancements.

Internet Pack for .NET has been extended with a native client implementation for LDAP, which Carlo also blogged about before. We use LDAP a great deal internally, and this new client class makes it easy to build LDAP authentication into your RO/DA servers (or any other applications, of course). In fact, Relativity ships with a default LDAP Login Provider that is based on this implementation.

Data Abstract for .NET now provides the ability to expose data via the REST protocol, which makes it very easy to access data from non-DA client applications, for example from client-side AJAX based web sites. REST is one of many features we have added over the past year or so to enable better accessibility from web clients (another notable one is support for JSON messaging in RemObjects SDK), and we’ll be blogging and writing more abut this.

Our Xcode integration has been extended by new project templates that really make it easy to get going with Data Abstract or RemObjects SDK for the Mac or iPhone. These templates were created based on a lot of custom code i had written while implementing our internal Bugs 7 client, and they should provide a great starting point.

Screenshot 1 - Templates.png

(One of the next items on my list is a post that will look at these in more detail).

 

Visual Studio 2010The last important change i want to highlight is that the entire range of products for .NET is now compatible and integrates with the new Visual Studio 2010 (based on the current Release candidate, although we expect no problems between now and the final release of vs2010 in April).

What’s Next

Ok, so i mentioned work on three new major features has started this week, as well. What are those? The first one, of course, is the new DA Scripting support i mentioned above.

The second new feature is one that we have been planning for a while but are finally getting around to for this time, and that is a brand new “New Project” template architecture for both Delphi and .NET. The current templates are pretty server-focused, and don’t make it very easy to create different client types. Our new templates will be focused around ann the various client applications you might want to create (WinForms, WPF, Gtk#, Silverlight, Monobjc, ASP.NET, VCL, UCL, and so on), combined with a great integrated wizard that will allow you to either create a new server project to match, or connect your client to an existing (custom or Relativity) server.

The third new feature, which i am most excited about, is to round of our Mac development story to allow for pure Mac development of DA applications. We have the library to build great clients on Mac, iPhone and iPad. We now have Relativity to host DA services on a variety of server platforms. What’s missing, and what we’re working hard on for the May release, is the tool chain in the middle – a Schema Modeler for Mac that will enable developers to design and test their schemas, for Relativity deployment, right in their Mac.

 

Stay tuned for a lot more talk about all three of these topics, over the next three months. In the mean time, go and check out our “Spring 2010” releases, available now!

 

marc

by marc hoffman, March 6th, 2010

Posted in .NET, Delphi, Delphi Prism, Mono, ROFX, Relativity, RemObjects, Visual Studio, Xcode | 4 Comments »

Photo(s) of the Week #28

by marc hoffman, February 28th, 2010, Categories: Personal, Photography, Xcode, non-tech


DSC_9205.jpg

It’s been a while since i last posted photos. Has, in fact, been a while since i last got around to doing some decent shooting.

I mostly blame Xcode.

You see, when i started up serious photography in 2006, computing as my main hobby of choice had started failing me. Computer work, and programming, had become work, not a hobby, and i no longer felt like doing programming in my spare time. A year later, along came my first Mac (ironically because &ndash among other things – it allowed me to do the post-processing of my photos without having to deal with the scourge that is Windows), and about half a year later came interest in developing with Xcode, which turned around to be such an awesome and fun development environment that it turned around my apathy regarding programming and made me enjoy it enough, again, to do it in my spare time.

So these days, my weekends and evenings are, once again, spent developing cool stuff (like our Bugs 7 application or my OneSpace iPad app). Going out and shooting pictures moved a bit to the back burner. (of course, the cold Winter hasn’t helped, either ;).

In any case, today has been one of the first days of great (for February) weather here in Berlin, along with at times almost clear blue sky, and some great clouds, giving me the chance to whip out my camera and grab a few dozen nice shots for cloudporn.com, my neglected photo blog (SFW).

DSC_9170.jpg

These images were all shot on my converted D50 and the Nikkor 70-300mm. They are all infra-red, with only really minor retouching (contrast, mostly) in the new Aperture 3. While i’m usually a Lightroom guy, what i like about Aperture is that it allows me to preserve my in-camera calibrated white balance in infra-red short. (in Lightroom, it’d be impossible to get out images looking like these, except by converting to grayscale; the images you see here are not grayscaled).

DSC_9217.jpg

We’ll see how it goes, but for the new decade, i’ve sworn to find more balance and get out to do more photo shooting, once again…

by marc hoffman, February 28th, 2010

Posted in Personal, Photography, Xcode, non-tech | 10 Comments »

Using Cocoa Bindings for binding DADataTable to NSTableView.

by Alexander, February 15th, 2010, Categories: Cocoa, ROFX, RemObjects, Uncategorized, Xcode

As you might know, Cocoa offers several ways for populating NSTableView with data.
The first approach is to use the NSTableViewDataSource protocol, which we are applying widely in our samples.

The second approach I want to cover today, is using Cocoa Bindings.

What is Cocoa Bindings?

Cocoa Bindings is an amazing technology that allows us to establish a full two-way data binding without writing any “glue” code. Cocoa Bindings widely uses the MVC paradigm, where models encapsulate application data, view display and edit data and controllers mediate between model and view.

So firstly, we will need to implement our own DataTableController, which we can reuse for any future projects.

In order to avoid creating a new sample from scratch, I’ve used our DASimpleSample, from which I removed all code for filling NSTableView using the NSTableViewDataSource protocol.

Implementing our DataTableController:

As the base for our controller, we will take the NSArrayController class.

So, let’s create a new class called DataTableController, inherit it from NSArrayController, add the DADataTable instance variable, which represents our data table and expose it as the read/write property like on code-snipped below:

//  DataTableController.h
 
#import <DataAbstract/DataAbstract.h>
 
@interface DataTableController : NSArrayController
{
	DADataTable *table;
}
 
@property (retain) DADataTable *table;
 
@end

In the DataTableController.m file we need to implement the setTable method, which retains the given DADataTable and set the table rows as content property of our controller.

-(void)setTable:(DADataTable *)newTable
{
	[newTable retain];
	[table release];
	table = newTable;
	[self setContent:[table rows]];
}

Also, in order to allow our controller to add and delete rows, we need to override add and remove methods as shown below:

-(void)add:(id)object
{
	if (!table) return;
	DADataTableRow *newRow = [table addNewRow];
	[self rearrangeObjects];
	[self setSelectedObjects:[NSArray arrayWithObject:newRow]];
}
 
-(void)remove:(id)object
{
	if (!table) return;
	for (DADataTableRow *row in [self selectedObjects])
		[table removeRow:row];
	[self rearrangeObjects];
	[self selectNext:self];
}

That’s all, our controller is ready. Let’s see how to use it for binding data.

Binding DataTable:

Open MainMenu.xib in Interface Builder and add NSArrayController.

Then, having added the selected controller, go to the Identity Inspector and select DataTableController as the class of the controller.

Then open Attributes Inspector and add keys. Keys is the column name of our DataTable. Specifying keys will allow us to select appropriate values in binding columns.

Now go to our window, select the NSTableView control and bind each of its columns to our controller.

For that, you will need to select a column and, in the Binding Inspector tab in the Value section, choose Bind To: Data Table Controller, set arrangedObjects as Controller Key and put the appropriate column name in the Model Key Path combo-box. We should get something like this:

Finally, we will set a link between add/remove methods and our controller.

To do that, we have to expand the toolbar of our application, then open the HUD window for our controller by performing a right mouse button click on it and connect add: and remove: actions with the appropriate toolbar buttons. You will see something like this:

We are now finished with the visual part and can close Interface Builder. The last thing to do is to set the content of our controller to a specific table. Switch to XCode and modify the asyncRequest: didReceiveTable: method as shown below:

- (void)asyncRequest:(DAAsyncRequest *)request didReceiveTable:(DADataTable *)table
{
	workersTable = [table retain];
	// set our table...
	[tableController setTable:workersTable];
}

That’s All. Let’s compile and run our application to see the results.

We can edit/insert/delete rows, all should work as expected and all the configuration took place in Interface Builder, we just had to write one line of code.

[tableController setTable:workersTable];

In the next my blog post, I’m going to tell you more about Cocoa Bindings. We will, among other things, try to add the client-side filtering of data in the table, the highlighting of changed cells.

by Alexander, February 15th, 2010

Posted in Cocoa, ROFX, RemObjects, Uncategorized, Xcode | No Comments »

« Older Entries