Recently I was lucky enough to hang out with much of the team from DevExpress, as well as fellow members of the DX-Squad, at DevConnections in Las Vegas. Michael Proctor (who was interested in accomplishing something similar) and I spoke with Azret Botash, who works on the .NET controls at DevExpress. Azret indicated that it was already possible to load the WinForms skins without the optional skin assemblies. He then proceeded to download and install Reflector on a conference PC before disassembling one of the DX WinForms samples and highlighting a few of the key classes involved, such as SkinXmlCreator and SkinXmlLoader.

After returning home, I started digging through the samples that ship with DXperience and was able to assemble various pieces of the puzzle to make my own SkinBlobXmlFileCreator class. It descends from SkinXmlCreator and then uses some very basic code to load a skin directly from its .XML and .BLOB files rather than from an assembly. These .XML and .BLOB files ship with DXperience and are located here:

C:\Program Files\DevExpress 201X.Y\Components\Sources\DevExpress.BonusSkins\SkinData
C:\Program Files\DevExpress 201X.Y\Components\Sources\DevExpress.OfficeSkins\SkinData
C:\Program Files\DevExpress 201X.Y\Components\Sources\DevExpress.Utils\SkinData

Using this new class, you can load a skin with the following lines:

            SkinBlobXmlFileCreator creator = new SkinBlobXmlFileCreator("VS2010", Application.StartupPath + "\\", "VS2010.skin.xml");
            SkinManager.Default.RegisterSkin(creator);

            UserLookAndFeel.Default.SetSkinStyle("VS2010");

This works without deploying or referencing the BonusSkins assembly. Only the “VS2010.skin.xml” and “VS2010.blob” files are required.

You can download the source for the SkinBlobXmlFileCreator here.

