This is part 1 of a 5-part series in which I explore and demonstrate cross-platform app creation for mobile and desktop platforms using iFactr, an enterprise-grade framework, and Monocross, the open-source core of iFactr. The other articles are easily accessible at the bottom of each post.
Saw a tweet the other day referencing an article about how “Cross Platform UIs suck”… whatever. Aside from a personal bias (mostly because, in full disclosure, my livelihood kind of depends on it), I have a pretty straightforward thought on this:
In my opinion this statement only holds up somewhat because up until this point those trying to do cross-platform UIs were just trying to implement a single codebase, then make it cross-platform. What if you had a team of people working on creating a way for you to write your code once, and translate it to run anywhere? A team dedicated to targeting the latest platforms, keeping theses translations up to date, and caring about the best practices in UX design for the target platforms.
It’s time to release the beast.
At the beginning of August, I quit my previous job of 6 years as a Sr. .Net Software Systems Engineer to join ITR Mobility. Why? I’m about to show you.
As any person working in a cube can probably tell you, enterprises and corporations are becoming increasingly more reliant on their people bringing their own devices to work and using them to get their jobs done. While this is great from a cost point of view (they don’t have to buy you stuff, pay for your access/plan, etc.), it also means that when they want to create an application to be used by their employees, they can no longer develop for the “company-provided X” as the lone deployment target; they can’t create an application that targets only one device or platform anymore. So… what to do? Hire 5x the people to create 5x the code and field 5x the bug reports? uh… no. We do this:
I’ll let you soak up what you’re seeing there. That’s one application, written once, and targeting the Console, Webkit, Windows Desktop, and WP7. In one Visual Studio 2010 solution. In this particular example, it’s an application that pulls data from public web services for the MonkeySpace (formerly MonoSpace) conference on Mono development where not only are some of my colleagues from ITR presenting, but also a very good friend of mine.
Now I’m going to walk you through how it’s done and what the output is. Sit back and get some popcorn.
iFactr, ITR-Mobility’s product, is a cross platform mobile development framework providing not just abstraction of your business logic layer, but also the UI layer. It also provides a data synchronization framework. These two pieces are built on top of ITR’s open-source project, Monocross which provides you the ability to share the business logic of your app across platforms. Think of Monocross as the M, and VM in MVVM. Or more accurately, the M and C in MVC. You still have to grown your own Views. iFactr, however, handles even that for you. And damn well.
Shall we continue?
In iFactr, the core area of your app is called the Application. Outside of this you have Containers, which are the parts that target the specific platform you want to use. The container will reference DLLs containing platform-specific code written w/in iFactr that basically translates the code you’ve written in to native constructs for each platform. We call these “bindings”. So basically iFactr serves as a big translation engine for your code, an interpreter if you will. You write code that says “show X on the screen” and iFactr translates that to Console.Writeline, a XAML TextBlock, some HTML, etc.
So, let’s build the application.
After choosing iFactr Application from the new Project wizard, you’re given this. It’s a fully buildable version of a blank app. The UI construct in iFactr is known as a Layer. So the template Layer we see is, naturally, a Hello World one. Let’s have a gander at the code:
iBlock is an iFactr construct to spit out, simply, a chunk of text. So, we create an iBlock, append some text in to it, and add that to the Items collection on the layer. This would spit out, on the UI of any platform iFactr supports, “Hello World”.
For impact, I’ll add the containers now to prove my point ;)
Don’t get too excited, we still need to wire these containers to the app. But first let’s examine one of these “Container” things:
You can see that this is the Console container, and all it’s asking for (the commented-out code) is a reference to the app that we already created in the previous step. So let’s give it that:
of course, we added a reference to the MonkeySpace2 project, as well
Similarly, let’s do this same thing in Webkit and Windows containers:
Now, watch what happens when we launch the Console container:
You see the Title, “MyLayer”, the iBlock output, and the Back Navigation option you could choose by typing ‘0’ at the command line.
What about Webkit?
Webkit doesn’t play nice in IE (hopefully they’re working on this) so that’s why it’s running in Chrome (what, you thought I wouldn’t be an IE guy?)
And finally, Windows WPF:
This particular Layer is showing in this manner on a large form factor because by default, large form factor layers are Master/Detail view layers. This is easily changed.
Ok ok I won’t be a tease. Now the moment you’ve been waiting for. Let’s take this whole thing and slap it on Android. Before we do this, though, there is one important thing to note.
Doing Android development with C#.Net means you’ll be using Mono for Android. Up to this point, you’ve been targeting the .Net 4.0 framework, proper. But now we have to target a different set of core DLLs. So how on earth do we do this, but keep sharing all of the code? Fortunately, the interfaces that iFactr uses for MonoDroid are no different and share all the same names and constructs. What does this mean for you? Truly shared code. Check it out:
A couple of things have been added now. One, a MonkeySpace2.Android iFactr Application project, and two, an Android iFactr Android Container project. The significance here, if you look closely at the files w/in the Android application (bottom-most project) is that they are linked files in Visual Studio. Their source is the exact same file that is in the MonkeySpace2 application we created to begin with. This means the same code you put in the original source is the exact same code being used by the Android deployment. Again, the only reason this is necessary is because you can’t use the straight-up .Net DLLs on an Android platform, you have to use the Mono variant so it’ll run under Android.
Now that this is all set up, let’s launch it:
Yup, that’s the same exact code, now running on an Android tablet.
And last but not least, iOs. An important note here is that in order to accomplish this step you’ve got to be running MonoDevelop on a Mac. Sorry.
Bringing the same exact sln file we’ve been working w/ in Visual Studio 2010 in to MonoDevelop, we load it up and add a Touch Application and Touch Container to the solution:
Again, note that we are linking the files from our main MonkeySpace2 application project in to the Touch project, and simply changing the one line in the Touch container to point to the new Touch app after also referencing the app from the container.
And now, can you guess?
My next post will augment the Application to be just a bit more complex than “Hello, World” and walk you through some more of the inner workings of this paradigm of mobile development. In the meantime, feel free to download Monocross and start playing with 2/3 of what iFactr gives you while also learning Mono, Mono for Touch, and/or Mono for Android to do all your mobile dev in C#.Net.
As we move through this series, keep in mind is the overall mission statement of iFactr. iFactr enables enterprises to achieve their strategic mobile objectives by gearing itself toward cross-platform development useful to enterprise applications. If you think about it, what are these? These are applications that facilitate CRUD (Create, Read, Update, Delete) operations to some data source. They enable the inventory tracker to scan and track inventory on the shelf, enable the VP to see real-time numbers and reports on what’s happening with backend data, the salesman to update a customer’s record on the road, or even e-mail important documents to the customer as he’s visiting with them right in their living room – all from any mobile device you want. You’re not going to be cranking out Angry Birds in iFactr. You’re not going to be creating flashy, crazy UI paradigms.
However, if you do find yourself wanting to do that, the best way is via Monocross. Monocross allows you to share business logic for all your apps and write that only once, but then gives you the freedom to implement a custom UI for each platform, geared toward that platform’s strengths and controls. It does this by feeding and maintaining a Model of data, and subsequently passing that up to the UI layer which you get to write from scratch for each platform/target. Incidentally for situations where you desire a one-off fully-native page w/in your app, you can override the default behavior of iFactr and substitute purely native code for one or more layers. So you’re not completely locked out of doing native development where needed.
Until next time