1Transit for them All (Exclusively for WP7)

A few days ago we released 1Transit. Softly. It is an exclusive Windows Phone 7 transit application that is a bundle of simple but robust and hopefully useful features.

Features Like

The application serves data for over 20 transit agencies across North America. Yes, built for travel.

We wanted you to be able to find things fast. Thus, the searching is fast. Something we like to showoff to our friends.

No your eyes do not fool you. Those are live updates that you can receive for transit stops around you. We implemented a bookmarking (aka pinning in the Windows world) feature too, so that you can get these updates with only a touch.

Not impressed? Try it for yourself and maybe you will be. Fingers crossed.

Coming Soon

We have put much weight behind this application and we’ll be building on the current version. In the coming updates we are looking to,

  • Utilize location to enrich the experience,
  • Provide schedules and maps of routes,
  • Implement live updates of vehicle locations,
  • Add support for more agencies.

Coming Sooner

Yes, 1Transit is exclusive for WP7 but we have been working on a version for our fellow smartphone users on Android and iOS. Stay tuned for that.


Say Hello to Project jQMvc

After my previous post about jQuery Mobile and ASP.Net MVC, I found myself using jQM in a project. Now, it would be a shame if I didn’t share the goodies I built for MVC with jQM.

So, I give you Project jQMvc. Really, it’s a collection of HTMLHelper extensions that build on jQM. With jQMvc you’ll be able to build full HTML5 compatible and mobile ready views but with the lovely MVC behind it at all times. Let me show you some of the things it can do.

Lists, a lot of them

In the project there a several types of lists, with and without searching. Thanks to jQM, it’s a treat! And really useful.

The below code,

@using jQM
@model IEnumerable

    ViewBag.Title = "Unordered List With Search";


And a little bit of sauce from the controller will give you,

jQMvc List with Search Preview

Buttons, all sorts of them

@using jQM

    ViewBag.Title = "Buttons";

@Html.ActionButton("Hi. I am a simple button.", "Index", "Home")

@Html.ActionButton("Hey! Look, I am a settings kind'a button.", "Index", "Home", ButtonIcon.gear)

@Html.ActionButton("Unlike others, I have route values.", "Router", "Home", new { id = "value" })

The code above will create a neat little stack of different kinds of button.

So that’s it for now. As the project grows, I will be sure to update with the neat things that will go into jQMvc.

Implementation of a Generic Repository Beauty, with Ninject the Beast

I really should be studying. But why study when I can blog right? Well, I have been meaning to write this post for a while now, and here it is.

The Repository Pattern is invaluable when working with the data, particularly in MVC. It encapsulates a lot of redundant and hopefully generic operations, I use it to encapsulate operations on the Entity Framework Code First ORM. My implementation doesn’t use Unit of Work which tracks changes and updates the database accordingly. Instead, I let myself decide. It’s not that bad.

The Context

Firstly, there is the context interface. It can expose methods, but I didn’t need to. Let’s imagine this context is for a shop.
This interface is important because it’ll be used by Ninject to wire everything up.

public interface IShopContext

The concrete implementation of the context might look like this.

public class CareContext: DbContext, IShopContext
    public DbSet<Fruit> Fruits { get; set; }

    public ShopContext()

The Entities

Fruit above is an entity and there can be many more. The entities derive from an abstract Identity class. What it is, is pretty obvious.

public abstract class Identity
    public Guid ID { get; set; }

Now let’s look at the example Fruit.

public class Fruit: Identity
    public string Name { get; set; }
    public int AmountInShop { get; set; }

The Repository

public interface IRepository<TEntity> where TEntity : Identity
    TEntity Add(TEntity model, bool persist = false);
    TEntity Get(Guid id);
    IEnumerable<TEntity> Get(Expression<Func<TEntity, bool>> predicate);
    IEnumerable<TEntity> GetAll();

    TEntity Update(TEntity model, bool persist = false);

    void Remove(Guid id, bool persist = false);
    void Remove(TEntity model, bool persist = false);

    void Save();

So these are some of the operations that the repository will perform. As you can see, I take care of the persistence using the optional parameter persist.

And now… the concrete implementation of the repository.