- (void)asyncRequest:(DAAsyncRequest *)request didFinishApplyingChangesForTables:(NSArray *)tables withErrors:(NSArray *)errors
{
	[self saveData];
	[self setBusy:NO];
...

This happens on the main thread and, given a large enough set of data, will cause your app to stutter.

Luckily this is pretty straight forward to address. Cocoa makes it easy enough to run code in a background thread, and that’s exactly what Alexander from RemObjects suggests:

-(void)saveDataInBackground {</pre>
    [self performSelectorInBackground:@selector(saveData) withObject:nil];
}

- (void)asyncRequest:(DAAsyncRequest *)request didFinishApplyingChangesForTables:(NSArray *)tables withErrors:(NSArray *)errors
{
    [self saveDataInBackground];
    [self setBusy:NO];
...

I’ve been using a form of the above solution for a while now and can confirm that things are running smoothly, even with a larger set of data. Alexander let me know that this would be addressed in the Xcode templates for a future DA update.

Data Abstract for Xcode makes it simple to support disconnected n-tier iPhone applications. The briefcase support is a snap, requiring only a few extra lines to be uncommented from the templates installed into Xcode by the Data Abstract installer.

I recently looked into adding support for an “offline” mode to a Data Abstract application I’ve been developing for the iPhone. Basically, the application should function whether the iOS device has an active network connection or not. If there is no connection, any changes to data should be cached until a network connection becomes available.

This ended up being pretty easy to do. I started by adding Reachability support to the application. You can read detailed instructions about how to do that on Stack Overflow.

Once Reachability support has been added, it’s trivial to alter the beginApplyUpdates code in DataAccess.m to only apply updates when a network connection is available:

- (DAAsyncRequest *)beginApplyUpdates
{
	if (!internetActive) {
		return nil;
	}
        ...
}

Then, modify the Reachability usage to apply any unsaved updates when a connection becomes available:

		case ReachableViaWiFi:
		case ReachableViaWWAN: {
			NSLog(@"The internet is working via WIFI.");
			internetActive = YES;
			//have we received data before?
			if (self.daTestTable) {
				//setup data adapter (to get a new connection)
				[self setupDataAdapter];
				//commit any pending changes to the server
				[self beginApplyUpdates];
			}

			break;
		}

The only tricky bit I found was the need to re-create the DARemoteDataAdapter after a network connection becomes available. This is because you may have an old connection that will cause an error if you try to reuse it.

You can download a sample application here. The archive includes a SQL script for generating the sample DB table.

The various session managers in RemObjects SDK are pluggable and swappable, so adding support for Olympia Server to our service was pretty straight forward. However, I quickly ran into a limitation when using Olympia Server for session management: if you make use of a custom TROSession descendant by handling CustomCreateSession (discussed here), your custom properties will not be available after they make the trip to Olympia Server and back.

After looking into the source for TROSession and TROOlympiaSessionManager, I was able to come up with a fairly simple solution that allows you to continue using a custom TROSession descendant while also making use of Olympia for out-of-process session management.

The key is to override both SaveToStream and LoadFromStream in your custom TROSession descendant. There, serialize and deserialize your custom property values using the Values name-value pair property found on TROSession.

procedure LoadFromStream(aStream: TStream; OnlyValues: Boolean = False); override;
procedure SaveToStream(aStream: TStream; OnlyValues: Boolean = False); override;

...

procedure TMySession.LoadFromStream(aStream: TStream; OnlyValues: Boolean);
begin
  inherited;
  MyProperty := Values['MyProperty'];
  MyStrings.CommaText := Values['MyStrings'];
end;

procedure TMySession.SaveToStream(aStream: TStream; OnlyValues: Boolean);
begin
  Values['MyProperty'] := MyProperty;
  Values['MyStrings'] := MyStrings.CommaText;
  inherited;
end;

That Values property is one of the properties that will be persisted round trip with Olympia, and will allow your service to continue working as-is while making use of both a custom session class and Olympia Server.

The update has some nice new features, such as the ability to add and edit security questions and general password notes. This version also makes the usage of a PIN for unlocking optional, and does a better job of explaining the importance of remembering your master username and password, as well as explaining that the PIN is solely for unlocking the application on the device – not for logging into the service. Version 1.1 also includes a handful of bug fixes and minor changes.

The Password Tote website and service are completely free, and access from native applications for Windows, OS X, Android, and iOS is free for 60 days. You can find the iOS and OS X versions on their respective App Stores, the Android version is available on the Android Market, and the Windows version is available here.

There are some nice changes in the works for the iOS Password Tote app including the ability to manage security questions and notes, as well as making PIN usage to unlock the app optional.

There are also excellent versions available for Windows and Android, as well as a Firefox plugin on the way.

Strongly Typed DataTables and Business Helper Classes

I’ve recently started using Data Abstract for .NET, and love the new features it brings, such as DA Linq and DA SQL. While this per-data table business logic isn’t to be found, it’s pretty straight forward to cook up.

Here is an example base class that encapsulates the standard Data Abstract BusinessProcessor, and here’s a sample CustomerBusinessProcessor that ensures a name is specified.

Using this class, you can write your own descendants, and then new them up in your service’s implementation unit like so:

FProcessors := new List<DomainBusinessProcessor>;
FProcessors.Add(new CustomerBusinessProcessor(self.components));

The essential bit here is passing in the components collection to the constructor, which is passed on to the constructing call for the internal BusinessProcessor. This is necessary as it is how Data Abstract finds BusinessProcessors for a given service.

You can download a sample here, which uses the SQLite PCTrade DB that ships with Data Abstract.

• Importing from LastPass
• Growl integration with notifications when the user should backup and when an account will expire
• User interface enhancements, including a new icon
• A new PKG installer

The Password Tote website is free and allows you to manage your passwords securely from any location. The desktop and mobile applications require a $2.99/mo subscription. Start your free two month trial here.

The iOS and Mac OS X versions of Password Tote use the outstanding communication libraries from RemObjects, and the Windows version’s slick visual styling comes from DevExpress’s WinForms controls.

In the end, this was fairly easy to do. I thought I’d share some notes about how I accomplished this, as some of the resources online are a bit outdated, or don’t lay all of these aspects out together.

Note that there is currently a request to support this sort of scenario directly in XAF’s security system. You can track the issue here.

The first thing to do is define the business object itself (we’ll called it OwnedObject). The only thing particularly interesting here is defining a property to reference the object’s owner, and initializing that value:

public class OwnedObject : BaseObject
{
    public OwnedObject(Session session) : base(session) { }

    public override void AfterConstruction()
    {
        base.AfterConstruction();
        if (Session.IsNewObject(this))
        {
            _ObjectOwner = Session.GetObjectByKey<SimpleUser>((Guid)SecuritySystem.CurrentUserId);
        }
    }

    private SimpleUser _ObjectOwner;
    public SimpleUser ObjectOwner
    {
        get
        {
            return _ObjectOwner;
        }
        set
        {
            SetPropertyValue("ObjectOwner", ref _ObjectOwner, value);
        }
    }
}

One way to filter list views by this ObjectOwner property is discussed here. Open up the XAFML file for the platform agnostic Module project. Navigate to the OwnedObject_ListView node under Views. Set the Criteria to ObjectOwner.Oid = '@CurrentUserID'. Here, ObjectOwner is the property defined on the OwnedObject class, and @CurrentUserID is expanded at runtime to contain the current user’s ID.

Set the same Criteria property on the OwnedObject_LookupListView node as well, and run your application. Both the WinForms and ASP.NET applications should now only show the objects created by the current user, which is automatically set when the object is created. Note that you can also accomplish the same thing with a View Controller.

You can hide the ObjectOwner property at runtime by deleting its respective items under the DetailView, ListView, and LookupListView nodes in the model editor. Also note that this can easily be applied to reports as well, so that a user only sees his or her reports. Simply descend a new object from ReportData, and use your OwnedReport as the data type for the report views.

This is all pretty cool with minimal code, but one issue that needs to be addressed is the data shown in reports. If a user were to create and run a report on OwnedObjects, they’d see all objects regardless of owner. This is also fairly easy to fix, but requires two solutions, one for the WinForms project and one for the ASP.NET project.

The solution for the WinForms project is discussed here. To the WinForms module, add a new View Controller. You’ll also need to add references to ExpressApp.Reports, ExpressApp.Reports.Win, XtraReports, and XtraReports.Design. Add the following code to your controller:

protected override void OnActivated()
{
    base.OnActivated();
    XtraReport.FilterControlProperties += XtraReport_FilterControlProperties;
    Frame.GetController<WinReportServiceController>().CustomShowPreview += ViewController1_CustomShowPreview;
    Frame.GetController<WinReportServiceController>().CustomShowDesignForm += ViewController1_CustomShowDesignForm;
}

void XtraReport_FilterControlProperties(object sender, FilterControlPropertiesEventArgs e)
{
    if (e.Control is XtraReport)
    {
        e.Properties.Remove("FilterString");
    }
}

void ViewController1_CustomShowDesignForm(object sender, CustomShowDesignFormEventArgs e)
{
    e.Report.FilterString = CriteriaOperator.Parse("ObjectOwner.Oid=?", SecuritySystem.CurrentUserId).ToString();
}

void ViewController1_CustomShowPreview(object sender, CustomShowPreviewEventArgs e)
{
    e.Report.FilterString = CriteriaOperator.Parse("ObjectOwner.Oid=?", SecuritySystem.CurrentUserId).ToString();
}

protected override void OnDeactivating()
{
    base.OnDeactivating();
    Frame.GetController<WinReportServiceController>().CustomShowPreview -= ViewController1_CustomShowPreview;
    Frame.GetController<WinReportServiceController>().CustomShowDesignForm -= ViewController1_CustomShowDesignForm;
}

Basically, when the controller is activated, it will add two event handlers to the report service controller for WinForms applications – one for when a preview is shown, and one for when the report is designed. These events force a criteria that only shows objects owned by the current user. The FilterControlProperties event hides the FilterString property.

I had to figure out the ASP.NET portion on my own, but it wasn’t hard. Based on the WinForms solution above, I knew to look at the WebReportServiceController. Turns out you can simply descend from that class and override ShowPreviewCore to filter the data.

For the ASP.NET module, add a new class. Descend the class from WebReportServiceController and add the following code:

protected override void ShowPreviewCore(IReportData reportData, CriteriaOperator criteria)
{
    criteria = new BinaryOperator("ObjectOwner.Oid", SecuritySystem.CurrentUserId);

    base.ShowPreviewCore(reportData, criteria);
}

You’ll also need to add references to ExpressApp.Reports, ExpressApp.Reports.Web, XtraReports, and XtraReports.Web. This does essentially the same thing as the WinForms solution, overriding the preview of the report to force a filter on the object’s owner.

With those two changes made, you can now run both the WinForms and ASP.NET XAF applications, create and run reports, and you will only be able to see your own objects.

You can download a sample that demonstrates all this here.

Version 1.0.3 for iOS is already under way. Planned features include importing from popular password systems and restoring backups, both via Dropbox.

Version 1.0.3 of the Mac OS X client is also already in the works. Changes include user interface improvements, Growl notifications, and importing from LastPass.

Finally I wanted to thank Jim and Marc at RemObjects for working with me on a nice case study and for having me on their podcast. Their support really has made focusing on the features (instead of the communication) for these Password Tote clients possible.