Blogging from the Uncloud

Our view on all things enterprise IT

Chrome Is The New C Runtime

Date: 
Friday, January 17, 2014
Author: 
Sanjeev Radhakrishnan

Cross-platform app development is more important than ever. 10 years ago, you just whipped out your Visual Studio when you needed a client application, but not anymore. With “app-ification” going mainstream on Android, iOS, Windows, and Mac, what is a developer to do?

Web apps are a good solution some of the time (except for that little detail called IE!).

But what about when you need the features and performance of native code, across platforms? And you’re a startup with a small team and impossible deadlines?

Well, at MobileSpan we’ve been living in this world for the past 2 years, and we want to share our approach.

We chose to build our application by integrating with the source code of Chromium.

Chromium is the open-source base of Google Chrome. My co-founder and I are Xooglers from the Chrome team, so we were very familiar with it and it was an easy choice for us. But you don't have to spend 4 years at Google to take advantage of Chrome's rich code base.

But... I'm not building a browser!

So, why would Chrome source be useful to me for cross-platform app development? I'm not building a browser...

In reality, Chrome is much more than just a browser. Chrome code is highly tuned for performance, reliability, and cross-platform compatibility across PCs and iOS + Android devices.

Out of necessity, the Chrome team has created cross-platform abstractions for many low-level platform features. We use this source as the core API on which we build our business logic, and it's made the bulk of our app cross-platform with little effort.

Most importantly -- Chrome code has been battle-tested like almost nothing else, with an installed base in the hundreds of millions. That makes all the difference when you want to spend your days working on your company’s business logic instead of debugging platform issues.

Basically, you can structure your code like the diagram below, where you only write your application logic, and let Chromium do the heavy lifting.

Chrome Development Diagram

So what's in Chrome that's so great?

Well, consider the parts of a modern browser. Chrome contains high-performance, cross-platform implementations of:

  • Concurrency handling
  • Compression
  • Encryption
  • Certificate handling
  • Low-level socket interfaces
  • High-level protocol implementations like HTTP, HTTPS, FTP)
  • DNS resolution
  • Proxy handling
  • Complex disk caching
  • Cookie handling
... and more

What it lets you do is build a single, cross-platform application layer, on top of all this goodness.

Chrome code also has other unexpected, higher-level goodies like:

  • Chrome Remote Desktop,
  • a full P2P (TURN, STUN, etc) stack (used by the Chrome Remote Desktop code),
  • an XMPP client (used by Chrome Sync as well as Chrome Remote Desktop)

Where Do I Start?

First Things First: The right tools to generate your project

The first step in starting your project is to create the appropriate project file for your platform (Visual Studio, XCode etc). Chromium uses GYP to declaratively specify files and project settings in a platform independent manner. I strongly recommend starting your project as a GYP file. GYP generates project files for each platform (Visual Studio solution and project files, XCode project files and Android .mk files). In addition, powerful dependency options in GYP allow compiler and linker settings needed by the various Chromium project files to automatically flow into the projects that depend on them. This drastically reduces your own build headaches, as well as problems when you update your checkout of Chrome sources.

A basketful of helpers prevent your project from becoming a basket-case.

Once you get to the meat of your app, you will find yourself needing all sorts of helper libraries for everything ranging from string manipulation, concurrency handling, synchronization, thread pools, message loops, logging, file manipulation, timers, shared memory management, and more.

If you find yourself starting to write a generic helper class or library, search the Chromium sources first. Chances are very high that you will find just the class you want, with very good unit-test coverage to boot.

The base library in the Chromium sources (found in src/base) provides a vast array of cross-platform tools that cover all the areas mentioned above and a lot more. There are also helpers for platform-specific areas such as the Windows registry or the iOS keychain.

It has become quite the game for developers at MobileSpan to search the Chromium sources for helpers they need.

Network stack, anyone?

Unless you are building your app for Windows 3.1, chances are that you want to talk to a server of some kind. This might involve simple HTTP or HTTPS API calls or low-level socket calls or anything in between.

The net library in Chromium (src/net) is your friend here. You’ll find a full cross-platform HTTP and HTTPS stack, code for cookie handling, caching, TCP and UDP sockets and socket pools, SSL certificate handling, DNS resolution, proxy server resolution ..., well, you get the idea, pretty much anything network related.

Encryption

Need to handle public/private keys, encrypt data store secrets? The crypto library (src/crypto) is another excellent cross-platform library that is almost sure to have the encryption or key management routine you are looking for. By now, you get the picture of how the sources are organized.