public class Repository<TEntity> : IRepository<TEntity> where TEntity : Identity
    private DbContext Context;
    private DbSet<TEntity> DBSet;

    public Repository(IShopContext context)
        Context = context as DbContext;
        DBSet = Context.Set<TEntity>();

    public TEntity Get(Guid id)
        TEntity model = DBSet.Find(id);
        return model;

    public IEnumerable<TEntity> Get(Expression<Func<TEntity, bool>> predicate)
        return DBSet.Where(predicate).AsEnumerable();

    public IEnumerable<TEntity> GetAll()
        return DBSet.AsEnumerable<TEntity>();

    public TEntity Add(TEntity model, bool persist = false)
        model.ID = Guid.NewGuid();

        return model;

    public TEntity Update(TEntity model, bool persist = false)
        Context.Entry(model).State = EntityState.Modified;

        return model;

    public void Remove(Guid id, bool persist = false)
        TEntity model = DBSet.Find(id);
        Remove(model, persist);

    public void Remove(TEntity model, bool persist = false)
        if (model != null)
            Context.Entry<TEntity>(model).State = EntityState.Deleted;

    public void Save()

    private void Save(bool persist)
        if (persist)

There you have it. It’s very simple to read really. It just spells out the methods defined in the interface and also provides logic for persistence when you want it.

The Ninject

Now all of this is pretty useless without Ninject. You’ll have noticed I used Inversion of Control while implementing the repository. Ninject is available on Nuget.

While registering the services on Ninject, I can tell it to provide a ShopContext when a IShopContext is required. The repository is bound to an interface, this context can be a development or deployment context, depending. Also, since I want to use the same context always, I bind it using ToConstant.

As for when a repository operating on a certain entity is requested, Ninject finds its type and provides accordingly.

private static void RegisterServices(IKernel kernel)
    IShopContext shopContext = new ShopContext();

Hope that wasn’t too long a post, it probably is my longest so far. Till next time, then.

MVC Now Stands for Mobile Views Conquered

Say hello to my little friend. Always wanted to say that. But seriously, say hello to jQuery Mobile. It’s pretty obvious what its all about so I’ll get straight to it. Here’s a little look at how pages of ASP.Net MVC applications can be hosted to work with mobile devices et with amazing interfaces.

Link ’em.

We’ll need to link the resources either from the CDN that’s mentioned on jQMobile’s download page. Or you can… download them. As I have.

    <script src="@Url.Content("~/Scripts/jquery-1.5.1.min.js")" type="text/javascript"></script>
    <script src="@Url.Content("~/Scripts/jquery.mobile-1.0a4.1.min.js")" type="text/javascript"></script>
    <link href="@Url.Content("~/Content/jqmobile/jquery.mobile-1.0a4.1.min.css")" rel="stylesheet" type="text/css" />

Give it structure.

I gave this MVC3 project’s _Layout.cshtml the following layout so that I can use it throughout my other views and modify those as required.

<div data-role="page">
   <div data-role="header">
   <div data-role="content">@RenderBody()</div>
   <div data-role="footer">
       <h4>Footer here</h4>

Using the data-role attribute, we can specify different parts of the page as we like. And as you might guess RenderBody() will be the mode of transaction for all your data. Data transactions can also happen through the jQMobile framework itself (using JavaScript that is). As you might imagine, each page can have be strongly typed to a model.

From there on it’s just good old MVC with jQMobile doing all the neat work, preparing the application for mobile platforms.

MVC3 Docking on AppHarbor and Entity Framework Code First

So, I spent last few hours figuring this out. AppHarbor is pretty nice. AppHarbor is free for one application, one database and it does work with SQL Server CE. I just deployed a stripped down version of one of my MVC projects there and it’s pretty smooth. So, here’s a run down of how it’s done, so that someone else might not need hours.

Stripping the project down was a breeze, you’ve got to love Object Oriented design, it’s beautiful. Deploying the project was a no-brainer too, if you’ve had some experience with Git. But testing, as ever brought out the issues.

I was using Entity Framework Code First (EFCF) as my ORM and it likes to drop databases. I didn’t realize it since it’s natural for EFCF to. And for good reason too, for when you change your models. On AppHarbor, you don’t get permissions to create databases. Thus the problem.

