Capturing a user's signature in an XAF mobile application - UPDATE for v17.2.8+

Starting with v17.2.8, MobilePropertyEditor supports the Edit ViewEditMode. We updated our How to use a Signature Pad in XAF Mobile example and enabled SignatureAction in the Edit mode accordingly. This improvement saves end-users time not only for this particular scenario (they no longer require to switch views), but also when working with regular image properties.

To see the difference in action, refer to the GIF file below and compare it with the one from my previous post:

Your feedback is needed!
For early testing, we published a daily build. You can download it using the following link: DevExpressNETComponents-17.2.7.18099.exe. We look forward to hearing from you.

Capturing a user's signature in an XAF mobile application - YOUR FEEDBACK IS NEEDED!

We are in the process of creating learning materials for this task, but polishing and publishing them online for everyone will require additional time. If you are ready to test our solution for your own app, I can provide you with draft instructions and test sample in return. 

It will show how to show a custom control where a user can draw his signature and save the result into an image property within your business class. 

Here is what it looks like in action:

For testing you will need XAF v17.2.3+, because there we supported mobile custom modules: Task-Based Help > How to: Add an XAF Mobile Custom Module

If you are interested in this testing, email me at dennis@devexpress.com.

Beware of the PhoneGap's Camera and Geolocation plugins version update

I wanted to warn early adopters of the XAF Mobile UI of the recent change in https://build.phonegap.com due to the updated version of two main plugins that may stop your camera or geolocation functionality on real devices:

https://www.devexpress.com/issue=T575763

Check this thread for a temporary workaround until we release new minor versions with the required changes. We apologize for all the inconvenience here, because we must have been sticking to a fixed version instead of the latest one when building the application package.

ImmediatePostData attribute support in XAF Mobile v17.1.7

I am happy to inform you that starting with version 17.1.7, XAF Mobile (CTP) supports ImmediatePostDataAttribute. You can see how it works in action using our https://demos.devexpress.com/XAF/MainDemoMobile/ demo in the Payment object's View. 

You are welcome to download the latest version and test this feature in scenarios you are interested in. As usual, your feedback is greatly appreciated. Do not hesitate to submit tickets in our Support Center.

NOTE: Automatic updates will not work for non-persistent calculated reference properties due to an OData specificity.

What's New in XAF Help 17.1.3 and 17.1.4

In this post, I would like to provide an overview of the most important additions to XAF documentation introduced after the 17.1 release.

New and updated help topics in version 16.2.4

Recently, Dennis has published a huge list of changes introduced in XAF documentation in the previous major update (16.2). In this post, I would like to overview another set of changes in XAF documentation introduced with the 16.2.4 minor update of XAF.

New and updated XAF videos

I am glad to announce that the XAF team have published several new videos in DevExpress channel. These videos demonstrate the most attractive features from the What's New in XAF v16.2 list.

XAF Mobile Platform (CTP)

With this video, you can learn how to add a mobile client for your XAF application. This is the updated version of the previously published video. It demonstrates the following mobile enhancements introduced in 16.2

1. New UI layouts optimized for desktop and tablet devices.
2. Improved look and feel.
3. Application Simulator no longer requires an internet connection.
4. 'Active' and 'Enabled' action states are now context-dependent.

How to access derived (inherited) objects from OData Service

I want to quote a new KB article we created to more easily answer such user questions, especially due to the increased interest in OData in light of the recent arrival of the XAF mobile UI (CTP). 

Scenario/Situation

"I created an XPO OData service (XpoDataServiceV3) based on my model, but when I try to query a collection of objects that are derived from another persistent object, the result set includes all objects inherited from the base class. Is it a bug? How can I get only derived objects?"

Explanation/Solution
"This behavior is caused by limited support for derived objects in the OData protocol, which doesn't expose derived classes as entity sets. To access derived objects or their properties, you have to include a type cast using the qualified object type name in the path constructed for a base class. For example, if you wish to get Person objects that are inherited from Party, use the following query:

http://localhost:56789/MyDataService.svc/Party/Person/



Please refer to Derived Entity Type section of the OData Advanced Tutorial and Addressing Derived Types section of the OData protocol documentation for more examples.

Note that this specificity is not related to XPO. If you create a WCF Data Service based on an Entity Framework model, it will behave in a similar manner in regard to derived entities."


And here is a real-life URL query I tested with the data service I created with our MainDemo app and the new Mobile project template:

http://localhost:51562/DataService.svc/DevExpress_Persistent_BaseImpl_Task/MainDemo_Module_BusinessObjects_DemoTask?$filter=Subject%20eq%20%27Task1%27