XMPP, P2P, Protocol Buffers etc.

These aren’t things you would normally expect to find in a web browser but Chromium includes an extensive XMPP and P2P client library built on top of libjingle (look at src/jingle and src/remoting). If you use protocol buffers in your code, GYP has support for .proto files. Just add the .proto files to your GYP file and it will do the right thing of building the protoc compiler and generate wrapper code for your protobufs. This even works for iOS projects.

Testing

Your code is only as good the unit-tests you write for them, right? Though not strictly a part of the Chrome, the GTest and GMock libraries that are part of the Chrome checkout provide an excellent framework for writing unit-tests and mocking your C++ classes. All Chrome tests are written using these frameworks so you have a big sample codebase to get inspired by.

GYP even creates platform-appropriate containers for your tests. For example, on iOS, it will automatically create an iOS app to contain your tests so you can run them in the simulator. You just write your tests in cc files, add them to a gyp file, add the right dependencies and viola, you have cross-platform unit-tests.

At MobileSpan, we implemented the core of our business logic in a cross-platform library that is built using Chrome. We then built our UI per platform that uses this underlying library. Porting our app to a new platform means mainly building the UI layer on the new platform and then tying it together with the cross-platform client library.

Conclusion: Tying It Together

If I am sounding like a Chrome fan-boy, that’s because I am one. Since we embraced Chromium more than 2 years ago, we have found it to work really well for us as a dev platform, saving countless person-hours. It has allowed us to reuse some really well-written and, more importantly, well-tested code across several client platforms, and to concentrate our efforts on making a solid product that works equally well on multiple platforms.

Items for a future post

This just scratches the surface of using Chrome source as a development platform. What should I cover in a next post?

Some options include:

  • Deep dive into specific libraries like Network, Crypto, etc.
  • Keeping up to date with Chromium sources
  • How to fork and keep your sanity (and knowing when to fork certain sources)
  • Process of checking out Chromium sources
  • More details on cross-platform UI development

Have you poked at Chrome's codebase or used it to build a cool product? Tell us about it in the comments section.

 

Comments

Love the post. Would like to hear more about:

1. Cross platform UI development 

2. How you've setup your source tree structure - i.e. how do you build / link with the Chromium sources.

Why did you decide to roll your own chrominum build vs Node-Webkit or Adobe Brackets Shell? Could you share your build structure?

Isn't the chrome codebase C++? And if it is, isn't that less than ideal for a "C runtime"?

Examples? This sounds amazing. Mind posting a few examples on GitHub? 

Yes the codebase is C++. The C runtime contains C++ libraries too. Our codebase is also largely C++.

What about Java ?

In a future blogpost, I will go into specific usage examples and more detailed instructions.

+1 for examples on Github

what about java?

I would like to hear more about

  • Process of checking out Chromium sources
  • More details on cross-platform UI development
  • More details on Chrome Standard C++ Libraries.

 

Thanks

 

Lalit Mohan

Excellent. Looking forward to more.

Thanks for the feedback, Lalit. I will keep that in mind for the next post.

I am thinking of building an app in QT with Python. I want it to run everywhere. Is there a case here to use Chrome?

Or, maybe use a proper cross platform framework like Qt instead of reinventing the wheel?

Any thoughts on using Chrome/Google's auto-update code?

Hey, I would love too to see some kind of example on how to create a project using the chromium source

Interesting article! Once you embed Chromium I think it should be simple to implement (most of) the UI in cross-platform HTML5 as well, right?

For the people asking about Java -- Oracle's current JDK 7 ships with JavaFX 2.2 which in turn offers the WebView class. And this is a full-fledged Webkit browser engine that can run HTML5 apps and communicate with the Java main program, so it's already possible to use a similar setup in Java. I don't know how useful it would be for networking, though, given that Java already offers plenty of networking facilities. I think it's more interesting for cross-platform UI development.

You are a star! Thanks for the great post.

I'd also like to echo Lalit's comment regarding the C++ libraries

Luigi

This sounds awesome. I cannot wait to read more about UI.

Interesting, very... But I agree with some others visitors : Why don't you consider Qt  instead ?

Thanks for interesting article. BTW, is it possible to use ODBC (via UnixODBC and iODBC)?

http://stackoverflow.com/questions/7548825/what-are-the-functional-differences-between-iodbc-and-unixodbc

 

deep dive those libs pls

I would drop the startup, and build an online paid training site for teaching this.

-- Ron 

Very interesting post, thanks! Can you give some examples of compiled program sizes?

 

Marius

