Mobile web development is tough especially when you're trying to offer native-like experiences to users. Several years ago, a small company called Nitobi took on the effort of simplifying building native mobile apps using traditional web development skills. Ambitious and sometimes controversial, the effort known as PhoneGap grew out of this need and one converts left and right.

One of the main masterminds behind the framework is Brian Leroux who apart from being well-respected for his development skills and incredibly likeable personality is also one of the savviest mobile developers around. Considering the number of mobile devices PhoneGap targets, you have to be pretty well-versed in a variety of devices and OSs.

Nitobi has since been acquired by Adobe and the PhoneGap codebase donated to the Apache Software Foundation to continue its development as the Apache Cordova project. Brian moved over to Adobe and continues to steward the codebase. In this interview, we'll chat with Brian about how PhoneGap came about and what the future of mobile web holds.

Hello, I'm Brian. I work on Apache Cordova, PhoneGap, and a new css library called Topcoat at Adobe. In my spare time I created a code joke site called http://wtfjs.com which kind of follows me around.

I've definitely been one of the stewards of PhoneGap but it is very important for me to say that MANY people of contributed to the creation and growth of it. No one person really decided to do anything it was a lot of forces coming together at once. PhoneGap was an outcome of the primordial soup that was the new Github model for open source, nascent mobile web browsers, and new generation smartphones. We started hacking, and did the whole thing in the open, and eventually more people subscribed to the project philosophy and utility. It grew from there.

Adobe acquired Nitobi in 2011! It is a little hard to believe that was close to two years ago already. Since our acquisition we donated the source of PhoneGap to Apache which is now known as Cordova. We are constantly improving project, adding features, polish, performance improvements, new tooling, and recently we shipped a vastly improved plugin architecture. PhoneGap has become as much about tooling and extension as it is a fancy embedded web browser for building apps.

We're also working closely with a new team at Adobe on a CSS library called Topcoat that is designed for building fast and clean apps. Of course, everything in Adobe Edge is growing mobile consciousness as a part of our focus on web technologies. Brackets is great for authoring web centric code. Reflow and Inspect are great new tools helping tame responsive design. We'll see more and deeper integrations between these tools and PhoneGap in the future.

Adobe PhoneGap is a downstream distribution of Apache Cordova. It is the same as the relationship of Safari to WebKit. When Adobe acquired Nitobi the original source of PhoneGap was donated to Apache to continue its open development, and encourage contribution from the wider developer community. It has been really great, and the community has grown exponentially since joining Apache. It was a great move for the project and has really matured the development.

Author Note: Brian goes into more detail about this in this blog post.

I think our popularity is owed, in part, to very clearly defined principles and goals. We want the web to be a first class platform and we often state a purpose of the project is to cease to exist. It's a powerful acknowledgement of our intention to get back to web development. This resonates with the web community.

PhoneGap is also just a really good name that clearly communicates the project succinctly. We got lucky there. I'm not sure if it was Brock Whitten or Andre Charland whom coined it. Rob Ellis was there but I doubt he'd remember either. I hated it at first but after five years of working on the thing I'm sort of used to it!

The adoption of PhoneGap was probably a little bit of dumb luck too. I'd like to think we made some of that luck with a regular release cadence and a strong testing philosophy. We rarely have regressions, and we ship quality releases continuously. That healthy activity has helped to build the confidence of our developer community, and the businesses and organizations that are using PhoneGap today.

Well, on one hand it is super easy to get started building a web app. On the other hand, web apps can grow complex quickly, and the devices we're talking about don't have a whole lot of horsepower to begin with. Software development is a balancing act. We're balancing all sorts of forces. Skill and code reuse. Adding more features or working on performance.

Most mobile operating system vendors are contributing directly to Cordova!

We have friends from Google bringing Chrome Packaged Apps to the fray. Mozilla is ramping up Firefox OS with us. Canonical has hackers working on Ubuntu Phone. Blackberry has a bunch of devs bringing us the Blackberry Webworks perspective. Intel and Samsung representing Tizen.

Early in the PhoneGap project, before all this glamorous Apache business <g>, we were temporarily blocked from the App Store by Apple. It was the best thing ever. It brought a tonne of attention the project. After much kerfuffle, Apple reviewed our code to our mutual satisfaction that we were not in violation of any of the App Store policies and PhoneGap apps have been shipping there ever since.

