Xamarin: Crafting 5 Star iOS Experiences with Transitions

Last month, I wrote a blog post on creating beautiful animations using iOS APIs. Subtle use of animations and transitions in iOS can turn an average app into a five-star app. iOS has many built-in transitions between views that can be leveraged as a great starting point for adding animations to your iOS apps. However, with just […]

The post Crafting 5 Star iOS Experiences with Transitions appeared first on Xamarin Blog.

Details

Xamarin: Better Apps & Faster Release Cycles Part IV

This week, we launched a four part series that covers simple steps you can take to improve your apps and make your release cycles faster. Our advice is based on real-world challenges and rewards from Niels Frydenholm, Senior iOS Developer at eBay Classified, who spoke at Xamarin Evolve 2014. Today we’ll look at how to […]

The post Better Apps & Faster Release Cycles Part IV appeared first on Xamarin Blog.

Details

Greg Shackles: Lambda Expressions, Weak Subscriptions, and MvvmCross…Oh My!

Earlier this week we found ourselves looking into a strange databinding problem, where things were working as expected on devices but not in the simulator. Differences between simulators and devices is certainly not uncommon, but I’m not sure I can recall a time where it was on the device that things were binding correctly, and the simulator that was showing problems. The usual suspect of being a linker issue was off the table, so we had to dig a little deeper.

My suspicions then turned to differences in build configurations between the two – the garbage collector, debugging symbols, profiling support, etc – but no amount of option toggling smoked anything out there either. The strangest part? If we built in Visual Studio and deployed to the simulator, things worked. If we built with Xamarin Studio…no dice. Harumph.

At this point I was pretty confident it would end up being a garbage collection issue of some sort, and found that the binding was set up like this in a view model:

public void Init()  
{
    // ...other stuff...

    option.Quantifiable.WeakSubscribe(
        () => option.Quantifiable.Quantity, 
        (sender, args) => RaisePropertyChanged(() => Caption)));
}

If you’ve used MvvmCross before, you’re probably familiar with the WeakSubscribe() method, which can be great for subscribing to property changes on a model without creating strong references to it. In fact, if you’ve used this method before there’s a good chance you already see the problem (or this post’s title gave it away…it’s ok, I’ll give you the benefit of the doubt). The second argument to WeakSubscribe is the event handler to use for the subscription, which in this case was a lambda expression that goes out of scope after Init() finishes running.

Let’s take a look at how weak subscriptions work in MvvmCross to see why this is important. When you call WeakSubscribe you’re given a MvxWeakEventSubscription in return. When this subscription object is created, it creates its own event handler using OnSourceEvent which will get called each time the source property is updated.

The implementation of this method is the key here:

    protected void OnSourceEvent(object sender, TEventArgs e)
    {
        var target = _targetReference.Target;
        if (target != null)
        {
            _eventHandlerMethodInfo.Invoke(target, new[] {sender, e});
        }
        else
        {
            RemoveEventHandler();
        }
}

If the target is null, which is the event handler we supplied for this subscription, it removes the event handler and moves on. This is what was happening in our code…the lambda was going out of scope, and the next time the binding tried to update it would notice that and drop the handler, resulting in the property changes not bubbling up to our UI. The solution in this case was simple – use an actual method as the event callback:

public void Init()  
{
    // ...other stuff...

    option.Quantifiable.WeakSubscribe(
        () => option.Quantifiable.Quantity, 
        OnQuantityChanged);
}

private OnQuantityChanged(object sender, PropertyChangedEventArgs propertyChangedEventArgs)  
{
    RaisePropertyChanged(() => Caption);
}

Once that was updated things worked as expected. It’s also worth noting that it’s worth holding on to the subscription you get back from calls to WeakSubscribe so that you can manage and dispose of them as appropriate for your applications. That was left out of this example for the sake of brevity.

This isn’t rocket science, but I wanted to post it as a reminder that it’s important to think about what’s going on under the hood with this sort of thing and not get caught up the simplicity of a nice API. Lambda expressions are awesome and make code much more readable, but do come with a cost at times.

Details

Michael Ridland: iOS 9 Search API – A killer way to engage with users

Note: I’m currently at WWDC watching the live sessions, I haven’t been able to include all session details and only the public information, as more information becomes public I will post more details. Did you know that in iOS 86% of time is spent in apps? Apps are now allowed to integrate with the search […]

The post iOS 9 Search API – A killer way to engage with users appeared first on Michael Ridland.

Details

Michael Ridland: Introduction to iOS9 Multitasking and Xamarin.Forms first-thoughts

Note: I’m currently at WWDC watching the live sessions, I haven’t been able to include all session details and only the public information, as more information becomes public I will post more details. Split screens on iPad, ah scary, now we have even more things to worry about. Just in case you haven’t heard about […]

The post Introduction to iOS9 Multitasking and Xamarin.Forms first-thoughts appeared first on Michael Ridland.

Details