Mono for Android: Just too expensive

There has been much talk in the office about mobile development.

I work with several devs that are building mobile apps in various different techs on different platforms.

For ages, I’ve been flying the Xamarin flag and fighting its corner. I’ve got the guys to come to Stuart Lodge’s MVVM Cross talks etc. As a development environment, I like it very much and I’m comfortable. I’m a c# WPF developer and so I like C# and Visual Studio.

But with the new pricing, I feel as though I’ve been let down.

$1000 is just way too high for the hobbiest app developer. Not to mention that that is per dev, so the guys that are in a small team of 3 or 4 – is their app going to make back $4000? Not any time soon that’s for sure.

And so they are going the Javascript, Typescript, Angular etc route under PhoneGap or whatever. And I don’t blame them.

Meanwhile, I’ve 11 months left of my annual subscription to build something in Mono for Android before the $1000 bill comes around again. And I feel I’ll have a hard time justifying it.

Advertisements

Common UI? Spotify on WP8 != Spotify on Android

Welcome Spotify!

Several friends of mine have the beautiful Nokia 920 running Windows Phone 8. It is a nice piece of hardware and it showcases WP8 very nicely.

One notable omission from the WP app store until now has been Spotify.

I’ve been a big supporter of Spotify ever since the beginning and happily pay my monthly premium subscription. Being able to store music offline on my phone is an absolute killer feature.

And so I am genuinely pleased that it has made it to the WP platform.

A Common UI

A hot topic of recent conversation amongst the boys has been HTML5 and the possibility of a common UI across multiple platforms. The conversation typically includes:

“You can write it once and it’ll run on desktops, iPads, mobiles…”

I have been developing in Mono for Android which allows for the code from the “viewmodel” (a logical representation of the view), interaction and business logic, service calls, etc to be shared.

Crucially though, the view, the UI, is not shared. And I believe this is a good strategy.

Users of Android expect their apps to be Android-like. Ditto for iDevices and Windows Phone.

Looking at screenshots of the new WP8 Spotify app, it is clear that the UI has been redesigned specifically for the Windows Phone. And rightly so.

So I applaud Spotify for making this (what I believe to be the) correct decision.

 

http://blogs.windows.com/windows_phone/b/windowsphone/archive/2013/02/08/spotify-arrives-on-windows-phone-8.aspx

Test App – It Works!

We’re making good progress now that we’ve gotten over the problem with the app refusing to load the Facebook login dialog (see previous posts).
Note: I still need to sort that problem out properly (or hope someone posts a solution) but for the time being, my test package is called Com.Facebook.Android!

Anyway, I have managed to build this little test app with very C# style code. Any places where I must use Java style code has been encapsulated as tightly as possible so that from the outside is still looks neat.

The screens show:

  1. The welcome screen with login button
  2. After the login button is pressed, this Facebook dialog appears
  3. Type in your Facebook credentials and press the Log In button
  4. The dialog even has a built in Loading… dialog.
  5. The dialog returns control to my app informing me of the result. Pressing the Logout button asynchronously logs you out
  6. Final confirmation of being logged out.

Excellent!

Note: I realise that visually, it just looks exactly like the sample app. Not surprising really since I’ve simply copied the images and layout code from there. It’s the code behind the layout that is completely different. Also, it’s all been a valuable learning experience. Onwards and upwards!

Facebook Graph API

OK, so whilst I have managed to:

  • download the Mono for Android samples
  • got the Facebook sample building in VS2010
  • got the Android emulator running
  • deployed the app to the emulator and run it
  • …and it’s worked
  • …and it uploaded a test image

…I’ve discovered that the REST api that it uses is soon to be deprecated, and instead we should use Facebook’s new Graph API.

*sigh* Right then, let’s see if anyone has built a Mono for Android wrapper for that then.

So apparently, this is Mono for Android compatible:

Facebook.MonoTouch

Let’s see if we can work out how to use it.

Neat Disposal Pattern

You know when you’ve been a c# developer too long when seeing a slightly neater and elegant disposal pattern gets you excited.

If you’ve been doing things properly, then you’ll already have components that are IDisposable because they need to release references (to aid garbage collection), unhook event handlers, dispose RX subscriptions  and clean up after themselves.

    public class MyComponent : IDisposable
    {
        // ...

        public void Dispose()
        {
            // Clean up component
        }
    }

Old School