Well if you have an existing investment in web content or web developers then PhoneGap is worth looking at. If you are looking for portability then web technologies are obviously useful, and this can even mean on a single platform, but able to automatically target handset and tablet form factors with a single codebase.

I used to say that web technology isn't really the best choice for games. But this depends on the type of game. Mobile games in particular tend to be more puzzles, card, or two dimensional sorting things that do not require immersive graphics. Web technology is surprisingly good for these types of games. Until we get better support for WebGL I think going native is still compelling. The W3C and browser vendors are very aware of this shortcoming and it is only a matter of time before the Game Controller, Orientation Lock, Fullscreen API, and the Audio API are fully realized. The console will move into the browser and monetization will move towards a service model as a result.

Well, if you have the time to invest in a particular platform (sometimes proprietary too) then going native is a fine, if costly, route to invest in.

It is easy to write a crummy native app as it is with web tech but it is even easier to debug these things using the native platform tooling. That tooling integration makes most development environments very comfortable, with great documentation, and distribution is kind of built in. (You get these advantages with PhoneGap too as that we do not hide these details.) I encourage developers to always be learning as much you can and native mobile development is super fun stuff to learn.

That said, I'm not as convinced about the business benefits of going native. You inherit a reliance on (often) proprietary tooling and distribution channels which is inherently risky. When the vendor makes a change so do you. If they chose to shut down, deprecate, or otherwise abandon infrastructure you rely on for revenue you will have no say or recourse. I personally would not build a business in that way, but I can also respect that some do, and either way you can use PhoneGap to mitigate that risk.

Offline is still messy, we have App Cache but it is really complex and creates a janky user experience. When a new version is available you have to prompt the user to reload. But I have high hopes for the Navigation Controller effort to fix it.

Push notifications are another thing the web needs to get right. Notifications are crucial for user engagement. Those standards and support are starting emerge in desktop web browsers but we need those capabilities to rise up into the mobile web browsers.

The security models for packaged apps is in need of refinement. But that is happening. As a result we will win more and better device APIs. Firefox OS and Chrome OS are going to point the way. We're going to do everything we can to help by providing a quick prototyping surface for browsers.

Developer tooling experience needs love. It is getting pretty good and there is a real healthy competition between Firefox, Chrome, Opera and to a lesser extent IE and Safari. Performance instrumentation for monitoring and especially post deployment crash reporting would be particularly nice.

Thank you Brian

I want to thank Brian for taking the time to provide us with the history of PhoneGap and his insights into mobile web. If you're interested in building mobile applications using your web development skills, be sure to check out Apache Cordova and Adobe PhoneGap.

This is a guest post from high school student Ethan Eirinberg about his experience learning to code, and how he’s now encouraging other students to do the same with his recently launched creative coding competition, CreateHS.

When my brother was a freshman in high school, he wanted to create an iPhone app. Much to his surprise, building a simple iPhone app was a complex task. To get him started, he bought lots and lots of boring books. After 2 years and 19,000 lines of code, he finally released his app to the Apple app store.

His app inspired me to learn how to code. But two years, five huge books, and 19,000 lines of code didn’t sound appealing. So I went online to learn, but I didn’t know where to start. This process was extremely frustrating to me.

I waited until high school. Much to my surprise, when I entered high school, there was no programming class that I could take. In fact, there wasn’t even a club I could join to learn coding. In the meantime, while looking for solutions, I saw an article that said that Treehouse was giving away accounts to their website. Unfortunately, it was only available to college students. I passed it on to my brother.

About a month later, he called me to let me know that he had won! He was ecstatic. As was I. As soon as he returned home from college, I begged him to let me try it. I must have spent hours that night watching video after video. I’d learned more in a couple hours than I had with all the other websites I had tried.

I had finally found a solution to my problem. I began to think… “if I had this problem, I bet other kids in my school did too”. I set off to create a club. But who could teach it? I surely wasn’t good enough yet. So I called Treehouse to ask if we could use their website to teach us. I was ecstatic to hear that they were as interested in teaching high school kids as I was. I went to the student activities coordinator at the high school to get the club started, but I needed a teacher sponsor. After months of searching and planning, we finally started the club. We were so lucky that the only computer science teacher (AP Computer Science is only available to upperclassmen) agreed to sponsor it.