I do wonder why you're not using something like Qt which is far more solidly established, has better documentation and official support channels, is also open source, and will be easier to find talent for.  In addition it addresses more things like the cross platform UI development piece.

Did you evaluate other cross platform libraries?  Why go with chrome over those?

What are your thoughts on Embarcadero's Delphi XE5? It allows native multi-platform development, including the one-time creation of the UI, by recreating (imitating) each platform-specific UI.

The write up is interesting but an insult to software developers over the last 30 years.

You don't seem to list any basic container types, like stacks, deques, trees, et multitudious cetera.  You don't mention unicode handling. (That's probably implicit in the browser code, but I'm not building a browser.  I need utilities for handling utf-8 and for converting it back and forth to utf-32.  If these aren't accessible (i.e., too thoroughly integrated into the browser), then it's not likely to be worth the effort.)

A link to an API would have been useful.  As it is I'd need to learn the code to even get an idea as to whether it would be useful.  (If you had such a link, I didn't find it.  I want to check the API *before* I decide to look at the source code...which can take weeks to properly assimilate, particularly if nobody has bothered to document an API.)

I don't see anything about SOAP in those network libraries.

Are you using well-defined Chrome interfaces that Google guarantee will not change? If not, it looks like you run the risk of continually having to tweak your code to fix breakages caused by Chrome updates, bearing in mind Chrome's update frequency is pretty aggressive.

There were several questions above that I will try and answer in one reply:

Chrome's auto-update mechanism is Omaha and we do use this for auto-updates. It works very well and has allowed us to silently and seamlessly update our app. Of course this only works on Windows and not on iOS.

 

You could use Qt if that suits your purposes and if the licensing meets your needs. For us, we needed higher-level abstracts such as a P2P client, XMPP client, remote desktop client/server etc. all of which work equally well on multiple platforms. The licensing for Qt is very different from that of Chromium.

I will work on providing more samples in future posts.

For UI, we have not use any Chromium code yet (though we may in future). The UI layer is built in a platform-specific way on top of the underlying cross-platform client library which is build on top of Chromium libraries. This also allowed to have very platform-native UI. For example, our UI on Windows is very similar to that of Windows Explorer.

Basic container types are provided by STL which is what Chromium also uses.

The post has a link to the Chromium website which had detailed instructions on checking out the code and building it.

Nice article, but a small example would be nice. A small basic app code example.... that is able to run on WindowsPhone, iOS and Android... 

I have been working with Xamarin and other platforms. But getting things actually to work on each platform is not so easy is my experience....

A catchy name often helps a new idea become popular. I suggest Vanadium - the element with the atomic number before chrome.

Chrome-vanadium is also the name of a strong steel alloy.

Thank you, great post. How about cross UI development?

 

 

There are still many questions need to be answered, most importantly how would you setup a build structure in Git and whatabout Java?

+1 for an example on github

What about licensing?

Thank you very much for taking the time to share your development experience based on Chromium. Indeed, Chromium is a wonderful open source project that ought to see more usage elsewhere. 

Theoretically building applications on top of the code base is a win, but my experience is there is usually too much trouble re-using Chromium code unless building consumer facing endpoint apps that uses C/C++ code. Beyond standardized protocol and APIs (http://dev.w3.org/html5/websockets/), I would like to see some examples of re-using Chromium modules' code in other applications. Looking forward to more insightful posts!

How could this differ from using something such as the Chromium Embedded Framework project (https://code.google.com/p/chromiumembedded/)?

C/C++ languages are the ugliest and most time-consuming ones comparing to f.ex C#,VB / .NET Framework

Its like reinventing a wheel and going backwards. There are already tools that have advantages platform-wise. 

Hi, which build system(s) do you use? I believe Gyp can build to cmake or ninja or vcproj or gmake. Do you use ninja at all?

Yes, GYP can use ninja as the build system too. We have not yet moved to ninja. We are still having GYP generate vcxproj and xcodeproj files.

After reading your post, I've managed to build Chromium. Could you give an example GYP (perhaps on GitHub) where you link a stand-alone, outside-chromium-source hello-world executable against, say, base.lib?

+1 to CEF3 -> where does it sit in your overall strategy. There is also appjs-deskshell 

https://github.com/sihorton/appjs-deskshell which is like node-webkit, and brackets. Any thoughts on those?

Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <br /> <ul> <ol> <li> <dl> <dt> <dd> <table> <tr> <td> <em> <b> <u> <i> <strong> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <embed> <object> <param> <strike> <caption> <tbody>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.