Quite often, you’ll have sub-components that are also IDisposable and you need to make sure you dispose of those when you are disposed (presuming you’re responsible for their lifetime).

You could just fill your Dispose () method with individual calls to each of the IDisposables you hold. Straightforward if a little verbose.

    public class MyComponent : IDisposable
    {
        private ISubComponentA _a;
        private ISubComponentB _b;
        private ISubComponentC _c;

        public MyComponent(
            ISubComponentA a, 
            ISubComponentB b, 
            ISubComponentC c)
        {
            _a = a;
            _b = b;
            _c = c;
        }

        public void Dispose()
        {
            // Clean up component
            _a.Dispose();
            _b.Dispose();
            _c.Dispose();
        }
    }

Middle School

Or you might hold a List and add to it everything that needs disposing. Then in Dispose () you can loop over the list and dispose of everything. A bit neater.

    public class MyComponent : IDisposable
    {
        private List<IDisposable> _disposables = new List<IDisposable>(); 
        
        private ISubComponentA _a;
        private ISubComponentB _b;
        private ISubComponentC _c;

        public MyComponent(
            ISubComponentA a,
            ISubComponentB b,
            ISubComponentC c)
        {
            _a = a;
            _b = b;
            _c = c;

            _disposables.Add(_a);
            _disposables.Add(_b);
            _disposables.Add(_c);
        }

        public void Dispose()
        {
            // Clean up component
            _disposables.ForEach(d => d.Dispose());
            _disposables.Clear();
        }
    }

College

If you’re familiar with RX then you might have come across the CompositeDisposable to which you add IDisposables and then at some point simply dispose the CompositeDisposable. It takes care of disposing its contents.

using System.Reactive.Disposables;

    public class MyComponent : IDisposable
    {
        CompositeDisposable _compositeDisposable = new CompositeDisposable();

        private ISubComponentA _a;
        private ISubComponentB _b;
        private ISubComponentC _c;

        public MyComponent(
            ISubComponentA a,
            ISubComponentB b,
            ISubComponentC c)
        {
            _a = a;
            _b = b;
            _c = c;

            _compositeDisposable.Add(_a);
            _compositeDisposable.Add(_b);
            _compositeDisposable.Add(_c);
        }

        public void Dispose()
        {
            // Clean up component
            _compositeDisposable.Dispose();
        }
    }

University?

So the final neatening up that I saw recently was this.

You have a base class called DisposableObject. It has a method called AddDisposable(IDisposable x) which adds the x to a private CompositeDisposable.

DisposableObject then disposes of its CompositeDisposable in its Dispose method.

    public interface IDisposableObject: IDisposable
    {
        void AddDisposable(IDisposable disposableObject);
    }

    public class DisposableObject : IDisposableObject
    {
        CompositeDisposable _compositeDisposable = new CompositeDisposable();

        public void AddDisposable(IDisposable disposableObject)
        {
            _compositeDisposable.Add(disposableObject);
        }

        public virtual void Dispose()
        {
            _compositeDisposable.Dispose();
        }
    }

You then derive from DisposableObject and the idea is to pass any objects that we need disposing to the base class.

But here’s the neat bit.

Rather than calling the base class’ AddDisposable method directly, write an extension method that looks like this:

    public static class DisposableExtensions
    {
        public static T DisposeWith<T>(this T source, IDisposableObject target) where T : IDisposable
        {
            target.AddDisposable(source);
            return source;
        }
    }

This means that now the code can look like this:

    public class MyComponent : DisposableObject
    {
        private ISubComponentA _a;
        private ISubComponentB _b;
        private ISubComponentC _c;

        public MyComponent(
            ISubComponentA a,
            ISubComponentB b,
            ISubComponentC c)
        {
            _a = a;
            _b = b;
            _c = c;

            _a.DisposeWith(this);
            _b.DisposeWith(this);
            _c.DisposeWith(this);
        }
    }

Very readable and very neat and tidy.

It means that when you make an RX subscription, instead of storing that subscription in a member variable and remembering to dispose of it later, you can do this:

            IObservable<Trade> trades = _tradeService.GetTrades();

            var subscription = trades
                .Where(t => t.TradedAmount > 1000000000.00)
                .Subscribe(HandleLargeTrade)
                .DisposeWith(this);

And I thought that that was rather nice.

My latest thoughts are whether there is a neat way to null the references too. Hmm…