Last year there was a total of 40 members, but I hope for it to continue to grow this year. This past summer, I spent time thinking of new ways to motivate the club members. I thought it might be a good idea to get the members involved with competitions, but as I looked for competitions in which they might want to participate, there were none that encouraged creating. They were all based on solving problems.

So I decided to create my own. CreateHS is a website that encourages high school students to submit entries to the monthly challenges provided. The beginning challenges are to create websites with specific functionalities. The entries are judged on creativity, challenge requirements, and design. With the continual support from Treehouse and other companies, I hope to grow CreateHS to a global scale.

To learn more about CreateHS, check out its featured article on ReadWrite.

The post Student Success Stories: Ethan Eirinberg appeared first on Treehouse Blog.

The following is a guest post by Shane Osbourne (@shaneOsbourne) from England. Besides being a musician, Shane is also an open source developer. Shane has developed a tool called Browser-sync for making CSS injection work across a wider swath of browsers than you might assume possible. And it does more than that, I'll let Shane tell you about it.

The ability to inject newly-modified CSS on every file change (without reloading the page) is the type of workflow-enhancement that you never truly appreciate... until you lose it.

This is exactly what happened to me recently.

For at least the last 12 months I had been using Grunt and the LiveReload browser extension to inject CSS when my files changed. It felt like a really nice workflow until I had to work on a project that required IE7 & 8 support. The LiveReload plugin I was using simply didn't support older versions of IE. For the first time in over a year I had to resort to manual page-refreshes every time I made a change to my CSS. It was painful. It's also why I built Browser-Sync

Introducing Browser-Sync

Browser-sync is a tool that gives you cross-browser CSS injecting. It will watch over your files and the moment you make a change, it will inform all connected browsers to reload (inject) the new CSS. This all happens without reloading the page. Most importantly, it works in every browser I've been able to test it on.

How Browser-Sync came to be

I knew from the outset that simply inserting new CSS into browsers is easy enough to do. The issue I had to solve was how to communicate a file-system change back to the browsers. The Grunt + LiveReload combination I was using previously relied on Web Sockets. This is why there was no support for old IE.

Say hello to Socket.io

I had my lightbulb moment when using Karma for running unit-tests. Karma allows you to run tests in multiple browsers. While testing in IE8 one day, I realized that Karma was automatically re-running the tests on each file save.

Bingo. I had found something that was able to watch the file system for changes and inform browsers all about it. I started to dig into the Karma source code. Eventually I discovered they were using Socket.io to achieve this.

Starting to come together

Everything was in place. With the pain endured from manual page refreshing as my driving force and the discovery of Socket.io as my inspiration, I was well set-up to build a tool that I would use myself on a daily basis.

Getting set up

This guide assumes you already have Grunt installed inside a project and know how to use it. If you don't, then you can learn about it on the Grunt site.

Browser-sync can be installed as a stand-alone command-line tool, or as a Grunt plugin. Because of the current popularity of Grunt I'll focus here on how to set it up as as Grunt Task. If you would prefer the command-line only approach, please checkout these instructions.

From the same file directory as your Gruntfile.js:

npm install grunt-browser-sync

This will install Browser-sync locally into your project. Now you can make sure it's loaded by Grunt by placing this near the end of your Gruntfile.js:

grunt.loadNpmTasks('grunt-browser-sync');

Finally, like all Grunt plugins, you'll need to provide some configuration. At a minimum, you'll need the following:

// Inside the Gruntfile.js config object
    browser_sync: {
        files: {
            src : 'assets/css/style.css'
        }
    }

With your config set up, you can run the plugin with this command:

grunt browser_sync

