|
The Angry Drunk links to a worthwhile read taking apart the latest “draconian control” clamors from Google’s new spokesperson for the Android / against the iPhone, and IMHO sums it up very nicely:
The bottom line is, if you think that Google is somehow a bastion of ‘open’ computing you are either ignorant, delusional or a hypocrite.
(Via The Angry Drunk).
Core Plot is an open source graphing framework for Cocoa developers that makes it really easy to add graphs to your applications for the Mac and iPhone. Over the past half year, i’ve had the chance to use Core Plot in several of the internal applications i have been working on and have been very impressed with it, so i wanted to talk a little bit about how to use the library, in general, and how to make generate charts based on data in a Data Abstract for OS X application, in particular.
The example shown here is from a small iPhone application i wrote to keep track of the status of our Continuous Integration servers. The application shows the success (or errors) of any builds done on the machine, as well as – and this is the part where Core Plot comes in – graphs the number of tests that run and fail, over time:
In the application in question, the chart is being displayed in a cell within a UITableView, so our example starts out by implementing a custom UITableViewCell class that will host the graph. But the same general principles apply to show a chart anywhere else (and, replacing UIView with NSView, for using charts in a desktop app).
Core Plot uses a Core Animation as underlying technology, and as such draws itself in a specialized view class CPLayerHostingView. So we start out by crating this view, and adding it as sub-view:
- (id)initWithStyle:(UITableViewCellStyle)style { self = [super initWithStyle:style reuseIdentifier:@"MyChartCell"]; if (self) { CGRect frame = self.contentView.bounds; CPLayerHostingView *chartView = [[CPLayerHostingView alloc] initWithFrame: frame]; [self addSubview:chartView]; //...
Once the CPLayerHostingView is created, we can add a graphs to it, and configure them. There are several graph types supported, but we want a regular line graph with X/Y coordinates, so we’ll choose a CPXYGraph class. We’ll add the graph to the view, and set a padding, to give us some room between the edges of the table cell:
// create an CPXYGraph and host it inside the view CPTheme *theme = [CPTheme themeNamed:kCPPlainWhiteTheme]; graph = (CPXYGraph *)[theme newGraph]; chartView.hostedLayer = graph; graph.paddingLeft = 10.0; graph.paddingTop = 10.0; graph.paddingRight = 10.0; graph.paddingBottom = 10.0;
The next step is to set up a plot space. A plot space defines the coordinate system for one or more charts in a graph, essentially mapping logical values to the area in the graph. For example, your chart might show values ranging from, say, 0 to 1000. The plot space defines the scale of those values in relation to the graph. It also defines the visual range of values that can be seen on screen.
To match our X/Y graph, we’ll create a CPXYPlotSpace, and set it to a range of 0-100 for both axis:
CPXYPlotSpace *plotSpace = (CPXYPlotSpace *)graph.defaultPlotSpace; plotSpace.xRange = [CPPlotRange plotRangeWithLocation:CPDecimalFromFloat(0) length:CPDecimalFromFloat(100)]; plotSpace.yRange = [CPPlotRange plotRangeWithLocation:CPDecimalFromFloat(0) length:CPDecimalFromFloat(100)];
Finally, we’ll set up to axis, for the X and Y coordinates. Axis provide labels and tick-marks for the viewer, to give context to the values being shown.
The X/Y graph already provides a set of axis in for of a – you guessed it – CPXYAxisSet class. There are several properties on the axis’ that are worth looking at at tweaking to to suite out needs:
CPXYAxisSet *axisSet = (CPXYAxisSet *)graph.axisSet; CPXYAxis *x = axisSet.xAxis; x.majorIntervalLength = length:CPDecimalFromFloat(10); x.constantCoordinateValue = length:CPDecimalFromFloat(2); x.minorTicksPerInterval = 2; x.borderWidth = 0; x.labelExclusionRanges = [NSArray arrayWithObjects: [CPPlotRange plotRangeWithLocation:CPDecimalFromFloat(-100) length:CPDecimalFromFloat(300)], nil];; CPXYAxis *y = axisSet.yAxis; y.majorIntervalLength = length:CPDecimalFromFloat(10); y.minorTicksPerInterval = 1; y.constantCoordinateValue = length:CPDecimalFromFloat(2); y.labelExclusionRanges = [NSArray arrayWithObjects: [CPPlotRange plotRangeWithLocation:CPDecimalFromFloat(-100) length:CPDecimalFromFloat(300)], nil];
Our graph is now fully set up – except for one important part: we still need to define one or more charts to display actual values. My application needs to show two graphs on top of each other – one showing the total number of tests that ran, and another showing the number of failures.
Core Plot supports a variety of chart (or, plot) types, such as bar and pie chart, but for this scenario, we want a simple line graph, which is done via a CPScatterPlot. (A scatter plot actually allows to draw a plot with points scattered all over the place, not just as string y = f(x) values, but we will use it in the more simplistic case).
We’ll create a new CPScatterPlot instance, configure some properties such as its lineWidth and lineColor, and most importantly, set the dataSource to the object that will provide the plot with its data – in this case, self. To round things off, we also tell the plot to fill the area underneath it with a gradient, going from almost-transparent green to nothing. This gives the plot some depth, without hiding the other plots.
CPScatterPlot *dataSourceLinePlot = [[[CPScatterPlot alloc] init] autorelease]; dataSourceLinePlot.identifier = @"AllTests"; dataSourceLinePlot.dataLineStyle.lineWidth = 3.f; dataSourceLinePlot.dataLineStyle.lineColor = [CPColor greenColor]; dataSourceLinePlot.dataSource = self; [graph addPlot:dataSourceLinePlot]; // Put an area gradient under the plot above CPColor *areaColor = [CPColor colorWithComponentRed:0.3 green:1.0 blue:0.3 alpha:0.3]; CPGradient *areaGradient = [CPGradient gradientWithBeginningColor:areaColor endingColor:[CPColor clearColor]]; areaGradient.angle = -90.0f; CPFill *areaGradientFill = [CPFill fillWithGradient:areaGradient]; dataSourceLinePlot.areaFill = areaGradientFill; dataSourceLinePlot.areaBaseValue = CPDecimalFromString(@"1.75");
We repeat the above to add a second plot, except this time we use red for the line color and gradient, and set the identifier to @"FailedTests".
This was quite a bit setup, but our graph is now ready plot, and will ask its data source (our cell) for data by sending it messages from the CPPlotDataSource protocol. This protoco will be familiar to any Cocoa developer who worked with, for example, a UITableView or NSTableView, or any other control using a data source.
To the protocol, two methods need to be implemented. The first is numberOfRecordsForPlot: which will, simply enough, return the number of items (in case of a scatter plot, points, the chart will contain. The second can be one of three methods that return the actual data. We’ll implement numberForPlot:field:recordIndex:.
The data to display is retrieved via Data Abstract, using a simple DA SQL request on a table that contains all test runs:
NSString *sql = [NSString stringWithFormat:@"SELECT TOP 50 ID, _TotalTestCount, \ _FailedTestCount, FROM TestRuns ORDER BY ID DESC"]; testRuns = [[rda getDataTableWithSQL:sql] retain];
The _TotalTestCount and _FailedTestCount fields are server-calculated based on a relation table and contain the total number of run and failed tests for each test run. We can Key Path operators to get the maximum value, and adjust our plot space accordingly, so that the entire graph fits into the chart:
int count = [[testRuns rows] count]; int maxTests = [[[testRuns rows] valueForKeyPath:@"@max._TotalTestCount"] intValue]; CPXYPlotSpace *plotSpace = (CPXYPlotSpace *)graph.defaultPlotSpace; plotSpace.xRange = [CPPlotRange plotRangeWithLocation:CPDecimalFromFloat(0) length:CPDecimalFromFloat(count)]; plotSpace.yRange = [CPPlotRange plotRangeWithLocation:CPDecimalFromFloat(0) length:CPDecimalFromFloat(maxTests)];
This is of course a bit redundant with the values we set earlier, but in real life application, the data access will usually happen in a different place than the initial setup (and data might get changed or refreshed during the course of the application), so i find it important to set up the graph properly to begin with, but then adjust the range to the real data.
With the data retrieved and the plot space adjusted, we can now implement the two data source methods.
numberOfRecordsForPlot: will simply return the number of rows in our table. numberForPlot:field:recordIndex will be called twice per data point, once for the X value (since we’re drawing a “non-scattered” plot, we’ll simply return the indexes) and one for the Y value, which we’ll retrieve from our data table. The different identifiers we assigned to the two plots will serve to distinguish which field to use for the Y value.
-(NSUInteger)numberOfRecordsForPlot:(CPPlot *)plot { return [rows count]; } -(NSNumber *)numberForPlot:(CPPlot *)plot field:(NSUInteger)fieldEnum recordIndex:(NSUInteger)index { switch (fieldEnum) { case CPScatterPlotFieldX: { // inverse numbers, so first (latest) test run is on the right. int x = [rows count]-recordIndex; return [NSDecimalNumber numberWithInt:x]; } case CPScatterPlotFieldY: { if ([plot.identifier isEqual:@"AllTests"]) { float v = [[[rows objectAtIndex:index] valueForKey:@"_TotalTestCount"] floatValue]; return [NSNumber numberWithFloat:v]; } else { float v = [[[rows objectAtIndex:index] valueForKey:@"_FailedTestCount"] floatValue]; return [NSNumber numberWithFloat:v]; } } } return nil; }
And that’s it! You can find more info on Core Plot on their Google code page; i also recommend joining their mailing list for latest news and support.
Bugs 7, the new bug-tracking application i have been working on over the past month for internal use here at RemObjects, employs several different data access paradigms (all based on Data Abstract for
The most interesting one is the main Issues table that contains all the bugs and tasks that are logged in the system. That is due to the fact that (a) it is a huge table (with over 25,000 records as of now, sized at about 11 MB when transferred over the wire, compressed) and that (b) by the very nature of a bug tracking system, this table changes frequently, and needs to be updated on the clients, often.
Rather then downloading the entire table anew every time, we optioned for a solution that allowed us to incrementally fetch only those records that have changed, and integrate them with the local dataset. This way, only minimal traffic is occurred for the regular refresh (which our client, by default, does every two minutes).
In the following post, i want to give you a quick glimpse at how this was accomplished, and how you can leverage the same technology in your own Data Abstract applications.
The Server
A couple things happen on the middle tier server (written using Data Abstract for .NET), to support the incremental refresh. Like all tables in the Bugs database, our Issues table has an UpdatedDate field, which gets automatically adjusted by the business logic code on the server. Every time a new issue is created, or an existing issue is updated, the server puts the current UTC time into the UpdatedDate field, clearly marking the order in which issues have been touched.
This is handled by a simple BeforeProcessChange event handler on the server, which simply adjusts the received delta, as such:
method BugsDataService.bp_Issues_BeforeProcessChange(aSender: BusinessProcessor; ea: DeltaChangeEventArgs); begin ea.DeltaChange.NewValues['UpdatedDate'] := DateTime.Now; ea.DeltaChange.NewValues['UpdatedByID'] := Session['UserID']; end;
(Of course the actual code in our server performs a lot more checks and changes, to enforce business logic for our database – but that’s beyond the scope of this post.)
Also, our Issues table does not permit deleting of records (only closing of issues, which sets their status accordingly, but does not remove the rows from the database). This alleviates the problem of worrying about rows disappearing from the table altogether.
The Client
On the client, a bit more custom logic is necessary, to perform the incremental updating.
When the client application (“Bugs 7”) is first started, it checks whether a briefcase file with a local copy of the data is found from a previous run, or not.
If not, the client will start a request to download the complete set of data from the server. This is a one-time process, and will download the entire table with it’s (currently) 11MB across the wire. Once downloaded, it is stored in a briefcase file, so on next application start, the data can be loaded locally. After the download is finished, the application also takes note of the latest UpdatedDate value it can find in the table, for future reference. This is made easy by Cocoa’s KVC and Key Paths:
- (void)downloadIssueData { // Initial download can take long, server side, to gather data. // allow for a longer timeout. [(ROHTTPClientChannel *)[[rda dataService] channel] setTimeout:360]; // fetch full table from server issues = [[rda getDataTable:@"Issues"] retain]; maxDate = [[[issues rows] valueForKeyPath:@"@max.UpdatedDate"] retain]; // save table to briefcase [self saveIssues]; }
If instead a briefcase was found, the Issues table simply gets loaded from that file, alongside the stored maxDate:
- (void)loadIssueDataFromBriefcase { DABriefcase *briefcase = [DABriefcase briefcaseWithFolder:briefcasePath]; issues = [[briefcase tableNamed:@"Issues"] retain]; maxDate = [[briefcase.properties valueForKey:@"BugsMaxUpdateDate"] retain]; }
Whichever path was taken, the application now holds a local copy of the Issues table it can work with. The next step it to schedule the regular refreshes, and for that an NSTimer is configured, to fire at regular intervals, on a background thread.
This NSTimer will trigger our beginRefreshBugs method, which uses asynchronous requests to start checking for new issues. It uses the previously stored maxDate and a feature of Data Abstract called DA SQL, to fetch only those issues that have newly changed:
- (void)beginRefreshBugs { // prevent two refreshs happening at the same time, if the NSTimer // triggers again before the previous refresh has finished. if (refreshingBugs) return; refreshingBugs = YES; // build the DA SQL query NSString *sql = [NSString stringWithFormat:"SELECT * FROM Issues WHERE UpdatedDate >= '%d'", (int)[maxDate timeIntervalSince1970]]; //and start an Async Request to the server DAAsyncRequest *ar = [rda beginGetDataTable:@"Issues" withSQL:sql start:NO]; [ar setDelegate:self]; [ar setContext:@"RefreshIssues"]; [ar start]; }
The DAAsyncRequest, once started, will communicate with the server in a background thread, without blocking the caller. beginRefreshBugs will return right away, and not wait for the request to complete (or fail).
Once the request did complete, it will call back to a delegate method (in this case we assigned self as the delegate, above), called asyncRequest:didReceiveTable:. It is here that we handle integrating the received data back with our big issues table by sending it the mergeTable:withPrimaryKey: message. This will replace the data in any rows that have changed, as well as add any new rows to the table:
- (void)asyncRequest:(DAAsyncRequest *)request didReceiveTable:(DADataTable *)table { // our class may handle access to more tables. check the context // to make sure we handle the right requests. if ([[request context] compare:@"RefreshBugs"] == NSOrderedSame) { // nothing received? nothing to do! if ([table rowCount] > 1) { @try { [issues mergeTable:table withPrimaryKey:@"ID"]; maxdate = [[[table rows] valueForKeyPath:@"@max.UpdatedDate"] retain]; [self saveBugs]; } @finally { refreshingBugs = NO; } } } }
Of course a refresh might also fail (for example due to a broken internet connection, for this case, we implement a second delegate method, called asyncRequest: didFailWithException:, as follows:
- (void)asyncRequest:(ROAsyncRequest *)request didFailWithException:(NSException *)exception { if ([[request context] compare:@"RefreshBugs"] == NSOrderedSame) { refreshingBugs = NO; }
The View
The last step after receiving new issues is to update any affected views. This happens more or less automatically, as every view that shows one one more issues (whether it’s the regular grid view of issues, a chart visualizing issue data, or an individual issue’s detail view) will be have registered itself to observe DA_NOTIFICATION_TABLE_CHANGED notifications on issues. And like any other change to a data table, mergeTable:withPrimaryKey: will send such a notification if changes happened, allowing all views to update themselves.
In Bugs, all of this happens in the background, so over time the view(s) presented to the user just seamlessly adjust themselves, as changes happen – new issues come into views; issues resolved by other users disappear on their own, etc.
Introducing Plateau
I’ve got a new personal Open Source project – Plateau. It’s a component library for MonoTouch. See my blog post at yamtu.net for more information.
One common scenario when developing iPhone apps is that you have a desktop application of some sorts that you want your iPhone to pair with – be it to sync data, remote control one with the other, or establish any other kind of communication.
In this scenario, the desktop app would be the “server”, in RemObjects SDK terminology, and the iPhone would be the client.
For the next release of RemObjects SDK for OS X, coming next month, we’ve created a nice sample that illustrates how to easily achieve this, and i figured i would post a small screencast of the sample in action, below.
What you see is a desktop app written in Delphi (although .NET will do just fine, as well), which for sample purposes has a pretty minimal UI, but in real life would be your full-fledged desktop UI app. When the iPhone client is a launched, it automatically detects any instance of your desktop app running on the local network and shows them in a list.
(The UI for this would be up to the application designer, obviously; for simplicity we simply show them all in a UITableView. In real life, if only one server was found you’d probably want to forgo the list altogether and just ask the user if he wants to connect).
Once the user picks a server, communication is initiated, by the iPhone calling a service method and passing it a unique GUID it generated. Since this is the first time these two are talking to each other, the server rejects the phone, but displays a random 4-digit code in it’s UI (this code is not known to the phone, at this stage). The phone asks the user to enter the code and, once done, sends it to the server to confirm the pairing. Once successful, the server stores the client’s GUID for future reference – and any future calls (even after the phone app has been restarted) will work right away.
Of course instead of showing an UIAlertView, your application would instead commence doing it’s real work.
Here’s the app in action:
The Mono guys released their first preview of MonoTouch, their implementation of the Mono tool chain for building iPhone apps.
Now, as anyone following this blog knows that i’m pretty deep into “native” Mac and iPhone development at this time, and i love Xcode and Objective-C too much to even consider switching to a third party platform for my OS X work – but none the less, i felt tempted to try out how it works with Delphi Prism, and am happy top report that i was able to port and compile their hello world sample app just fine in Prism (using the compiler we’re shipping for the August release).
Now, i wasn’t able to actually run the app on the phone, because some parts of the MonoTouch tool chain apparently don’t work on Snow Leopard (which i’ve been running exclusively since WWDC) yet – but hey, it’s all IL. If it compiles in Prism, it should run just like the C# version does.
Here’s the ported code:
namespace MonoTouch; interface uses System.Drawing, System.Linq, MonoTouch.UIKit; type AppController = class(UIApplicationDelegate) private fWindow: UIWindow; public method FinishedLaunching(app: UIApplication); override; end; Demo = class public class method Main(args: array of string); end; implementation class method Demo.Main(args: array of string); begin UIApplication.Main (args, nil, "AppController"); end; method AppController.FinishedLaunching(app: UIApplication); begin fWindow := new UIWindow (UIScreen.MainScreen.Bounds); fWindow.AddSubView(new UILabel(new RectangleF(50, 50, 230, 100), Text := 'Hello from MonoTouch with Delphi Prism')); fWindow.MakeKeyAndVisible (); end; end.
I realize it’s been a while since i talked about Data Abstract for OS X, so i figured today would be a good time to post a small teaser for what’s coming up in the next beta drop – most likely before the end of the week.
The previous beta, which we shipped in early June, provided read-only access to Data Abstract servers created using .NET and Delphi. Since then we’ve been busy both refining that support but also, more importantly, adding the ability to make changes, persist deltas and and apply updated back to the server.
Below, you’ll see a screenshot of a small sample application that downloads a table from our unified PCTrade sample database, allows to make changes, and post them back. in the background, you see the sample server (running in a Virtual Machine on Windows) accepting and handling those update requests.
The app uses the briefcase model, so it can work offline, with changes staying local until the user presses the “Update” button to send them back to the server; of course DA will also all you to sending changes to the server implicitly, to provide a more seamless “online” experience for the user.
As you might notice, the sample also leverages the new ROZeroConf support we shipped in May, to find the server on the local network without manual configuration (in this case, the server machine is called VEMMY, as can be seen in the popup button in the client’s toolbar – if more than one server were running on the network, the user could pick which one to use, defaulting to the one found first).
Push Notifications area an important new feature in the new iPhone 3.0, and one that will be naturally useful for most people using RemObjects SDK to build iPhone apps because – by definition – if you’re using RO, you have a server that your iPhone app talks to, and the potential to have things happening on said server that warrant notification.
As of today, we have published a new, small open source project that sits on top of RemObjects SDK for .NET and RemObjects SDK for OS X to make it really easy to add push notification support to your apps. And i mean, really easy.
Available on code.remobjects.com as part of the iPhone Goodies repository, RemObjects.SDK.ApplePushProvider takes care of the entire package of handling Push notifications: Getting your devices registered with the server (and maintaining and persisting said registration over time) and sending out the actual notifications. All that’s left for you to do, really, is to come up with things to notify your about!
I’ve written up an extensive overview of how it all works on our wiki.
As mentioned above, the provider is implemented using RemObjects SDK for .NET, but for those of you using RO/Delphi, it will also provide a good conceptual starting point for implementing the same in Delphi (and who knows, maybe you can contribute it back to the repository). Even if you;re not using RemObjects SDK at all, it should still be a good reference implementation.
I hope you’ll find this useful, and – as always – feedback (and contribution!) would be greatly appreciated.
yours,
marc hoffman
So, WWDC09, Apple’s World Wide Developer Conference, is over, and i’m sitting in my room at the excellent Hotel Monaco getting ready to leave San Francisco.
For every conference i go to, i plan to blog more extensively about it, but of course that never happens, because there’s just too much good stuff going on throughout the week to find the time to sit down and write about it; WWDC has been no different.
I know most people following WWDC from afar only see the keynote on monday, but of course that is only the start of a full week of info straight from the firehose, and – while fun – pales in comparisson to the real meat of the conference.
This year, there has been lots of exciting news from the developer tools front. Xcode, the development IDE for both Mac and iPhone, is getting vastly expanded, with things such as deep integration of the Clang Static Analyzer (which admittedly i had been playing with for a month now, so it was not brand new for me, this week) and a new and vastly better Clang-LLVM based compiler to replace GCC (which still is the default, though). And that’s just the tip of the eisberg. And the rest of the tool suite, such as Instruments, is seeing significant improvements as well.
Due to the work i do at RemObjects, i always find myself in some sort of a “meta-developer” position at conferences like these. While most attendees see, say, new improvements in Instruments and think “that’s great, how can that help me write apps?”, i think “great, how can we leverage this to help our customers write their apps?”.
And i think there’s great potential here for deeper integration of RemObjects SDK and Data Abstract with tools such as Instruments, to make your life easier (and the same goes for GCD).
In addition to the tool chain, there’s also lots of good stuff happening in the OS and libraries, to benefit developers. Of course this is all largely under NDA, so i cannot say too much, but just take Grand Central Dispatch, for instance.
While GCD was already announced (not in the public keynote, but to developers) at last year’s WWDC, this week went into much more detail, and it’s amazing to see just at what level of both the OS and its applications, but also the developer APIs, GCD is being employed. Having a great technology as GCD made available is one thing (and the Parallel Framework on .NET offers something comparable), but seeing how virtually every of the OS’s APIs has been revised to make use of it, and seeing – first hand – the sort of performance improvements Apple has been able to get out of the technology by consistently applying it to all of their code as well, is mind blowing.
With this, and the great enhancements to the entire tool chain, i feel once again ensured that this is a great platform (or actually, two great platforms) to invest in.
And to think the entire tool chain, from Xcode to all the professional tools it comes with, comes free with the system (remember that, the text time someone wields the Apple Tax myth).
In any case, i should start to pack and catch my flight. It’s been a great week of learning and meeting great people, and i, for one, already can’t wait for WWDC 2010…
yours
marc hoffman
Chief Architect
ps: a couple of great food recommendations in San Francisco:
A bit ahead of the regular new product releases coming out later today, i’m happy to let you know that our second iPhone application has become available on the App Store, at midnight, tonight!
Very much a companion to the upcoming RemObjects SDK releases, ROZeroConf Browser (appstore link) is a free application that allows you to browse for available ZeroConf/Bonjour servers on the network your iPhone (or iPod touch) is connected to.
Enjoy,
marc