Again, take special note that this is however, NOT specific to XAF itself or DevExpress ORM OData Service in any way, but rather to the OData V3 protocol itself.

Exposing Domain Components (DC) via OData for mobile apps

As you probably know, it is possible to use DC in non-XAF applications as described at eXpressApp Framework > Task-Based Help > How to: Use Domain Components in non-XAF Applications

So, I will use a similar approach in my XPO-based OData Service project (you can learn more on how to create it via the wizard here). Once I created the service, I will have to modify my XpoDataServiceV3 descendant as shown below:

[JSONPSupportBehavior]

public class DCDataService : XpoDataServiceV3 {

    static XPObjectSpaceProvider objectSpaceProvider = null;

    static readonly DataService1Context serviceContext =  new DataService1Context("XpoContext",

        "DevExpress.ExpressApp.DC.GeneratedClasses", CreateDataLayer()

    );

    protected override UnitOfWork GetSessionCore(IObjectLayer objectLayer) {

        if (objectSpaceProvider != null) {

            XPObjectSpace os = (XPObjectSpace)objectSpaceProvider.CreateObjectSpace();

            return (UnitOfWork)os.Session;

        }

        return base.GetSessionCore(objectLayer);

    }

    static IDataLayer CreateDataLayer() {

        XpoTypesInfoHelper.ForceInitialize();

        var typesInfo = XpoTypesInfoHelper.GetTypesInfo();

        var xpoTypeInfoSource = XpoTypesInfoHelper.GetXpoTypeInfoSource();

        typesInfo.RegisterEntity("Survey" typeof(ISurvey));

        typesInfo.GenerateEntities();         

        var connectionString = "Integrated Security=SSPI;Pooling=false;Data Source=(local);Initial Catalog=TestDb";

        var dataStoreProvider = new ConnectionStringDataStoreProvider(connectionString);

        objectSpaceProvider = new XPObjectSpaceProvider(dataStoreProvider, typesInfo, xpoTypeInfoSource, true);

        objectSpaceProvider.CreateObjectSpace(); // Force the objectSpaceProvider.DataLayer property initialization.

        XpoDefault.DataLayer = objectSpaceProvider.DataLayer;

        DevExpress.Xpo.XpoDefault.Session = null;

        return XpoDefault.DataLayer;

    }

}

Here I would like to focus on three things:

1. I initialized the static serviceContext variable and provide the namespace of our auto-generated DC entities as the second parameter: "DevExpress.ExpressApp.DC.GeneratedClasses". It is important to avoid dealing with long-named entities like "DevExpress_ExpressApp_DC_GeneratedClasses_Survey" in our consumer applications.

2. I initialized the data layer that is used by my XpoContext descendant via the static CreateDataLayer method. There I used some XAF magic, which is required for DC, because domain logic methods accept the parameters of the IObjectSpace type. If I did not use DC, then I would not use the XAF classes in my data service and rather go using pure XPO stuff.

3. I overrode the GetSessionCore to use the Session created by the XAF's ObjectSpace, again for the correct work of domain logic methods. Take special note that this virtual method is available in version 12.2.8+ only (thanks to our XPO guys for implementing my request so quickly;-)). If you want to test it right away, I have included the latest version of the DevExpress.Xpo.v12.2.Extensions assembly into the demo project I posted here.

Finally, let me demonstrate why I created the OData service in the first place. Of course, I needed it for my mobile DXTREME application:

View on screencast.com »

You may also be interested in my other blog on a similar subject at http://community.devexpress.com/blogs/eaf/archive/2012/12/12/how-to-configure-the-xaf-middle-tier-security-service-and-deploy-it-in-the-cloud-for-further-use-by-desktop-xaf-and-mobile-dxtreme-clients.aspx (that one is a way more complex, though).

UPDATE:

Originally when experimenting with this DC-based service I tried to reference the DcAssembly.dll into my data service project. This cache assembly is automatically generated by XAF when running the application with no debugger attached. So, to get it, I simply ran my XAF WinForms application, which used the same data model, and then copied the generated assembly from the Release/Bin folder into my data service project. Since this assembly contains regular persistent classes instead of DC interfaces (remember my recent talk about different types?), I hoped that this way it might be easier for you to understand and work with. Unfortunately, I had to stop using this undocumented approach later, because it required additional configuration from the application for the correct operation of the DC-based functionality: normally, when XAF loads this assembly internally it also calls the private void ProcessGeneratedAssembly(Assembly generatedAssembly) method of the XpoTypeInfoSource class. Another reason is that with the DcAssembly.dll approach it would also be more difficult to deploy and maintain the app due to the overhead on generating and copying the assembly...