Now you should receive an HTML snippet that you can paste into the footer of your website. Place that there. Now whenever you change that CSS file (or it's changed by another build process), it will be automatically injected into all browsers.

Note: there are ways to specify multiple files and you can use wildcards (*) too. Please see the Readme on Github for more information.

A more automated approach

The example above is great for those situations where you already have a server. Building a site with WordPress or Rails, for example. But the downside is that you have that manual step of copying & pasting a snippet into a file. If you're working with static files (HTML, CSS, & JS) then you can use the built-in server instead. The built-in server will automatically insert any HTML snippets needed so you don't have to.

To use the built-in server, just set your config like this.

// Inside the Gruntfile.js config object
    browser_sync: {
        files: {
            src : 'app/css/style.css'
        }, 
        options: {
          server: {
            baseDir: "app"
        }
      }
    }

Files will now be served from the app directory and all the magic needed to inject CSS will be done for you.

Going even further

If you use the server option above, did you notice the IP address and port that is used? Normally something like 192.168.0.8:3001? Browser-sync tries to figure out a good external IP address to use for the server. That means you should be able to connect to it from any device/computer on the same WiFi network. The cool thing here is that the CSS injecting will work across all mobile devices and tablets too. When you see this type of automation in action, you're going to find it hard to live without it.

If it doesn't work for you

In my tests, I've found that on typical WiFi networks, Browser-sync does a fantastic job of getting the correct IP address. However, in a large office setup, you may find that it chooses an IP that is not accessible to other devices/computers. If this is the case, and you know what the correct one is, just provide it as an option like this:

// Inside the Gruntfile.js config object
    browser_sync: {
        files: {
            src : 'app/css/style.css'
        }, 
        options: {
          server: {
            host: "192.168.1.1",
            baseDir: "app"
        }
      }
    }

Beyond CSS injecting

Being a guest post on CSS-Tricks, I've focused mostly on setting up the CSS-injecting part of my tool. But Browser-sync does a lot more than that! It has something awesome called Ghost-mode.

Ghost mode will keep track of all connected browsers and keep the following in sync:

1. Scroll Position - extremely helpful when developing with multi-monitor
2. Form Fields - fill out a form in one browser and all others will be populated with that data.
3. Links - Reviewing a few pages of a newly built site? Have it open on all your devices and when you navigate from page to page, all the browsers with follow you around!

Conclusion

I hope this all sounds pretty cool to you. I loved building Browser-sync. I welcome feedback and issue reporting so that we can improve it as a community.

Remember Browser-sync can be used two ways:

• Stand Alone - installed globally, use anywhere
• Grunt Plugin - installed locally, configure as grunt task

Cross Browser CSS Injection is a post from CSS-Tricks

AMST 422: Preserving Places, Making Spaces in Baltimoretrains students to complete research in cultural history and develop related public programming working with a community in Baltimore city. For spring 2014, we are working with the historic industrial community of Baybrook, which includes Brooklyn and Curtis Bay and the “lost neighborhoods” of Masonville, Fairfield, Wagner’s Point, and Hawkin’s Point. AMST 422 students have been working with residents of the community since 2009. The course incorporates the skills of social entrepreneurship—using entrepreneurial methods to produce measurable social outcomes. The culmination of the course is a public event in the community. Students complete numerous hours of community service, including attending community meetings, park cleanups, citizens on patrol walks, college fairs, and community gardening events to build relationships with residents. AMST 422 students will work with Professor Steve Bradley and his ART 390: Imaging Research Center (IRC) Fellows students on the final community event and populating the Mapping Baybrook digital exhibition with content: http://mappingbaybrook.org/  

During the semester, Students will research the environmental history of both industry and the green space in the community. We will also work with “green businesses” emerging in the area and with Jason Reed, who runs the Filbert Street Community Garden in Curtis Bay. Reed received an Open Society Institute (OSI) Fellowship in 2011 to continue his work with the garden and connected projects—which he calls the Curtis Bay-Brooklyn Urban-Agriculture and Stewardship Program (CUSP). The project uses urban agriculture to improve the health of residents, foster community pride, and increase awareness of the need for land stewardship and good nutrition: http://www.filbertstreetgarden.blogspot.com/ 

Central questions the spring 2014 classes will explore are: What is environmental justice? What are the parallels between the disciplines of art and history? Can students develop hybrid methods of inquiry? What does true interdisciplinary collaboration look like? How does collaboration complicate and enhance the learning experience? How can art and history be used to enhance justice in urban communities?

Course funded by seed money from a Kauffman Faculty Innovation grant and a Breaking Ground grant.