This project has moved. For the latest updates, please go here.
1

Closed

If IDataLoader.GetLoadRequest returns null, DataManager.Load's asynchronous callbacks are never invoked

description

I've come across a peciular issue. This may be by design but it's definitely unexpected if it is.
 
If GetLoadRequest in a DataLoader returns null (in the instance of where I don't want the DataLoader to load anything because something else isn't ready), the DataManager.Load call never invokes the success or failure callback and the object that is returned is a cached instance of the model.
 
I find this behavior very confusing -- I would assume in this case that one of the callbacks would have been invoked (probably the error one) or some other indicator would occur to tell me that nothing was actually live loaded.
 
Here's a sample unit test that repros this. As neither of the waiting callbacks is invoked, the unit test never finishes.
 
[TestClass]
public class BugReproTests : SilverlightTest
{
    public class TestDataLoader : IDataLoader<LoadContext>
    {
        public object Deserialize(LoadContext loadContext, Type objectType, System.IO.Stream stream)
        {
            throw new InvalidOperationException("should never get here");
        }
 
        public LoadRequest GetLoadRequest(LoadContext loadContext, Type objectType)
        {
            return null;
        }
    }
 
    [DataLoader(typeof(TestDataLoader))]
    public class TestDataModel : ModelItemBase<LoadContext>
    {
    }
 
    [TestMethod]
    [Asynchronous]
    public void BugReproTest()
    {
        TestDataModel result = DataManager.Current.Load<TestDataModel>(new LoadContext("test"), BugReproSuccessCallback, BugReproErrorCallback);
    }
 
    public void BugReproSuccessCallback(TestDataModel model)
    {
        Debug.WriteLine("Success callback from Load()");
        TestComplete();
    }
 
    public void BugReproErrorCallback(Exception exception)
    {
        Debug.WriteLine("Error callback from Load()");
        TestComplete();
    }
}
Closed Jan 25, 2012 at 4:40 PM by shawnburke
By Design

comments

shawnburke wrote Dec 22, 2011 at 7:51 AM

Hi -

Returning null is meant to cancel the request. I definitely see your point, agreed it seems a little funky, but the behavior is by design, but i'm open to discussing it. To do anything else would be a challenge, just because returning null in the callback would require everyone to guard for it (which I'm not a fan of), and it's not really an error case. So the current architecture doesn't support this well.

The callbacks don't actually tell you that something was live-loaded in any case. It just tells you a load completed, but I see the symettry problem. I suppose that the callbacks could fire with whatever the current value is (e.g. a default one or the current one), but i'm not sure that woudl be the right thing either.

What do you think should happen that wouldn't require an API change for current apps?

Thanks,

Shawn

wrote Jan 25, 2012 at 4:40 PM

wrote Feb 14, 2013 at 2:53 AM

wrote May 16, 2013 at 8:17 AM