But no fear, NuGet to the rescue. Again. Actually, community to the rescue. There’s a workaround for EFCF’s DropCreateDatabases it’s DontDropDbJustCreateTables. You can find here on NuGet. It plugs in beautifully to your application and all you need to do is enter your context name. Also, you will have to get a new database from AppHarbor since already EFCF dropped it.

Also the connection string should include a providerName otherwise, exceptions!

    <add name="connection string name"
         connectionString="Server=db003.appharbor.net;Database=dbXXXX;User ID=dbXXXX;Password=YourPassword;"
         providerName="System.Data.SqlClient" />

Improve Performance on Your Windows Phone 7 Apps. Totally.

Let’s get straight to it.

It’s all about the threads.

There are two main threads on WP7: UI thread, composition thread.

The UI thread handles user input, XAML parsing, drawing visuals and callbacks. A lot of work. So, don’t use it, it’s already got a lot on its plate.
The composition thread mainly aides the UI thread in handling graphics and animation, improving UI thread’s performance. In many cases the composition thread doesn’t kick in, so that’s no use either.

Enter, background threads.

These babies are amazing and the best way to enhance applications. And oh boy, it’s an enhancement. How does it work? Asynchronously. (Love that word.)

You can have the background threads can do all the dirty work using BackgroundWorker and then when the dirty work is all ready to be presented, use either shared variables or my favourite, Dispatcher.BeingInvoke to update the UI thread.

WebClient no more.

The web is everything and WP7’s way to the web is WebClient. Unfortunately, it runs on the UI thread. You don’t want that, especially if the data you’re working with is large. MSDN recommends using HttpWebRequest. But why build a house from scratch when there’s Nuget? The package you’re looking for is Hammock. It’s what you want if you’re working with RESTful services. And once you have all the data call on to Dispacther.BeginInvoke to send the data off to the UI. Beautiful stuff.

Let there be Opacity.

I’ll be truthful. I love UIElement.Visibility. It’s just great hide stuff and unhide them whenever. Magic style. But, UIElement.Opacity is just as amazing only faster. Black magic style. We all know black magic is better than magic. Here’s why.

When UIElement.Opacity is set to zero, Silverlight will save the bitmap to memory but when UIElement.Visibility changes, Silverlight redraws everything. Very tiresome. But to get this awesome boost you have to set UIElement.CacheMode to Media.BitmapCache, otherwise, it really is no magic and a lot of black-hole of performance hogs.

There’s another aspect to this though, if you’re in/visibling a lot of elements (by a lot I mean a lot), it’s best to measure the performance of both first and see which suits your needs. Also, you may consider selective in/visibling depending, again, on your needs.

Guess that’s all for now. I’ll wonder around to see if I can find other neat ways of enhancing performance for WP7 applications. Till then.

Objective Scrutiny: inTO

Okay, this may not be completely objective because I am really excited that a recent update… actually, overhaul of inTO is up on the Windows Phone 7 Marketplace: http://bit.ly/GetInTO.

What’s this inTO you ask? Well, the idea is to aggregate events from all over Toronto, yes GTA, in a way that it’s easy to get on top of the kazillion things happening in the city. Windows Phone style.

I’ll allow this video to demonstrate:

So, what’s the scrutiny? Well, you really should have seen Version 1.0. Hey, I was just learning Silverlight… But with the help of the team at Fersh, we cleaned up my act and the app. Redesigned the UI a bit, made it more consistent, got rid of a bunch of bugs that tend to creep in when you’re up at 5 am coding your brains out.

The good in it:

  • “in and out” of the application in no time,
  • huge amount of data at your service, searchable too,
  • the data is locally saved, so your data usage is not so huge,
  • easy sharing via email, sms and of course Facebook,
  • a completely feature-complete trial* version.

And not-so-good (hey, I said it won’t be that objective):

  • lengthy loading time; don’t blame me, it’s not my fault Toronto is a happening city,
  • no categorization of the events; I am working on that next,
  • searching isn’t the most accurate; not really noticeable but I know because I wrote it.

Well, I hope, all in all, the experience won’t be too obvious… in keeping with the Windows Phone 7 spirit. Again, the trial* version is feature complete, so give it a shot for sure: http://bit.ly/GetInTO!

*trial: a free version of a Windows Phone application, available for most applications.