What you’re looking at are two versions of my Bugs application, a native OS X client for the bug tracking database we use internally to keep track of – well, not just bugs, but pretty much everything that’s to be done, including support issues, management tasks, you name it.
Both applications leverage the RemObjects SDK for OS X that i’ve talked about before (and which is in beta now, make sure to apply!), but also a very early prototype of Data Abstract for OS X which – although the class structure is still very volatile an in the early design stages – is already working very well.
What’s great is that not only do the Mac and the iPhone version of Bugs rely on the virtually identical library code in RO and DA; even the application-specific data access code is all shared between the two, with the only core difference being the presentation layer (and the amount of actual data the app fetches). I originally set out and wrote Bugs for the Mac side, and when i finally made the plunge to get an iPhone version running, it took me literally a handful of lines of code to get the basic DA data showing. Pretty cool.
On the back-end side, we have a pretty complicated “legacy” configuration. We have no less than four separate Mantis databases that stores our data. The internal database structure used by Mantis is pretty… well… odd, so accessing this directly poses a few challenges. Eventually we’ll want to move away from Mantis entirely, but doing that means replicating a lot of functionality that isn’t there yet and that we rely on the Mantis fronted application for – not something done lightly.
So we have a middle-tier server done in Data Abstract for Delphi, which uses AnyDAC to access the four (ugly) MySQL databases that Mantis provides. It also uses ADO to talk to our MSSQL server to verify user logins (we use the same user db as our website for this, which will eventually allow us to easily open access for all out customers to access parts of this data, themselves).
The four MySQL databases are abstracted to a schema that looks more closely like what we’ll eventually want our bug database to look like (once we drop Mantis altogether). The server is also leveraging Data Abstract’s Unions and the upcoming “DA HET” (short for Heterogeneous) feature to make each of the tables appear (to the client) as one entity, even though data comes from four separate back end databases.
Look for DA HET in a future release of Data Abstract, soon.
First, we create the standard set of components for RO/DA data access. For anyone who has used DA on Delphi or .NET before, the class names and concepts will be instantly familiar.
msg = [[ROBinMessage alloc] init]; channel = [[ROHTTPClientChannel alloc] initWithTargetUrl:@"http://..."]; dataService = [[RORemoteService alloc] initWithMessage:msg channel:channel serviceName:@"DataService"]; loginService = [[RORemoteService alloc] initWithMessage:msg channel:channel serviceName:@"LoginService"]; rda = [[DARemoteDataAdapter alloc] initWithDataService:dataService loginService:loginService];
Once we hold a RemoteDataAdater configured to access our server, we can fetch data – in this case we’re getting the full set of records for just one table – combined_bug_table (which, server-side, is the union of four distinct bug_tables from different database).
data = [rda getDataForTable:@"combined_bug_table"]; bin2 = [[DABin2DataStreamer alloc] initWithData:data forReadOnly:YES]; DADataTable *bugs = [bin2 getDataTable:@"combined_bug_table"];
The result is a DADataTable object that contains a recordset with the data. You can access this from code, accessing data by row and by field name or index, or use Cocoa Binding to bind it to user controls, such as the NSTableView or UITableView in the screenshots above.
Wanna know more about RemObjects SDK and Data Abstract for OS X? Drop me a mail or comment, or apply for the beta.
Subscribe to RemObjects Software Blog
Get the latest posts delivered right to your inbox