Metro HTML5 Apps

One of the most exciting aspects of development for Windows 8 is the ability to build a native app using nothing but HTML and JS. I think this is a huge advantage over other platforms, and one that will help liberate HTML apps from the browser and bring them to the desktop in a way that no other platform has been able to do. All of this is made possible by Windows Runtime (WinRT), which is built into the core of the operating system.

As you can see, there are now three pillars for building Win8 apps: C++/XAML, C#/XAML and JS/HTML. It’s this last pillar that enables us to take any existing HTML5 Canvas-based game and turn it into a native Metro app with very little modification at all. In addition to simply being able to port over your JS game to a Metro app, Win8 provides an entire JS runtime with hooks into the OS via the WinJS library. These hooks allow you to extend your HTML5 app even further and blend it seamlessly into the OS. For the purpose of porting over Impact games to Win8, I am not going to touch on WinJS, but you should read more about it since your game will probably need to hook into Win8 core systems such as the file system, screen resize events, application focus events and any Metro-style controls you may want as part of your game’s UI.

In addition to the power of running HTML5 games natively on Win8, Visual Studio 11 also got a huge update to help support building JS applications. VS is now on par with the likes of WebStorm and other powerful HTML5 IDEs by proving code completion, refactoring and support for Metro-specific hooks provided by the WinJS runtime. I highly suggest giving VS a try since it’s the best and only way to build Win8 apps right now but, as the platform matures, VS is going to end up being one of the best HTML IDEs out there. I loved using VS for C# WP7 dev and am really excited about the new HTML, JS and CSS support MS is adding into it.

Getting Up And Running

One of the advantages I had over starting from scratch when it came to making an HTML5 Metro game was the Impact game framework. I have talked about this framework before and, since I already had a bunch of games written in Impact, it was a no-brainer to just port them over as is. One thing to keep in mind is that there is now a JavaScript equivalent of XNA for Win8 so, if you don’t want to use Impact, you will have to find another game framework or build one from scratch. Grant Skinner has been optimizing his own JS frameworks to run on Win8, and the consumer preview ships with one of his Canvas-based games called Pirates Love Daisies. I suggest you give it a try, but keep in mind that Impact is made specifically for game development and comes with its own level editor, which can help dramatically speed up your game development.

Once I had a basic Impact game ready to go, it was incredibly easy to get it set up in Visual Studio. I simply created a new JS-based Metro project and copied over my code into the project.

Here you can see I am simply selecting the Blank JavaScript Metro app template.

One I created the project, I copied over my game’s lib and media directories.

Don’t forget that you need to manually add your files to the project. You do this easily by following selecting show all files.

Now you can see all the hidden files which apear with grayed out icons. Simply select the files or folders you want in your project then right click and pick “Include In Project”

Once all your Impact files are included in the project, you will need to set up the default.html file to import and load up your Impact code. I simply copied over the contents of my Impact index.html files over to the default.html and everything worked great. One thing to keep in mind is that by replacing the contents of defult.html you lose the references to the WinJS runtime so becarfuul as you copy your code over. I would take a look at the default.js file to see the hooks for handling launching, exiting and resuming your game as part of the Metro App’s lifecycle.

Now, with everything linked up, you can compile your game and test it out.

The app should run great, but there are a few more things you may want to consider when moving forward:

• It’s really easy to set up Metro live tiles, which represent the icon of your game on the Win8 launcher screen. You have a lot of freedom when it comes to designing these, so check out this article to learn more about how to set them up.

• Metro apps have a minimum resolution of 1024×768 but actually support many different resolutions larger than this. It is good to think through how your application is going to scale across different screen sizes by checking out the following article.

• Check out the WinJS APIs and map out what features you want to support in your game. This may be especially helpful for UI or saving files to the local storage system.

• In the end, once you have linked up your Impact code to the default.html file, you should have everything you need to run, debug and test your game. From there you will need to add support for keyboard/touch controls, optimization and eventually look into publishing your app to the Win8 Store, which you can learn more about here.

Here is a screen shot of the game running with touch controls so you can play it on Window 8 Slates and I also have the Impact profiler running to test out performance.

As you can see the game is running smoothly at 60 fps on the preview device I got at the Microsoft Build conference.

Optimization

After I had my game set up in Visual Studio and everything was compiling, I started to notice some performance issues. Out of the box my game was running at 30-40 FPS, but I wasn’t very happy with the performance. My game was skipping frames and sometimes the system lag would lock up the game. What was confusing me was that the draw calls in the game were being executed incredibly fast. Canvas, by default in Win8, is hardware accelerated. At first I attributed this to the higher resolution but, after some research, I started to learn that Win8 games run slow if their game loop relies on setInterval instead of requestAnimationFrame.

Unfortunately this wasn’t an easy fix. This required patching one of the core classes in Impact to make the modification. Dominic, who created Impact, used to use requestAnimationFrame earlier on in the framework’s development but pulled it out. I reached out to him and he gave me the following plugin which I was able to use in order to patch the framework to use requestAnimationFrame. Once I loaded this plugin into my Win8 version of the game I saw an incredible boost in performance. Dominic is aware of the issue and will hopefully add support for requestAnimationFrame in future builds of the framework.

I also want to point out that the slowdowns weren’t solely related to requestAnimationFrame; my game was not optimized at all at this point. Before I started building the Win8 build of my game, I had only focused on desktop with no mobile optimizations at all. While Win8 on my development devices is as powerful as a desktop computer, you really need to think of these new computers as mobile devices. This means that any optimizations you would normally make to an Impact game to run on iOS’s browser will make a huge difference in the performance of your game on Win8. Part of the issue is the incredibly high screen resolution of Win8 apps. The goal really is to limit the number of draw calls your game is making. Here is a list of optimizations I performed, which drastically improved the performance of my game:

• Pre-Render Layers – Make sure your map layers have “Pre-Render in Game” selected, which will speed up the rendering by creating larger images of the tiles resulting in less draw calls. The only down side is that you will not be able to have animated background tiles, but the increase in performance is noticeable.

• Limit Entities On-Screen – I started relying on lots of object pooling and limited the number of entities being spawned at any one time. This was especially expensive with all my blood particles that were getting created when entities would die. If I had a level with 10-20 zombies, and a grenade would go off killing most of them, it would spawn almost 20 blood entity particles per zombie. By reducing that to around five, I dramatically increased the responsiveness of the game when lots of entities would die at the same time.

• Limit Weapon Fire Rate – This is along the same lines as limiting the number of entities on the screen, but I wanted to call it out specifically. I went through and added object pooling into my weapon classes and also limited the number of projectiles per weapon. So, guns could only shoot three bullets at a time, shotguns could only do one bullet at a time and I restricted the player from throwing more than one grenade or land mine at a time, since they tended to kill more than one entity, which contributed to the blood particle slowdowns.

• Remove Text Where Possible – Text ended up being the biggest rendering issue I found in Impact. Every text field you render out incurs a draw per character so, if you have a HUD with the score and other stats at the top of the screen, you could end up with an additional 50 draw calls that will bog down your game. I removed the stats from the top of the game and put them in the pause screen. So, when you pause the game and all the entities stop drawing, the game has enough resources to render out all the text.

• Pause Entities – The last optimization I did was to add logic to correctly pause or suspend my entities when I needed to. Every time pause or game-over screens come up I still need to call draw on all the entities, but I added a flag to each one that lets the render loop know if it should pause or ignore the pause. This is helpful when you have menus that rely on entities to render out text or images but you want the rest of the game to be suspended behind the screen. Also, make sure you take into account any timers you may have running when the game pauses and restore them correctly or your game may get out of sync.

While this may seem like a long list of optimizations you need to make to your game, realistically you should already be doing this kind of stuff in order to support other slower platforms such as mobile. Win8 is going to be a huge mental shift for desktop and Web developers since you can no longer throw anything at the application and assume it will run. Win8 is going to be on high-end hardware as well as low-end mobile devices, so it’s incredibly important for your game to scale accordingly. That means building for the lowest common denominator first if you want to have the broadest reach possible. Unfortunately, I have not been able to test my game’s performance on an AMR device, but all the optimization tips I have outlined above will help keep your game running smoothly on any device.

MS-Specific Hacks

I wanted to talk a little bit about some of the specific IE hacks I had to do in order to run my game. While Microsoft touts IE10, which is the backbone of HTML5 Metro apps, as being standards compliant there is a lot of gray area in their interpretation of “compliant.” While it is true that IE10 is light years ahead of IE8 and some aspects of IE9, the fact still remains that in order to access a lot of features WebKit browsers take for granted you will need to use MS namespaces in front of specific hooks in IE. The two biggest offenders are touch events and requestAnimationFrame.

I briefly talked about needing to use requestAnimationFrame above in my optimization section and, while this is becoming a standard across all browsers, MS still uses its own implementation of the feature via the msRequestAnimationFrame hook. While this is easily fixed with a polyfill and some conditional magic, the fact still remains that even with IE10′s support for some of the new standards being proposed as part of the HTML5 spec, you should still expect to have to preface your API calls with MS namespaces.

While requestAnimationFrame was easy to fix, adding touch events to an existing Impact game was a little bit more of a chore. IE does not support the WebKit implementation of touch events and has its own completely different API. This meant that I had to hack Impact’s input class specifically for IE10 on Metro. Here is a sample of how I was able to handle touch events:

addEventListener('MSPointerUp'...

and

addEventListener('MSPointerOver'...

I found this really annoying because, while touch events aren’t standardized yet as part of the spec, I consider mobile WebKit to be the standard seeing how iOS, Android and even BlackBerry all implement it. MS should have tried to build off the predominant API instead of introducing their own system. This means that you will not be able to support touch events out of the box or with a simple polyfill, so be prepared to have to tailor your touch events specifically to IE10 until Dominic modifies Impact’s core to support IE10 when it eventually launches.

The last MS-specific issue is that it’s incredibly difficult to determine what platform Win8 is really running on. Is it a touch device or does it have a keyboard? Is it a desktop or a mobile device? These questions are incredibly difficult to answer without doing a lot of testing and, even after polling the browser to figure it out, you still don’t have a clear idea of what the processing power of the Win8 device is. This means you need to support everything out the gate. So, when I would normally disable touch events on desktop and enable them on mobile WebKit, I just end up leaving all the events in because at any point you could turn a Win8 touch device into a desktop by docking it and adding a keyboard. Hopefully how to differentiate devices will become easier over time as MS fine-tunes the OS, but right now without any real devices to test with it’s going to be a lot of trial and error optimizing your games on all the different types of devices that will support Win8 at launch.

Moving Forward

While I focus on the trouble spot I had with porting over my game to highlight issues you need to take into consideration, I don’t want to overshadow how incredibly cool it is to actually get my HTML5 game up and running on a desktop with very little additional work. Most of the issues I had can be quickly patched in Impact and, if you are not considering doing multi-platform deployment with your Impact game, then it should be really easy to get your game up and running in no time on Win8. I was really blown away by the level of performance I was able to get out of my HTML5 Metro game right out of the box, and Microsoft really nailed the tools/workflow for creating Metro apps with HTML/JS. I couldn’t have asked for anything better and, over time as the tools and OS get refined, it’s just going to get better and better.

I am really looking forward to seeing how Win8 runs on ARM devices, and I think that it’s clear this is the direction MS wants to take the OS. Make it as fast and portable as possible. It should help liberate Windows from the desktop and give iOS a run for its money. I am confident that Microsoft will be able to get the performance of ARM devices to be impressive. Right now I am already getting 60 FPS on iOS in the browser with my Impact games, so I don’t see why ARM-powered Win8 devices will be any different.

Right now I would like MS to support more of the WebKit standards in order to help accelerate porting of existing HTML5 apps and games over to Win8. While they have made some incredible headway with IE10, all the MS-specific hacks I have to do in my game make me feel a little dirty inside. It also makes it incredibly hard to deploy my game on different browsers and OSs, which may also be MS’s intent. I didn’t hook into any of the WinJS APIs since they are tied specifically to Win8 and, since IE10 doesn’t run on Macs or Linux, you will always be stuck in Windows from development to deployment. If Win8 takes off then this will be a moot point, but right now the spotlight is on iOS and it’s clearly the leader of the pack. Most, if not all the clients I deal with, have iOS first Web strategies. MS is going to have a lot of convincing to do in order to win back developers who lived through the IE6 Web app days.

Hopefully it’s not too late for Microsoft to catch up but, given the number of Windows computers in the world, even if a small percentage of existing users adopt Win8 we will see massive gains in penetration numbers for the fledgling OS. That means the potential to distribute your app and monetize it is going to be incredible. I truly believe that Windows 8 is going to be the catalyst we have been waiting for to see HTML5 games come into their own. Since HTML5 Metro apps are as responsive as native C# apps, it’s an incredible opportunity to translate your Web skills into desktop development. Now is a great time to get ready for Win8′s launch, so start working on your HTML5 games now!

My Workshop

On day one of the conference I did an “Introduction to HTML5 Games with Impact” workshop. It was great to have another sold-out workshop with 30 registered attendees. This marks the fourth workshop I have done on this topic with my one at Microsoft’s New York office being the largest with over 100 registered attendees. I have full- and half-day versions of my workshops now and have ironed out all the kinks.

I split my workshop into two parts, theory and code review, with a break in the middle for lunch. The amount of material I try to cover is truly massive, and it’s next to impossible to do any live coding. I focus on teaching people how to think about game development, go over a real, fully functioning game and analyze why I set things up in specific ways so that when people leave the workshop they have everything they need to go home and continue their learning. I also hand out copies of my book so that people can go through all the code examples at their own pace after the workshop, and I encourage people to play with the supplied code during the workshop to get a feel for how everything works.

I have been thinking about turning this into a two-day workshop so I can have more time to let people experiment and actually make their own game. Since most of the people who take my intro workshop have never built a game before, I even had a person who never even coded before, it’s incredibly difficult to expect them to be able to make a game from scratch without going through all my material in-depth. Making games is not an easy task, which is why I also focus on how to think through an idea to make a game along with answer peoples’ questions about how to build things in Impact.

My Talk

The day after my workshop I got to do an hour-long talk on “My Adventures in HTML5 Gaming.” This is the second time I have done this talk, and for FITC I gutted about 70% of my original slides and redid them from scratch. I was trying to do the entire talk off of my iPad, from slides to code examples, to show off how powerful HTML5 really is, but I just couldn’t pull it off in time so I simply ran the presentation from my laptop. As I have mentioned, I spoke to a packed room and being able to follow someone like Grant Skinner is an honor. Grant is really doing a lot to help push HTML5 forward. I, on the other hand, have narrowed my focus on the platform to a few specific areas, one of which is game development with the Impact framework. I wanted to share some of the material from my talk for those who couldn’t make it out in person to see me present.

I start my talk out with the following quote:

“Success consists of going from failure to failure without loss of enthusiasm.”
- Winston Churchill

I love this quote, and it really highlights my experience trying to make games with HTML5 as well as development in general. I am not a professional game developer, and I wouldn’t argue that I am even a good game designer. I make this very clear in the beginning of my talk. I use game development in a much different way than most people would think. I have always loved making games but ended up doing agency and enterprise development for my day job. For me, games are one of the most challenging programing systems to build, and I use games to teach/push me to be a better developer. Whenever I learn a new language, I always start by making a game first and, when it comes to my day job, I use everything I have learned from games to help me be a better application developer. Game development teaches you how to simplify complex systems, optimization and advanced graphic techniques, all of which can be applied to any type of development, especially enterprise.

I have my talk broken up into five parts:

Part 1

Game Design – In this part of my talk, I go over the basics of game design, what a Game Design Doc (GDD) is and tips on how to organize your own game ideas. I talk about how I use a game journal to keep track of the parts of games I play that I like as well as my daily code warmups. A code warmup is a 30-minute coding exercise I use to learn new techniques, try out new APIs or SDKs and vet out ideas while forcing myself to produce something in half an hour.

Part 2

Why Use Impact? – In this part of my talk I go over why I chose Impact to make HTML5 games. Impact is incredibly powerful and one of the best JavaScript game frameworks out there. Most people dismiss it since there is a $100 licensing fee but, once you pay the fee, you get the source code, example games and a level editor, which is worth the price of admission. I also cover how modules, classes and extensibility work in Impact, which is helpful for those developers coming from ActionScript, Java or C# and looking for more structure in their code.

Part 3

Automate Everything – In this part of my talk I go over how I use automation for my asset pipeline and creating deployment builds of my Impact game. I am a big proponent of building automation scripts for all my projects, especially in Photoshop, so I take some time to go over how I created a sprite sheet generator for Photoshop. I also talk about how I use Ant to build out versions of my game for the Web, iOS, Win 8 and the Chrome Web Store. Impact runs almost anywhere so, by taking advantage of the power of Ant, I am able to simplify generating each build I need for all the platforms I want my game to run on. If you are interested in learning more about how I use Ant with Impact, you should check out the post I wrote on my site called “Automating Impact with Ant.”

Part 4

Games I’ve Built – In this talk I go over the games I have built with Impact. I have four examples and talk about each one, what I learned from them and end with a project I have been working on in my spare time for a crowd-sourced rogue game called Tile Crusader. Here are some highlights of my games:

Alone

Alone was created during my first Ludum Dare competition. The game is built around an Edgar Allan Poe poem and is devoid of any visuals except for the words themselves, allowing the players to imagine the game’s visuals in their own head.

Jetroid

In Jetroid, you land on a planet to look for lifeforms and artifacts while trying to make it back to your ship before you run out of air. As you explore the underground caves, you will find power-ups (air, life and energy), new alien lifeforms and artifacts.

Resident Raver

Resident Raver is Super Crate Box meets Elevator Action. The goal of the game is to survive wave after wave of raver zombies that have taken over the dorms at FSU.

I spend some extra time talking about Resident Raver, since it is the example game I wrote for my book, and talk about how I built on top of the book example with more advanced level designs.

I also talk about some of the more advanced features of Impact’s level editor, such as setting up triggers and connecting entities together to create elevators and spawners.

Tile Crusader – Coming Soon

Tile Crusader is a crowd-sourced, coffee break, rogue-like game that gives anyone the ability to pick up and play a random crusade in just a couple minutes. What makes Tile Crusader unique is that the players can also create their own custom levels to share with others.

Since this is an unfinished game, I talk about how I go from
sketch to design to final HTML page.

My initial sketch:

<

My first design in Photoshop:

Refining my first design in Photoshop:

My final design for the game built out in HTML:

The other thing that is interesting about this project is that I have connected the Impact level editor to WordPress so that each level of the game is basically a post, so I have created the first RPG blog ever!

Screen shot of Impact’s level editor inside WordPress:

As you can see, I have been incredibly busy making games with Impact, but it’s important to remind people that making good games is not easy. It takes a lot of trial and error when you are starting out, and game design/development is like any skill, you need lots of practice before you become good at it.

Part 5

What I Have Learned – The final part of my talk focuses on four bullet points of what I have learned while doing HTML5 game development. For the most part, they are self explanatory:

1. JavaScript can be fun when you are making games.
2. HTML5 games are the future.
3. This is just the beginning; it’s only going to get better.
4. Be a leader, not a follower.

I was never a big fan of JavaScript, but I have grown to enjoy it while making games. When learning new languages it’s important to find a fun project to explore how everything works, and nothing touches all parts of a platform like a game. When it comes to HTML5 games being the future, I illustrate how important the iPad is now. I can run all my games on the iPad from the browser and, while there are still issues with sound and performance, most clients aren’t interested in starting a new Web project unless it will run on the iPad. It’s only a matter of time before HTML5 games mature on the Web and we start to see the same proliferation of the platform as we did with Flash. We are still in the early stages of HTML5 game development, and I remember making games in Flash 4 with AS1 and how primitive that was. That was 13 years ago. In another three to five years HTML5 games will easily be on par with what Flash can do today, especially with accelerated canvas and WebGL.

The final part of my talk is the most important. Be a leader, not a follower. This really goes for anything but is especially important when it comes to HTML5. Those people who are pushing the technology forward, sharing what they learn and talking about it are the ones who will be ahead of the curve. Don’t wait for a platform to mature; there will always be something new and better to replace it. If you don’t have the luxury of pushing technology at your day job then spend your free time sharpening your skills. The way I see it is that if you are going to spend your valuable free time learning something new then have fun with it. For me having fun means making games!

Conclusion

It’s been an amazing experience to be able to travel and talk about something I truly love, which is making games. For me it’s all about following your passions, and people will notice and reward your for inspiring them. I am very grateful to have this opportunity to speak at conferences as part of my job at Roundarch Isobar. A big thanks to Dominic, for creating Impact, and for letting me give out free licenses of Impact at my workshops. It’s incredibly hard to find a balance between doing these workshops, my work responsibilities and being home for my family, but so far it has been working out. And, the best part about learning a new technology via building games is that I also get to sneak in some extra practice time on my game design skills. Please check out Impact, and I will be speaking at the end of May in San Francisco at the Fluent conference if you would like to see my talk in person.

Also if you would like to see my slides I have them hosted on Speaker Deck:

First off, let’s talk about my computer setup. I have three main computers that I use on a daily basis: my desktop (27" iMac), my laptop (11" MacBook Air) and my work computer (15" MacBook Pro). On these computers I am constantly switching between OS X and Windows 7. In addition to these three computers, I also have several different phones, that I use personally as well as for testing, and my iPad. Finally, I have a Windows 8 tablet, which I also do development and testing on. As you can see, I have a lot of computers I use daily, and trying to keep everything in sync would be a daunting task if it wasn’t for Dropbox.

After realizing how valuable Dropbox was to my workflow, I upgraded to the Pro account to get 50 gigs of space.

Also, between getting other people to sign up to gain free referral space and taking advantage of a few other offers, I was able to end up with 62 GB, which is more than enough for any dev you may be trying to do. If you haven't signed up for Dropbox yet, you can use my referral link to get extra space when you sign up.

The biggest limitation for me is the fact that my MacBook Air can only hold so much due to its small SSD drive space. While you can limit which folders sync on your computer, I have noticed that, for the most part, my development files don’t take up that much space. You can probably just get by with the 2 GB of free space you get when signing up.

Once I was signed up and installed the software I just used the default folder location. I set up three main directories inside the Dropbox folder:

• design – This is where I keep all my design work for my project, ideas I am sketching out and space to store images I like from the web for inspiration.
• development – This is where I do all my development from. I’ll talk about this folder structure next.
• writing – This is where I keep all my writing. Everything from posts like these (if I am not using Google Docs) to ideas I have, game design docs and even the book I wrote.

I also have a lot of other folders in Dropbox since I keep a lot of my files in there, but these are the main development folders I have set up.

Let’s talk about how I set up my development directory. Here is a screenshot:

As you can see, I work on a lot of different platforms. Here are the most important folders to note:

• sdks – This is where I keep installers, code libraries such as APIs for other services and any dependencies I would need to install to get my development environment to work on another computer.
• tools – These are installers for tools or additional apps I would need to install on other computers.
• web – This is the root of my web server for any HTML, PHP, JS, etc. work. Basically, anything that needs to run on a server, with the exception of node.js, which has its own folder, is hosted from here.

Outside of these core folders, I simply create a new folder named after the platform I’ll be working on. The goal of my development folder in Dropbox is to have quick access to all my projects on any computer as well as all the SDKs and tools I would need to set up a new computer if I had to.

From here I can work directly from any of these folders in my IDE of choice. I’ve tested lots of these IDEs and not had any problems moving between different computers or across each OS. Here is a list of some of the editors I use:

• IntelliJ – For Android/Java dev.
• Web/PHPStorm – For HTML, JavaScript and PHP dev.
• Sublime Text – An excellent lightweight code editor.
• Visual Studio – For Windows Phone 7 and Windows 8 dev.
• Xcode – For iOS development.

As I have mentioned, I’ve not had a single problem working in any of the above IDEs from within my Dropbox folders. The only thing to be careful of is to make sure your IDE saves its project resource files within the project. You may have noticed directories such as .idea or .eclipse in the root of your project like this:

As long as your editor keeps its settings in with your project, even if the folder is invisible, Dropbox still syncs them.

You may also notice from the above screenshot that if you are using Git, or even SVN/CVS, for version control those directories are also part of your project folder, so Dropbox can keep those in sync as well. This is great because I always have the most up-to-date version of my code, regardless if I remembered to check the code in before I left for work or wherever I need access to it. Then I can commit my changes when I am ready from any computer. This solves one of my biggest issues with multi-computer development, which is keeping my version control commits in sync.

Next up, I want to talk about how I handle running local servers and testing from my web folder. On the Mac I use MAMP and on windows I use XAMP, which are great one-click Apache, PHP and MySQL solutions. Normally you would use the default web server directory on your computer to host your files. I have actually set my Apache’s root to my Dropbox’s development folder’s root like so:

Now you may be thinking, why not set this to my web directory in my development folder? If you remember back to how I break up my dev projects by platform, I tend to keep my Impact game dev in its own folder along with any Flash projects or, if I am doing PhoneGap in Xcode, I can launch any web content from within my entire dev directory from the browser. So when I launch MAMP, I am automatically taken to my localhost, which exposes all my projects:

So now my entire dev workspace is navigable via the browser, and when I navigate to a project with web content in it I can test it in the browser. This is critical for doing any kind of PhoneGap or Windows 8 dev where the entire project is all done in HTML/JS, and you can use your computer’s browser to debug as you work much faster than trying to recompile the app on the simulator or device each build.

Here is an example PhoneGap app I was working on called Room112 and wrote about on my site here.

As you can see, I keep all my PhoneGap code in www/ and, if I open the directory, I can test it out right in the browser:

When I am done testing, I simply go into Xcode and compile it to the simulator or my device. When I need to debug I do it all in the browser. I have found this to be one of the best workflows around and, to top it off, all my work is synced thanks to Dropbox.

Now, before I talk about some of the limitations of Dropbox, I want to talk about how I use my development directory to quickly install and share Android APKs to all my devices. Since I do all my Android work in my Dropbox directory, and Android allows you to install APKs from the Android Dropbox app, it’s incredibly easy to immediately test new builds of your application without having to connect your device. Simply install the Android Dropbox app on your phone, navigate to your Android project folder and when you compile a new APK it is right there waiting for you:

This is also helpful if you are doing a lot of AIR for Android development. I even set up my Ant builds to generate output folders for each platform and can share that folder with other people who want to test my game so they always have the latest build:

I have covered a lot of advantages of using Dropbox, but I want to cover a few of the issues I have had and some mistakes to avoid as you get used to this new workflow. Here are a few things to keep in mind:

• While I have never had any issues with missing files or sync conflicts, this setup is not ideal if there is more than one developer working on a project at a time.
• I would also avoid sharing a folder you are actively doing development in since the people you share it with have access to all your files but have to download every change you make. If you want to share compiled apps like APKs or IPAs for testing, just share the output folder for these themselves and only push out updates when you are sure they are stable.
• Dropbox is not a backup solution or version control replacement. Once you delete stuff it’s usually gone forever. You can pay for backup history but IDEs do lots of different non-destructive and destructive modifications to files and directories, so it may be a mess to try and sift back through any changes via Dropbox. Always use version control on top of your Dropbox solutions.
• When conflicts do arise, Dropbox is smart enough to give the files the same name, but one will have a conflict identifier added to the filename so you can tell there was an issue. If you feel like some file has not correctly updated, make sure you check the folder in the OS and not in your IDE. Most project-based IDEs like Visual Studio and Xcode don’t automatically add new files unless you manually include them in the project, so always check in the folder itself first.
• Remember that in order to keep your projects in sync Dropbox needs time to download all the changes when you move to a new computer. Don’t leave your IDEs open or in sleep mode on multiple computers then turn them on expecting all your changes to be there. Always make sure you give yourself enough time to download the latest files before doing any edits.
• Some IDEs such as WebStorm do not store global settings like servers in the project folder. I have had issues moving from computer to computer and WebStorm not being able to remember the default server for uploading web files. This is usually an easy fix but frustrating if you move around computers a lot.
• Pay attention to file paths, especially when doing cross-platform development like moving from Mac to PC because if your project has hard coded library dependencies there will be corruptions in your project. In IntelliJ, I tend to add Mac and PC paths to the project settings so if one fails it can still generally find the right library for the OS it is on. I also just group my project dependencies in the project itself since most IDEs use relative paths for files inside the project and that cuts down on most of the file system conflicts.

While this may have been a long list of things to watch out for, and not a complete list by any means, I have found Dropbox for my development to be an invaluable tool that has mostly solved my biggest problem of keeping my projects in sync across all my computers and devices. I would make sure you start small if you want to give this a test and work your way up. I have done a lot of trial and error perfecting my workflow and, when something does blow up, it’s not fun. As long as you go in knowing that something could happen if you are not careful you will do fine. Plus, there is nothing more gratifying than being able to turn on a computer, wait for all your changes to sync then pick up coding right where you left off. In some IDEs even your last open window and all your code history is saved into the project and synced automatically by Dropbox, which is truly amazing that one time you need to remember what you did at 1AM on the computer you left at home and you are in another state, which happens to me more times than I care to talk about.

One of the most important parts of setting up automated build scrips is reducing the amount of mistakes caused by performing repetitive tasks. Builds are probably one of the most complex things you are going to do in any project and they require machine precision. They are also incredibly hard to document or reproduce over and over again without a script. The problem of maintaining builds becomes compounded when you add in multiple platforms and platform-specific libraries or packaging.

But wait, isn’t Impact a JavaScript-based framework? You may be thinking that JavaScript doesn’t need compiling or packaging. While this is true, once you start trying to deploy Impact to multiple platforms you will quickly see how complex the process can get. In addition you have to “bake” your game, which compresses all your game JS classes into a single file before deploying to help cut down on load time as well as offer basic code obscuring. Let’s take a look at the process I normally follow when it comes to setting up an automated build script and how it applies to Impact.

Target Platforms

As I had mentioned, Impact runs on a plethora of platforms. Whenever I am faced with a project that has multiple deployments, even as simple as QA and production (Prod), I list out all the possible targets. Impact provides us with a lot of options, so let’s take a look at what platforms are supported in a little more detail:

• Desktop Browsers: Chrome, Safari, Firefox and Internet Explorer 9+
• Mobile Browsers: iOS and Chrome for Android
• Web Markets: Chrome Web Store and Mozilla’s soon-to-be-released Web Store
• iOS Native: Impact allows you to compile your game natively for iOS
• WebView Wrappers: AIR, PhoneGap and OS X using a native app with WebView
• Windows 8: Windows 8 allows you to create native Metro apps with HTML5/JS

As you can see, Impact is incredibly versatile and allows lots of options to deploy and monetize your game. Managing all these deployments can be a total nightmare. To help make sense of all the work that needs to go into supporting each platform, I created a matrix that can help identify the level of effort required to support each build:

Now that we can clearly see what we are working with, it is easy to go through each platform and decide if the level of effort has any return on investment (ROI). Creating these kinds of matrices are also helpful to keep track of platform-specific optimizations or modifications to the core application logic you will need to make. While the above matrix has been simplified greatly, I would suggest keeping a more detailed list in a spreadsheet or document depending on how complex your build gets.

Creating An Ant Build

When it comes to setting up an automated build script, there are a lot of languages you can choose from. I prefer Ant since it is easy to pick up, doesn’t require learning any other language, is portable, is installed by default on Macs and exposes all the power of the command line, which you will need for manipulating files on the operating system. If Ant isn’t your thing, I have used Maven, Python, PHP (which is what Impact actually uses for its bake script) and shell scripts. Everything I will set up in Ant should be portable to other build script languages, and I will focus more on the steps required to set up our build script instead of focusing so much on Ant itself.

If you don’t have any experience with Ant, let me give you a quick rundown of how it works. Ant is an XML-based wrapper for executing command lines on your computer. Anything you can do from a terminal or console can be run in Ant. One of the key advantages of using Ant is that, due to its XML markup, it makes it very easy to pick up and start working with. On the same token, XML is not great for logic and, as your build scripts grow in complexity, you will probably find Ant to be incredibly limiting and frustrating. For simple things like Impact, it is perfect.

One of Ant’s key features is grouping actions into tasks, which allows us to break out repetitive actions into reusable blocks we can call over and over again to minimize code duplication in our script. Now that we have a matrix of the supported platforms, we can look at our build process and break it down into tasks to find similar actions we may need to create individual tasks for. Let’s take a look:

• Cleanup – This is a standard task that removes any files created from the previous build. You always want to run this type of task to make sure you don’t corrupt your deploy folder (where our final output will be copied to).
• Post Build Cleanup – Generally, when we are moving around a lot of files, we will create tmp folders to keep our script’s files separated from the main codebase and the final deploy directory. It helps to remove these temporary files once you are done with them.
• Bake – As I had mentioned earlier, Impact’s license requires that you bake your game so you don’t inadvertently distribute the source code, and it also allows you to merge all your JS files into a singe file. The bake script is run from the command line and is written in PHP. Luckily, Ant can execute PHP scripts as long as you have PHP installed in your system and are able to run them via the command line as well.
• Web Build – This will be our base build script. We will make sure that we clean up our final codebase to be deployed to a Web server. We’ll need to point our HTML page to load the baked JS files instead of the default impact.js and your custom game.js files. From here, we will also use this for our other builds since it is our baseline for creating a functional game.
• iOS Build – Since iOS has its own Xcode project, we simply want to copy over the core game code into that directory. The rest of the Xcode project will handle initializing the game on iOS and is not worth us trying to generate any of the iOS-specific wrapper files.
• Windows 8 Build – This is going to be similar to our iOS build. We only need the core game classes, and we’ll rely on the default Visual Studio project to handle setting up and initializing our game for us.
• Web Store – We’ll have two builds for our Web stores, one for Chrome and the other for Firefox. We’ll use our default Web build but handle creating the manifest.json file in Ant (another cool feature of Ant that allows you to write out text to a file). For Chrome, we’ll just zip up the final output so you can upload it to the market.
• Full Build – Once we have all our build targets set up, we can create one master target that will call on each one, in a specific order allowing us to automate the entire process of deploying to all these different platforms.

Now that we have a plan for building out our Ant scripts, let’s go through each one and take a look at how the code will work.
The Build Script

Setting up a Ant build is relatively easy. Each build script starts out the same way:

<?xml version="1.0"?>
<project name="Impact Ant Build" basedir="." default="full-build">
</project>

As you can see, we give the script a name, set a base directory to its current directory and set a default target to get called. Right now we don’t have one set up, so if you tried to run this it would fail. Next we are going to want to set up some properties, which are variables we can use throughout our script to help centralize properties that would change on different developer’s computers at the top of the script.

We are going to start with the following properties, each one of them should be self-explanatory:

<!-- Project meta data -->
<property name="project.name" value="Resident Raver"/>
<property name="company.name" value="GameCook"/>
<property name="company.site" value="http://gamecook.com"/>
<property name="project.version" value="0.8.1"/>
<property name="project.description" value="This is Resident Raver the Game!"/>
<property name="project.url" value="http://gamecook.com/games/resident-raver/"/>

As you can see, we are setting up the project-specific properties. These are the ones that would change from project to project. Things like project.name, project.version and project.description are required by the Web stores in their manifest files, but we can also use these values to name our final output as well as version it.

Next we need to set up some paths to where our files are:

<!-- Deployment directories -->
<property name="deploy.dir" value="deploy"/>
<property name="web.dir" value="${deploy.dir}/web"/>
<property name="chrome.dir" value="${deploy.dir}/chrome"/>
<property name="mozilla.dir" value="${deploy.dir}/mozilla"/>
<property name="ios.dir" value="${deploy.dir}/ios"/>
<property name="win8.dir" value="${deploy.dir}/win8"/>

As you can see, these represent all the directories we will be deploying our final game to. It’s important to note that when you see something wrapped in $() that it is a variable that can be used anywhere in the Ant build script. All these paths use $(deploy), which is set up at the beginning of the property block.

Also, it is important to note that in your build script you would want to change the ios.dir and win8.dir to your Xcode and Visual Studio projects, respectively.

The final property we need to set up is Impact’s directory itself:

<!-- Path to Impact directory -->
<property name="impact.dir" value="${basedir}/impact"/>

Now that we have our properties set up, we can start building out our targets. Let’s start with our cleanup and post build cleanup targets:

<!-- Delete deploy directory and create a new one -->
<target name="pre-build-cleanup">
<delete dir="${deploy.dir}"/>
<mkdir dir="${deploy.dir}"/>
</target>

Here you can see that we delete the entire deploy directory and then create a new one from scratch. Here is the post build target:

<!-- Removes the minified game from the impact directory-->
<target name="post-build-cleanup">
<delete file="${impact.dir}/game.min.js"/>
</target>
<pre>
 
<p>All we do here is remove the baked game files from our main code directory. The last thing we need to do before creating our first build target is to make a wrapper target to call the bake.php script:</p>
 
<pre lang="xml">
<!-- Run the bake script - you need PHP to be runnable from the command line. -->
<target name="bake">
<exec dir="${impact.dir}" executable="php">
<arg value="${impact.dir}/tools/bake.php"/>
<arg value="lib/impact/impact.js"/>
<arg value="lib/game/main.js"/>
<arg value="game.min.js"/>
</exec>
</target>

As you can see, we are taking advantage of Ant’s exec method, which allows us to call a script from the command line. In this case, we are letting Ant know it will execute the script with PHP. The arg nodes supply additional information to PHP so it knows what to do, such as the script to run, the directories where our code lives and the final output file name.

We now have enough of a foundation in place to create our first build target for the Web:

<target name="web-build">
    <!-- Copy over the impact directory to the deploy folder and ignore what is not needed. -->
    <sync todir="${web.dir}">
        <fileset dir="${impact.dir}">
            <exclude name="weltmeister.html"/>
            <exclude name="**/tools/*"/>
            <exclude name="**/lib/**"/>
        </fileset>
    </sync>
 
    <!-- replace js source paths in HTML with minified game js. Make sure code is surrounded by "source script" comments so the regex can find it. -->
    <replaceregexp file="${web.dir}/index.html"
                   match="\&lt;!--source scripts--\&gt;(.*?)\&lt;!--end source scripts--\&gt;"
                   replace="\&lt;script src='game.min.js'\&gt;\&lt;/script\&gt;" flags="gs">
    </replaceregexp>
    <!-- This will copy over debug CSS if game is running in debug mode. -->
 
    <copy file="${impact.dir}/lib/impact/debug/debug.css"
          tofile="${web.dir}/lib/impact/debug/debug.css"/>
</target>

I’ve commented on this before but wanted to call out a few things that are important. First, let’s just walk through what is going on here. We need to copy over all the files, so we use Ant’s sync todir call and pass it a fileset. Filesets are a way to organize copying over multiple files and exclude ones you don’t need. In our case, we don’t want to copy over the level editor HTML page and the tools or lib dir. Once the files are copied over, we will replace the two JS imports to point to the baked JS game code file. I am using a regex call here, and in my Impact project’s index file I had to set up a special comment block around my two JS imports so Ant could find and replace them. Here is what that looks like in my game’s index.html:

<!--source scripts-->
<script type="text/javascript" src="lib/impact/impact.js"></script>
<script type="text/javascript" src="lib/game/main.js"></script>
<!--end source scripts-->

This is a great trick if you have any other parts of a document you may want to modify via Ant but don’t want to set up complex regex searches. Simply wrap the code that needs to be modified with a comment block and search for that.

The last thing we do is copy over the debug.css file. This allows you to still publish a debug build of your game and see the debugger. Without this call, if you forgot to remove Impact’s debugger, it would appear messed up. In situations when you don’t have debug enabled, the CSS isn’t loaded.

Now that we have seen how to set up our Web build, let’s take a look at the Chrome Web Store build, which is similar but adds in creating a manifest file along with zipping up the entire project for distribution:

<target name="chrome-build">
    <!-- Create chrome market app -->
    <sync todir="${chrome.dir}/tmp">
        <fileset dir="${web.dir}">
 
        </fileset>
    </sync>
 
    <echo file="${chrome.dir}/tmp/manifest.json" append="false">
        {
        "name": "${project.name}",
        "description": "${project.description}",
        "version": "${project.version}",
        "icons": {
        "16": "images/icons/icon-16x16.png",
        "48": "images/icons/icon-48x48.png",
        "128": "images/icons/icon-128x128.png"
        },
        "app": {"launch": {
        "local_path": "index.html"
        }},
        "homepage_url": "${project.url}"
        }
    </echo>
 
    <zip destfile="${chrome.dir}/${project.name}-${project.version}.zip" basedir="${chrome.dir}"/>
    <delete dir="${chrome.dir}/tmp/"/>
</target>

This build has a dependency on our Web target, but we will set that up later in our main build target. For now this target assumes the Web build exists and copies its contents to its own tmp directory called ${chrome.dir}/tmp. Once it is copied over, we create our manifest.json file via the echo file command. The append attribute flags the action to override the file if it already exists.

It’s important to note that we can still use build properties inside of the echo call so we can populate our manifest .json file with the project properties we set up earlier. Finally, once everything is in place, we zip the tmp directory, using project.name and project.version to name the file then delete the tmp directory. After this you can simply upload your game to the Chrome Web Store.

The rest of the build process is straightforward. I am not going to cover the other targets, but I do want to show you how I tie this all together with the full build target:

<target name="full-build">
    <!-- Clean -->
    <antcall target="pre-build-cleanup"/>
    <antcall target="bake"/>
    <antcall target="web-build"/>
    <antcall target="ios-build"/>
    <antcall target="win8-build"/>
    <antcall target="chrome-build"/>
    <antcall target="mozilla-build"/>
    <antcall target="post-build-cleanup"/>
</target>

As you can see, I simply call all the targets in the correct order. There are lots of ways to set up something like this, especially if you just want to call a specific target without calling everything else, and I encourage you to look into the dependency attribute in Ant if you want to streamline this.

As for the rest of the targets, you can view the full build script here.

Finally, once you have the Ant build file created, simply place it in the root of your Impact project, open up the command line, cd into that directory and type out Ant. The default target will get called and you should see that all your deploys get created.

Wrapping Up

This is just the tip of the iceberg of what you can do by automating your build scripts. Like I mentioned at the beginning, this technique is useful for any kind of builds you may be doing. I have used this technique with Flash applications/games and even Android. Before I end this post, I thought I would give you some pointers on what the next steps would be from here:

• Cut down on target repetition – As you can see in my script (unless I have updated by the time you read this), I have the Chrome and Firefox manifest.json files being created in their own targets. It may make sense to just break that part out into its own target so I can call it whenever I need a manifest file.
• Extract the properties – In more elaborate Ant build scripts, have their properties in a separate file called build.properties and have their build script import them by adding

  <property file="build.properties" />

  This allows you to have different property files on multi-team projects since the build script is checked in by each developer and you don’t want any custom settings to be overridden.

• Break out each task into its own micro build XML – You can then import each file by adding them to your main build like so

  <import file="${includes.loc}/custom-build.xml" />

  This is a great technique to share custom build files across multiple projects yet have a fully customized main build script tailored to the project.

There are a lot of resources out there about setting up and maintaining Ant builds. There should be enough in here to help you build a solid foundation on how to create your own build scripts for your next project.

Room112 is a simple way to keep track of your hotel room number. Enter your hotel room number into the app and the next time you open it the number is displayed for you along with the time you checked in, the floor your room is on and a map of the hotel’s location. TripIt doesn’t really track the last two bits of information. This app is just like the card a hotel would give you with your room number on it.

Goals

I collaborated with Wesley Crozier (who did all the artwork) on Room112 with the goal of creating a simple PhoneGap app that looks and feels as close to native as possible. I travel a lot and always forget my hotel address, room number and floor. I set the following goals when creating this application:

• Create a simple one-screen app
• Test our local storage
• Make the app feel like a native iOS app
• Have most design done via CSS3
• Test out animation on mobile Web browsers
• Take advantage of some simple jQuery
• Understand how to set up and publish a PhoneGap app in Xcode
• Display a Google Maps image via built-in GPS support

The full source code for this project is availbile on github here.

Architecture

Room112 is very simple. When you launch the app it checks for saved room data. If no data exists you are taken to the check-in screen. If data does exist then the check-in card is displayed with the saved data. I also planned on being able to review past check-in data, but this feature didn’t make it into the initial release.

Over the next few pages, we will discuss each of the application's screens based on the designs with functional notes on the logic.

Loading Screen/Background

This represents the loading screen of the application, which is the same as the background image.

Loading Screen

When the application is fully loaded, a small pocket is faded in to allow for easier masking of the check-in card animation.

Pocket Image

Background Plus Pocket

Once the application is fully loaded, the two layers (background and pocket) work very well to mask off the card animations and offer up a little more depth to the design.

Before Check-In

This is the screen you see after launching the app when no hotel information is saved. Simply enter a room number to activate the Check In button and save your data.

Before Check-in

During this process, the user is not able to actually check in until the room is entered. All other data is optional to make adding room data as fast as possible. Once a room number is added, the Check In button is highlighted and the user can save their data.

Check In

When you have entered your hotel information you are ready to check in. The Check In button becomes active, allowing the data to be saved.

Checked In

One thing to note is that the date is automatically filled in before checking in. Again, the goal is to simplify the check-in process by not forcing the user to have to add information we can assume is going to be contextual to the check-in process. Also, the user can add their room number as well as a map to the hotel’s location by pressing on the top part of the card at any time.

Once the user checks in, the card slides down into the pocket and the Check In button is changed to a Check Out button indicating that the data is set. At this point, if the user exits the app and comes back, their data will be saved and re-displayed until they check out.

Check Out

After you have checked in, you can edit your data at any time or check out. Checking out clears the card data and a new empty card is shown allowing the user to start the process over.

Check Out

Once the user hits the Check Out button, they are asked if they are sure they want to proceed.

If the user gives the OK to check out, the card slides out of the pocket and off the top of the screen and is reset before a new card slides back down into view.

Error Screen

There is only one error state for the app, which is displayed when the app is unable to locate the GPS position of the check-in.

Map Error Screen

Error handling and messaging is done by swapping out images. The initial state of the application is to display the Add Your Location image. If there is a failure, the Could Not Locate Your Position image is displayed. If the location can be used, an image of the map from Google is loaded in on top of the display area.

Error Screen Details

Code Review

Due to the nature of this application, the codebase was architected to be as small and portable as possible. I did not break out the JS logic into classes and relied heavily on frameworks to help speed up my development. Let’s take a look at what is going on under the hood.

Application Structure

For the most part the application is very flat. There is a standard www directory, which houses all the Web content loaded by PhoneGap. In that directory are my css, images, js and index.html files.

In addition to the www folder, PhoneGap automatically adds all the needed libraries to run on iOS when you create a new PhoneGap template from Xcode.

It’s important to note that once you create a PhoneGap project you will need to manually link the www directory into the project. Here is how the project looks in the finder:

Notice the www sites outside of the Xcode Room112 project and how I tend to include my own design directory in the root to keep my source designs organized, especially when I check in a project.

Let’s take a quick look at each of the directories in the www folder.

• css - There are two css files, one for the base of the project and the other that has overrides for retina resolution graphics. I’ll talk more about this in the next section.
• images - This contains all the images the Web side of the PhoneGap application requires to display.
• js - This contains all my JavaScript libraries. I am using the following libraries for this project:
  • jquery-1.7.1.min.js - to handle animation, changing data on the page, etc.
  • jquery.animate-enhanced.min.js - allows jQuery animations to use CSS3 transitions where supported to help improve performance on mobile
  • lawnchair-0.6.1.min.js - handles local storage
  • phonegap-1.3.0.js - PhoneGap’s APIs and native to JS bridge
  • room112.js - application logic

Room112 Core Code

I designed the application to be a simple state machine. It handles three states: not checked in, checked in and checking out. From there I was able to manage the state changes and update the display accordingly. Here is a high-level overview of the app’s functions and what they do:

• onDeviceReady - This is the main init function of the application. It handles setting up the initial visuals of the application along with requested saved room information from local storage via Lawnchair. Once everything is set up, the room card is animated in and the app is ready to be used.
• loadGPS - This handles making the request to the browser’s built-in GPS API:




navigator.geolocation.getCurrentPosition(showMap, showMapError);

I decided to use the built-in browser’s GPS instead of the API provided by PhoneGap to help minimize any dependencies on their library. The call to navigator.geolocation accepts two callbacks, one for success and the other for failure. When the request is made, a pop-up is shown automatically to allow the user to accept permission to use the built-in GPS.



• showMap- This is called when the GPS is able to find the user’s location. It simply makes a request to Google Maps for an image and displays it at the top of the check-in card. The URL for the map is saved locally so the service doesn’t have to be called when the app re-loads and the user is checked in.




cacheMapURL = "http://maps.google.com/maps/api/staticmap?center=" + coords.latitude + "," + coords.longitude + "&zoom=13&size="+width+"x"+height+"&maptype=roadmap&key=MyGoogleMapsAPIKey&sensor=true";

The method accepts a position argument that can be used to determine the coordinates the Google Maps API needs to generate the image. I also provide the image size manually so I can support standard resolution and retna.



• showMapError - This is called if the GPS is unable to return a valid position to the application. I simply show the error image allowing users to try again later.






• addInputListeners - This handles adding listeners for the buttons and other UI elements such as each input field. This allows me to listen for when an input field loses focus so I can call invalidate() in order to see what data has changed.
• invalidate - This method compares the data in the form to what has been saved. This allows the application to automatically save any changes made while checked in and also test if the user has entered enough information in order to check in.
• updateDisplay - This manages updating the action button based on the state of the application.





Before Check-in State


Able to Check In


Check Out

• getHotelData - This is a simple utility method for accessing saved hotel data from Lawnchair.
• formAction - This is called after invalidate() and simply switches between the application’s mode methods: checkIn(), checkOut() and saveRoomData().
• checkIn - This is the default state of the application when no saved data is found upon launch.
• checkOut - This animates the card off the screen, calls resetCard() to clear the data and resets the application’s mode method back to checkIn().
• saveRoomData - This is called when the user is checked in and they change any values in the form.
• resetCard - This clears the data on the check-in card while it is off-screen. This is called after the card is animated off the screen.

Design/Retina Display Support

The application was designed with iPhone 4S Retina display support in mind. In order to do this you must provide two resolution images and a secondary CSS sheet to override the base image paths. This is relatively easy to set up.

<link rel="stylesheet" type="text/css" href="css/normal.css">
<link rel="stylesheet" type="text/css" href="css/retina.css" media="only screen and (-webkit-min-device-pixel-ratio: 2)">


As you can see, the initial CSS sheet is loaded and then we use a media query, which is supported on WebKit on iOS to detect if the pixel ratio is 2x larger. Here is an example of a low res image:

#pocket
{
background: url('../images/pocket.png') no-repeat;
background-size: 320px 80px;
width: 320px;
height: 80px;
position: absolute;
bottom: 0px;
}

and the retina override:

#pocket
{
background-image: url('../images/pocket@2x.png');
}


It’s important to note that in the base style we need to define the background size so that when the retina image loads it’s not rendered at its native resolution. Here are the two images:

pocket.png 320 x 80px

pocket@2x.png 640 x 160px

All the images in the application have retina size graphics to support the higher resolution, and the difference visually on the device is noticeable. On a website, this approach would be problematic since we are loading both sets of images and would probably want to use a better solution so the application is only loading the right image to cut down on bandwidth. I didn’t take this into account since it was a locally running app, but if the app is image intensive this could end up being a performance issue.

Finally, there is some mobile WebKit-specific CSS code you should add to your style sheets as well to help make your app look and feel more native.

<!--
* {
-webkit-touch-callout: none;
-webkit-tap-highlight-color: rgba(0, 0, 0, 0);
-webkit-text-size-adjust: none;
-webkit-user-select: none;
}
-->


This allows you to hide the fact that your app is running in WebKit and remove highlight colors on taps and user selection on form elements. Also, adding the following metadata block will disable scaling and zooming, which is built into the WebView by default:

<meta name="viewport" content="width=device-width; initial-scale=1.0; user-scalable=0;">

This extra line of CSS and meta tag will make your app run at native resolution and is important to have in your project’s HTML code.

Animation

I chose to go with jQuery for the animation and ran into performance issues, which I will discuss later on. My reasoning for this was to make sure the app wasn’t dependant on CSS3-specific animations that may not be supported on other platforms. To me this was a big concern even though I focused on an iOS app only, so if you have a clear understanding of where you application will be deployed to you may just want to go with CSS3 animations from the beginning.

jQuery did allow me some additional control with call backs and delays, which I still don’t find to be well supported with CSS3 animation right now, especially when you need to execute JS during a key point in the animation sequence.

Local Storage

I chose to go with a local storage wrapper framework called Lawnchair. Using local storage directly is relatively easy, but I had read good things about it and liked its implementation. It is very straightforward to set up a pointer to local storage by doing the following:

hotelData = new Lawnchair({name:'hoteldata'}, function (e) {console.log('Storage Open', this); });

Then, at any point when I need to save data, I simply reference the Lawnchair instance and save my data out.

var formData = {
room:$("#room").val(),
floor:$("#floor").val(),
date:$("#date").val(),
map: cacheMapURL
}
hotelData.save({key:"room", value:formData});

I save out my application’s state to a simple JSON object, which makes loading and parsing the data very easy.

Development Workflow

Browser Prototyping

I experimented with several workflows, the first of which was doing all my development locally and testing it out in Safari on the Mac. This allowed me to quickly prototype the application using the tools I was most comfortable with along with WebKit’s built-in debugger. One of the biggest issues I ran into while testing was being able to simply debug my CSS and JS, which is incredibly difficult to do when running the PhoneGap application on the iPhone simulator.

Development in Xcode

Once I was happy with the application and the way it ran in Safari, I moved the project over to Xcode. Development tended to slow down considerably for me since debugging issues and JS integration were difficult without better debug tools. The big downside to testing in Xcode is the compile time. While it isn’t too bad, it does take a few seconds to go back and forth between the two environments.

I did find Xcode to have good JS support and was even able to continue to use Xcode to write and fix my JS logic without much issue.

Deployment

Once you have everything set up in a PhoneGap project, your application runs just like any other iOS application. Technically, this is a native app, so you get to take advantage of Xcode’s built-in support for setting up provisioning.

Issues

I ran into several issues that in the end made it hard for me to make Room112 feel like a native app. I have outlined a few of the issues below to help you address them in your own app as well as things to keep in mind when planning out your own development.

Animation Performance

I ran into lots of issues trying to get native-looking animation using PhoneGap. At first my issue was the performance penalty of using jQuery for animation. Doing direct DOM-based animation is incredibly slow. There are lots of hacks you can do in order to force hardware-accelerated CSS3 animation on iOS, and it wasn’t until I started using jquery.animate-enhanced that I began seeing better performance. Also, at some point everything slowed down on later builds and I was unable to debug.

My suggestion for iOS is to simply use CSS3 transitions from the beginning and make sure you take advantage of the -webkit-transform: translate3d(0,0,0); hack, which is said to force all other CSS3 translations to be hardware-accelerated. This could also be problematic if you are trying to directly port over an existing mobile site to PhoneGap, which may not have support on other platforms for CSS3 transitions. I will probably continue to experiment with this to find the best solution with good fallback support to allow the code to be as portable as possible.

PhoneGap Issues

I was running into a lot of issues trying to disable the native scrolling of the Web page via JS. The only way I was able to fully disable it was to add the following Objective-C code to disable scrolling and bouncing directly in the PhoneGap WebView instance:

UIScrollView* scroll;
for(UIView* theWebSubView in self.webView.subviews){
if([theWebSubView isKindOfClass:[UIScrollView class] ]){
scroll = (UIScrollView*) theWebSubView;
scroll.scrollEnabled = false;
scroll.bounces = false;
}
}

I ended up having to add this to the AppDelegate.m class, which is auto-generated by PhoneGap because the JS code to ignore scroll events didn’t block the user from scrolling from inside a text field. This is a good example of how you may need to augment your PhoneGap app with native code when JS hacks simply don’t work.

I was also running into issues trying to access the Google Maps APIs and had to whitelist the URL in PhoneGap’s .plist file, which is located in the native project.

Project -> Support Files -> PhoneGap.plist

Once you have PhoneGap.plist open, simply go to the ExternalHosts property and add any URLs your application will need access to.

After that you shouldn’t have any issues.

Alerts and Messages

I ran into several strange issues with displaying alerts in my app. At first I was trying to avoid using the native PhoneGap hooks so I could continue to test my app in Safari on my computer, but when you call JS’s default alert you’ll see the parent page the alert is being called into.

I wasn’t really expecting this, and it certainly takes away from the native feel of the app. I tried to switch over to PhoneGap’s built-in native alert message bridge but had problems getting it to run. I was using an older version of PhoneGap, so hopefully updating it will fix the issue. Other people on the forums had similar issues with it as well.

Graphics Issues

I didn’t run into many issues, but the few that I did see are slightly annoying. The biggest issue I noticed is after the application loads there is a split second flash of white, which happens when the WebView loads right after the loading image is removed and the index.html page’s background hasn’t fully loaded. I believe there are ways to keep the loader image up longer to smoothe out the transition, but that would have to be done in Obj-C and there isn’t much you can do about it. This just means you need to pay special attention to the loading of your main page, especially if it is graphically intensive or requires a lot of JS to initialize.

The only other issue I want to highlight was the difficulty I ran into with getting fonts to match up exactly with my Photoshop designs. At first I tried to do the entire design via CSS3 and use fonts where possible. I was unable to get the layout to match my PSD to my satisfaction and ended up using rasterized images instead for most of the UI. While this app would be relatively easy to localize, since I could swap out different images via CSS based on the default language of the phone, in a production application this would not be ideal. While CSS3 and browser fonts have come a long way, there is still a gap between what can be done in the browser versus Photoshop, so that limitation should be in the back of your mind when trying to figure out how to set up the visuals of your PhoneGap app.

Development Bottlenecks

While I only focused on doing an iOS application, I have heard of issues building for Android. In addition, it became next to impossible to maintain a Web-only version of the app. So, while it would be ideal to be able to deploy the same code base to a mobile website and have the PhoneGap wrapper app for people who want to use native, you will end up having to modify each build for each platform.

You could write a wrapper to emulate or disable the PhoneGap-specific JS logic so that your application would degrade better on the Web, but the level of work required to architect a single app that could run on the Web and in PhoneGap on all its supported platforms would be a huge undertaking. It’s not impossible but I just don’t think that it ends up being worth the level of effort. In that case you are better off defining blocks of code that are portable and spending the last 10-20% of your development customizing the code base to each platform.

Moving Forward

While this was a fun little exercise to help me get up and running in PhoneGap and vet out Web-based app building, I still have a lot to do and learn.

Deploying to Multiple OSs

The next steps are going to be getting this app to run on different OSs such as Android and Windows Phone 7. The biggest reservation I have with porting the app to other platforms is that each one has its own UI and navigation paradigm. While Room112 was designed according to what most iOS apps are starting to look like, using real-world textures to look photo realistic, this may look out of place on Android and Windows Phone 7. Luckily, I could easily swap out the CSS and images and quickly reskin the app; it’s just extra work and platform-specific customization I don’t want to do. This is just another problem with the dream of having a single app that runs and uses the same code base across multiple platforms.

iPad/Tablet Support

I would also like to eventually support the iPad, tablets and other higher-resolution devices but would have to rethink my design approach. Right now the app doesn’t warrant a larger-resolution design, but I would like to test out how to handle scaling up in a PhoneGap app. I may just try this on another project. Again, I hope it would be a few quick CSS changes, but most phone apps need to be rethought out for tablets so it would be interesting to see how much of the application logic I could keep and what the performance would be on larger screen devices.

Conclusion

While this wasn’t the most awe inspiring application I have ever built, it did give me a great opportunity to learn more about PhoneGap as well as how to style for iOS mobile browsers. All in all, while PhoneGap is easy to use and being able to leverage a Web Stack for development is a great advantage, it’s also incredibly difficult to get a native feel and responsiveness most users would be expecting on iOS.

I think if you approach your PhoneGap app understanding the limitations and pain points, you can actually produce something really polished and portable across multiple platforms. I wouldn’t rule this out because over time, as devices get faster and support more HTML5 features, this may turn out to be a viable development solution.

Perhaps the most jarring part of the entire experience is the way that legacy Windows apps are contained inside of what would seem like a single Metro app, which you access via the desktop tile. So if you have Metro apps open and legacy Windows apps open, it becomes difficult to move between them quickly. There is a new dock that previews open apps on the left of the screen that sort of helps, but I found pulling it up difficult. I think over time these issues will be worked out but, in the end, having desktop support is simply a stopgap until more developers create Metro apps and the desktop eventually goes away. At least that is my take on it. I actually don’t have any idea what Microsoft’s goal is with Win 8 and future builds.

HTML5
Microsoft is betting on HTML5 in a big way. You can build three types of Metro apps: C++, C# and JS/HTML. I honestly couldn’t tell the difference in terms of performance from JS/HTML apps and C# ones. I got to meet with the head of the compositor team who is in charge of rasterizing HTML and rendering it via the GPU. Internet Explorer 10 has full hardware acceleration, and this also translates into HTML Metro apps. For this reason, HTML5 apps are first-class citizens on the OS, and I would tell anyone who is interested in making apps for the platform to build them with JS/HTML and not bother with C++ or C#. I love C#, but what is the point if you can take advantage of HTML and JS, which are more portable? You can even write wrappers for C++ and access them via JS through WinJS (the Win 8 JS layer that runs HTML Metro apps).

WinJS
While I was impressed with building Metro apps, I was not very happy that in order to get the best experience from your JavaScript app you need to build on top of their WinJS and IE10-specific HTML tags. MS keeps talking about how they are fully supporting Web standards, but every code example I’ve seen from animation to touch events requires -ms prefix selectors, which force you to use their version of the standard. Even worse is that WinJS only works on Windows, so you are locked into their platform. While I was able to get one of my HTML5 games up and running as a Metro app in less than 10 minutes, I needed to go through and rewrite parts of the underlying JS to run better on their platform. I feel like MS missed a huge opportunity to build a new rich Web UI framework that could have replaced Silverlight/Flex but chose instead to force developers to build apps for their OS and not the Web.

Potential
I see a lot of potential in building Win 8 HTML Metro apps since my primary type of development is Web-based. Especially now as companies transition out of Flex and go deeper into writing HTML5 Web/mobile apps, all the skills, people and development practices required to build these new apps will help position them well for this kind of work in Win 8. This is good because most companies won’t have to hire specialized developers to build Metro apps. I am confident that building HTML5 Metro apps will be straightforward and that any competent JS developer would be able to optimize the app to run on WinJS if this is a port for existing Web sites/apps. The way I see JS/HTML Metro apps is like PhoneGap on steroids. So, theoretically, clients who are already heavily investing in HTML5 could quickly port their Web apps over to the Win 8 platform and use Metro’s components/controls to modify the views to fit within the Metro style.

Long Term
Microsoft is betting on the fact that its Windows 7 user base is going to upgrade to this new OS. Even if they do, there is a huge disconnect between running Win 8 on a touch screen versus a desktop. That being said, people do buy new computers, so there will be a faster adoption rate than with their phones (which had most people locked into two-year contracts when they came out). If MS can get people to buy these new Win 8 devices, and the ARM-based tablets have enough power to be usable, then this will become a viable platform. The biggest hurdle in my mind is going to be finding the right price point. Basically, Win 8 tablets need to sit in the $200-$500 range, and there is no clear indicator if that will be possible. Also, MS is not very upfront about what classic mode apps will be supported on ARM. I am not convinced that it’s going to be as easy as recompiling an existing Win 32 app and it will work. ARM devices may have to rely heavily on Metro apps getting out of the gate until older software is updated and optimized for ARM, or those vendors simply decide to move over to Metro (which is probably the smartest move at this point).

Hardware
The other thing working against Microsoft is hardware. Apple excels in the phone, tablet and computer space since they control “the entire widgets” and limit the choices consumers have to deal with. Microsoft is at the mercy of their hardware partners to come up with innovative devices to show off the OS. I don’t think consumers are going to find it easy to pick the right Win 8 device. Do they want a laptop, a desktop or a tablet? If they get a desktop should they get a touch screen? What is the performance difference between ARM and Intel/AMD? I guess Windows users are used to this, but I think that radically changing the entire OS to be touch first focused while the majority of the existing hardware out there isn’t that way is problematic. The hardware is going to need to be up to the task to deliver the best experience possible. I also don’t think I need to elaborate on the fact that Apple is just moving so quickly now in the hardware space, just check out the new iPad, and most companies will have difficulty catching up. The new iPad already highlights the lower resolutions these unreleased Win 8 devices will have. It will be interesting to see how quickly Microsoft can adapt.

Conclusion
I spent some time going through Windows Phone 7 and doing development on it when it was announced. I loved the platform, the tools, the language and even the submission processes, but none of that helped make people buy the phones. It wasn’t until Nokia got involved that sales started picking up because they make really good hardware. I think Win 8 is going to live or die by its hardware. Granted, phones are a totally different beast, especially since most people get locked into a contract for two years. With Win 8, most people have Windows and can buy a new computer as needed, so the barrier or entry is much lower.

For developers who are currently doing HTML5 development, such as apps or games, it’s a no-brainer to make a Metro app. I do agree with the Microsoft evangelists when they say to simply sell your app to 1% of the existing Windows market and you will make a lot of money. I plan on releasing any app I would put on the Web or in the Chrome Market on Win 8, and I suggest that at the very least you do the same. Download the consumer preview and the tools and give it a try; I think you will be very impressed by how well HTML5 is integrated into the OS.

Next up is the fact that Adobe’s story with Flash has always been a VM that works exactly the same on any platform. The only problem with this story is that they never achieved it, even on desktops. For years Flash player was noticeably slower on Macs then PC. Adobe hardly supported Linux and the player was so buggy it was clear Adobe couldn’t care less about it. When Adobe started pushing Flash to run on Mobile, Apple locked them out and thanks to the fragmentation of Android Flash just could not deliver. By the time Adobe finally figured out how to get Flash to run decently on iOS via AIR they had lost performance on Android. The two mobile platforms were never in sync, nor would Adobe ever be able to keep them on par performance wise since they lack the resources to support hundreds of different mobile devices. When you have to spend more time optimizing your AIR app for one platform over the other, especially when your desktop/web code would run fine but fail on mobile (for good reason given the limited resources these devices have) it becomes a logistical nightmare to support fractured code bases of the same application.

Let’s not forget that Adobe was always far behind the native language and it took constant updates to the runtime just to support the most basic features of each devices. To accommodate this Adobe started supporting something called Native Extension where you mix native code in with your AIR project to roll your own solution for features Adobe didn’t support. For me this was the deathblow and clearly showing that AIR was a total failure. Why would I write native code that is not portable across each mobile OS and still try to maintain a horribly performing Flash application? There is no cost savings and as a develop you are now responsible for “patching” the runtime so if you don’t know the native languages you are basically screwed. It’s not like Adobe released a community site to share native extensions easily among developers so everyone is just forced to reinvent the wheel on their own projects. Native Extension is just another half-baked solution and one more nail in the runtime’s coffin.

On top of this Flex just wasn’t up to the task of being a mobile UI. Originally Adobe announced that they were going to create a new mobile friendly version of the Flex framework. They never delivered, instead they decided to try and patch the existing framework and optimize it for mobile. That may have worked except Adobe still hadn’t even finished porting over most of Flex’s components from 3.0 to 4.0. On top of that Flex is a total dog, even on a powerful desktop. You would think a company who had been trying to get Flash to run on mobile devices since Flash Player 6 on Pocket PCs would have been forward thinking enough to actually build Flex in a way that would eventually work on Mobile but they didn’t. It’s no surprise Adobe announced the end of Flex’s development yesterday. They just can’t support it. Between the fragmentation of Flash across mobile devices, and the legacy code they never addressed deep in the core of the framework Flex was dead way before most people even wanted to accept it.

What makes the end of Flex incredibly scary is how dependent most enterprises are on it. Adobe has nothing else to offer as a transition away from the framework. They are only now shifting focus to HTML 5, which is still years away from being on par with most of what Flex could deliver. Make no mistake about it, companies like banks, financial institutions all the way up to the government are now dependent on Flex. While Flex and Flash will limp on for some time there is absolutely no reason why they should or would invest more money in moving these products forward. Most companies will have to go into maintenance mode on these apps and start moving over to HTML 5. This will be incredibly expensive and time consuming especially in a period when most companies are struggling to stay in business due to the weak economy.

With nothing really ready to replace Flex companies have a tough choice to make and this will no doubt create bitterness and resentment towards Adobe over screwing them over. Smaller Flash agencies that haven’t hired resources for HTML 5 yet are going to have a hard time finding new clients who will be confident making Flash sites. Sure banners and micro sites will exist for years to come but if these clients haven’t given up on Flash yet over iOS, then someone needs to sit down with them and fill them in on the reality that Flash is not making a comeback. This resentment will tarnish Adobe’s name even more then Apple has and honestly at this point who would really trust Adobe to make development tools for HTML 5 or a new platform?

Flash Builder, formerly Flex Builder is horrible. It’s one of the worst pieces of software I own. It’s a shame when you are a tool company that can’t build tools for your own platform. For years other companies have been able to build much better IDEs for Flash such as FDT, IntelliJ and even Flash Develop, which is totally free. Adobe knows nothing about developer tools and it’s clear in Flash Builder, Flash Pro and Catalyst the poster child for complete and utter Adobe tool failure. I mean what do you expect? Its not like we have been telling Adobe what we need in the enterprise space for years… oh wait we have been but they continue not to listen to its own community. Ironically when I saw the tweets that Adobe had announced they are exiting the enterprise space I was shocked because I never considered them actively participating in it.

Let’s talk about community, or what is left of it? The biggest blow to Flash from the layoffs is the dismantling of the community teams. The one thing that used to keep me interested in Flash was its community but with the restructuring most of the people who I respected are gone so who is going to help message that things will be ok? I am watching all of Flash’s evangelists trying to keep people calm and maybe it’s just me but if you can’t see through their bullshit then you probably think Adobe is going to continue to really contribute to Flex when they open source. Now with Adobe’s Flash community gone, and no new community initiative to harness disgruntled Flash developers who have moved on what incentive do I have to keep my opinion to myself? Why would you even want to be involved with a company who’s Product Manager goes around calling other developers who try new technology douche bags? I guess I get the last laugh because this douche bag knew better and spent the last 3 years learning languages/platforms that will survive long after Flash is dead.

It’s about time Adobe showed its true colors. Adobe is just a company, they are not your friends, they don’t care about you, shit they don’t even care about their own employees. Nothing like gloating that Adobe will reach their 4th quarter financial goals after laying off 10% of their company. I feel bad for the people who were not laid off, if you think your job is secure guess again. As Adobe quickly starts shutting down more and more resources around AIR and Flash there will be more layoffs. The best part is that no one questions the leadership of their CEO because he is “trimming the fat”. Flash represents 4% of their revenue, why would they spend so much time, energy and resources on it when everyone hates it now? Finally they woke up and realized that Photoshop on a tablet is going to make more money for them then selling overpriced licenses of Flash Builder ever will.

The final deathblow to Flash is this new initiative to turn Flash into a gaming platform. I guess Adobe missed the memo but Flash was already a gaming platform despite their best efforts to not improve it over the years like everyone was begging them to do. All of the things we had been asking for such as a more robust language, multi-threading, GPU acceleration and better performance would have actually made Flash a gaming platform organically. Now Adobe has to shoe horn all of that crap in or just move over to a new VM. That would be fine except the advantage of Flash was that it is installed on basically every computer. A new VM means a new download and honestly no one is going to do it. The Metro version of IE on Windows 8 isn’t even going to support plugins. Unity is way better at delivering games and their penetration numbers are incredibly low.

Adobe is going to have a hard time selling Flash to game companies. Not after this PR nightmare, I mean what company in their right mind would trust Adobe or Flash? Adobe knows nothing about gaming, Flash gave birth to the casual gaming market and they completely ignore it while they were on the quest to build a better video player. Now that plugins are dead the last thing we need is a new game centric plugin. That is what my mobile phone is for and my tablet; casual games. When I want real games I turn on my Xbox or PS3. Mobile gaming is where the money is at now and Adobe still can’t get Stage 3d to run on mobile. They don’t even have tools to support a 3d workflow. Remember Adobe is a tools company, if they don’t have tools to sell they don’t make money from the platform unless they license it out and who would honestly pay for that? I am sure RIM is happy with that arrangement.

I could probably go on for days criticizing Adobe and what has happened over the past week. In the end it doesn’t matter because Flash is such a small part of my development now. I moved on long ago because Adobe just doesn’t understand developers. They never did and they actually killed a good thing. While they were too busy criticizing my loyalty they totally proved me right. You can only get away with abusing your community until they finally turn. Now with all the negative PR, the end of development of Flex and the general public’s negative image of Flash Adobe should have just declared it dead and made this easy. Don’t be fooled, it will take a long time for Flash to finally die. When it does I will not be there to morn its loss, I suggest you don’t be around for it either. Three years ago I started telling Flash developers to branch out, learn new languages and grow their skill set, I hope someone was listening.

I have started a google+ thread here to capture your comments and start a discussion around the Adobe announcements.

The Build conference has been an almost life changing event for me. I don’t say stuff like this lightly. I have been a Web developer for the last 13 some odd years doing mostly Flash development. I also know several other languages and have been doing lots of native mobile dev lately. If you know anything about the tech community, you probably have an idea of Flash’s downward spiral right now. Before I went to Build I was in a state of dev limbo. I had no idea what I would be doing next and no languages or platforms were really exciting me. This past year I did some wp7 development and fell in love with C# and the tools but the market for wp7 users is too small to be worth me dedicating much of my time to. Well, that all changed at Build. I can’t remember the last time I was this excited about a platform and it’s all thanks to Windows 8.

As an entrepreneurial developer, I look at the potential growth of any platform I dedicate my time towards learning and developing on. Picking up a new language is a long and arduous process. Sometime it’s incredibly fun but it has to be rewarding at the same time. I want to focus my time on a platform that is going to have the largest reach and opportunity for financial gain. The way I see it, Windows 8 is going to be one of the largest developer centric platforms available when it launches. It’s hard not to get excited about the prospect of reaching millions upon millions of consumers via one of the most successful computer platforms ever. Being able to reach every person who buys a PC from the lowest end sub $400 desktop to the highest end gaming rig along with the new generation of slate and ultra portable laptop computers with a single OS is about as good as it gets for me. Even with the success of the iPad I find it hard to believe that desktop and laptop computers are going to just go the way of the dodo bird over night. Perhaps Windows 8 is the opportunity hardware manufactures have been waiting for to compete in both spaces at the same time.

For me, the greatest advantage of doing Windows development right now is Microsoft’s “developer centric” approach to coding on their platform. What do I mean by developer centric? Take a look at the choice of languages you have at your disposal for building Metro Style apps. You can use C++ for the most processor intensive types of applications or games. There is C# for the Silverlight and WFP developers along with Visual Basic. These three languages share XAML for the display layer and come with a suite of components developers can take advantage of to help build consistent looking apps. For developers who can’t design, Metro is made for you. By simply using the built in components you get the default Metro look and feel in your app for free leaving more time for you to focus on what matters most, the code.

If those 3 languages aren’t your thing there is now HTML 5 which is treated like a native language in Windows 8. This opens up the flood gate to all the Web developers who are either transitioning out of Flash or have been JS/HTML developers this entire time. My big take away from all of this is that unlike Apple who forces you to use their language and tools, MS is actively trying to cater to the largest demographic of developers possible. With Win 8, I can pick the language that best fits my needs and skill level, I am not being forced into something I don’t want to do. The only downside is that their tools only run on Windows but since the apps you will be building run there as well it’s really par for the course.

When I originally bought my UMPC I desperately wanted to develop apps for it. Even back then I saw the potential of the slate form factor but the hardware and software just wasn’t there. Even if I could build an app for these devices how was I going to distribute it? The market for UMPCs was incredibly small and there was no way I would ever make a profit. With a unified App store on Win 8, and given the reach of the platform, those fears are long gone. Plus, as WP7 continues to grow market share, being able to deploy basically the same application to mobile devices in addition to desktop and tablet/slate is incredible.

I could probably drone on and on about how excited I am to start developing for Windows 8. At Build I didn’t go to any of the after parties and was coding in my hotel room each night. The fact that they gave out a slate with Win 8 installed on it definitely helped. Even if you don’t have one of these computers, anyone can download a preview of the OS and start coding for it. While iOS is still proving to be an incredibly lucrative platform for developers it would be crazy to miss out on an opportunity like this when Win 8 launches. “Windows 7 has sold more than 100 million copies in six months which made it Microsoft’s fastest selling operating system” according to wikipedia. So if a few million people buy Win 8 devices when they come out and I am able to sell at least 100,000 copies of my app for a $1 in the first few months I would make a healthy chunk of change. Plus it’s not just about buying new devices, all of the millions of existing Windows users can simply upgrade and instantly help grow the platform overnight. That is probably the single most important path to success with Win 8 is that no new hardware is required, it still works on most modern computers everyone may already have. All I need to do now is be ready for the launch with as many great apps and games as I can come up with. As much as I would hate to have the competition, I suggest you at least give it a try. C# is an amazing language, Visual Studio is an incredible tool and Windows 8 has the potential to be a huge success.

I have started a google+ thread here to capture your comments and start a discussion around the Windows 8 announcement.

What projects are you working on right now and what are you using to build them?

I have been all over the place at Roundarch lately. I recently finished up a huge Flash project then went right into a native Android app and even had to help out on a custom WordPress project for the front end of an enterprise app. Outside of coding I am involved in pitches and research. There is a lot of mobile on my plate as well as HTML 5. Flash/Flex is not so common for me but people keep telling me it is still being asked for. I do try to pitch AIR for mobile when I get the chance since right now it is still the only multi-platform game in town that I feel comfortable with. Outside of that I always say go native but have even dabbled with PhoneGap a bit as a backup plan.

For my development I use IntelliJ. It’s the only IDE that allows me to go from Flash to native Android and not give me any problems. I am not a big Eclipse fan and find that while there are lots of plugins out there for it, most of them are unstable or conflict with other plugins. IntilliJ doesn’t have any of those issues, it just works. When I am doing HTML 5, JavaScript or PHP I use PHPStorm which is a scaled down version of IntelliJ without all other stuff you don’t need for web dev.

You’ve worked on all types of projects, from enterprise-level applications to casual games. What area of development do you enjoy the most?

I really have a passion for making games. That is actually how I got into Flash but I quickly realized there was no money in it so I started doing agency/enterprise work. Now I focus 100% of my free time to making games for the web and mobile. I have a long ways to go before I will probably make a successful one but I need all the practice I can get. I am great at the technical part but I am still trying to find that magical formula for fun. Right now mobile is big, especially for casual games. It’s a good time to try and be part of the mobile indi/casual game market since trying to monetize web games was never that lucrative. Don’t get me wrong, devs can and have made livings off of Flash based web games but people are spending more time on their phones and tablets then their computer or TVs now a days.

As a creative developer, do you think it’s necessarily bad to move back to a more dynamic, less strict language like javascript?

At first I was really opposed to doing Java Script. After spending years understanding Classes, Design Patterns and building large scale web applications it felt like a total step back to the stone ages. Over the last two years I have worked very hard on being able to understand development and be language agnostic. It wasn’t until recently that I could look at a language and not try to compare it to ActionScript which is what I primarily worked with. Now that I have this perspective shift I see the strength and weaknesses of JS in a new light.

There are some aspects of the language that are truly freeing. Then I hit a wall because I still cling to the what I am comfortable with. In the end we all have to accept whatever the next language is with open arms. At least for now it looks like Java Script is what will take us in to the next cycle of web development while Flash slowly (or quickly depending on how you look at it) becomes even more specialized.

If you can keep an open mind while learning a new language you will pick it up a lot faster. It’s important to try and stay positive and challenge yourself with tasks you can accomplish. In the past I would bite off more then I could chew with a new language and flounder. With JS I am taking it nice and slow and at my own pace. Also having a solid IDE like PHPStorm or WebStorm which has code hinting is monumental in easing the burden of learning JS.

A lot of people are uptight these days when it comes to technology discussions. Why do you think people get so defensive about a specific technology?

I once had a teacher who said that when you do something more then 3 times it becomes a habit. Think about how much repetition there is in development. Programming is a very personal experience for people. In order to be good at a language you have to be close to it, speak it and understand it. Developers form a special bond with the platform they are working on and when something disrupts that balance they tend to lash out. I probably spend more time with my code then I do my wife, my kid, my family or my friends. That’s a lot of time to spend with something and you grow to love it.

Programming languages come and go, they all have their own life cycle. Not to get all spiritual on everyone but it does become like a religion to some people. It also doesn’t help that the companies that develop these products brain wash their user base into thinking their platform is the best one out there and sometimes go to great lengths to bring down the competition. It is all marketing at the end of the day, companies are selling developers a dream and it’s heard to stop drinking the kool-aid. I can clearly remember how hard Adobe’s stance was on Silverlight yet when Apple called them out for their own faults they cried foul.

There will always be those people who can’t move on or choose not to when a platform is nearing the end of its life cycle. There was a huge rift between Director and Flash developers until it was clear that Flash was going to be the winning platform. Adobe still supports Director to some extent so these things die slow and painful deaths. Sometimes it’s hard to see the end of a platform because as more people move away from it there is an over abundance of work since less and less developers are around to do it. Eventually that work becomes maintenance and who wants to be the last one at the party. I guarantee if you can find director work you will be highly paid, not because it’s “in” but because everyone is out.

In the end you need to look past the marketing and find the platform that is right for you. Some people pick languages that have no commercial value simply because they are fun. Others go where the money is. The worst thing we can do is be critical of other languages or developers who chose to explore new languages. This is exactly what is going on in the Flash community and it will be the thing that tears it apart. What is even worse is that Adobe is doing little to help ease the rift between those who feel abandoned and the ones who are still making a living with it.

Eventually when a company doesn’t see a return on investment for a platform it gets canned and everyone feels cheated. Even bringing this up and making people nervous about it sparks all kinds of emotions. Just look at how large of an ecosystem depends on a development platform and you can see there are a lot of things at stake when it is threatened. People lose their jobs, their entire living could be flushed down the toilet just because a company failed to maintain it’s hold on the market.

Do you still prefer WP7 as your main device OS and are you developing for it?

Yes, my main phone is still a WP7. In my opinion it is the best OS out there right now. I also loved developing on it. I have not done much Objective C but between Flash, JavaScript/HTML5 and Java for Android, C# was the best language to develop with. The tools are top notch, especially when you add ReSharper to Visual Studio and the Mobile platform is well architected. Unfortunately I have not had much time to build another WP7 app but I think about it whenever I start a new personal project. Microsoft has a huge hill to climb when it comes to getting the adoption rate up and this is not a battle they can just throw money at like they did with Silverlight. MS is really going to have to innovate the platform and that is exactly what they have been doing so far. WP7.5 looks amazing and they are really pulling away from the heard of mobile OSs.

Adobe Flash is still very widespread, but the tools and support are arguably lacking. C# and Visual Studio are obviously amazing, but its products lag behind. What can either of these companies do to help perfect that cycle?

One day I am going to sit down and finish this series of articles I have been wanting to do where I talk about how I would run companies like Microsoft, Adobe, RIM and others. To say that Flash’s tools are lacking is an understatement. Just look at 3rd party IDEs like FDT and IntelliJ and you will see how far behind Adobe is on their own platform. Even worse is the fact that Unity 3D will be compiling to Flash so that will be the only real solution for a 3D IDE for Flash. Adobe continues to dump so much money into Flash Builder yet a much smaller team maintains IntelliJ which handles countless languages with ease. Adobe doesn’t have a strategy for building developer tools, and the fact that all of their IDE’s still don’t work together is a clear indication on how dysfunctional their future vision for their products is.

Adobe needs to learn how to become a developer IDE company or buy a company that understands what developers want. Microsoft is the exact opposite, they build the best development tools out there, they treat their developers with respect and actually listen to what they want. That kind of dedication to their community really shows through in the tools, the language, and the entire platform. The only problem MS has is that they like to kill off their platforms as soon as they mature. WFP to Silverliight, Silvelright to HTML 5, who knows what’s next? They are a wild card right now with this move to Windows 8 being JS and HTML based. We’ll have to see what they are planning on doing with C# and .Net in September at their Build conference. I’ll be there of course, I think they have an ace up their sleeves. As for Adobe if they can’t migrate Flex over to being GPU accelerated through Stage3d in the next 2 product cycles they will lose any foothold they hope to make in the mobile space. By the end of the year every major mobile language will be hardware accelerated except for Flash.

If you could choose one programming language to rule them all, RIGHT NOW, what would it be?
What’s next for Jesse Freeman?

If I had my choice it would be C# but the reality is that I will most likely be doing JavaScript and HTML 5 for the next few months. There is a lot of posability there and it has the largest potential penetration numbers plus it runs on iOS (to some degree). Right now it’s all about iOS and I am really feeling the itch to learn some Objective C but I keep holding out for Adobe to get its act together. There is an interesting space growing with HTML 5 to Native packagers and some of them even offer native Open GL replacements for canvas. I think the person who figures out how to cross compile JS and still allow it to run on the web is going to be the winner. I have a feeling that Microsoft will be first to market with that. I dream of a C# to JS compiler that is usable. JS should not be written by hand, it’s a language that screams to be generated and I have yet to be impressed with Coffee Script.

Let’s wrap it up with 5 TRUE / FALSE questions:
Canvas games will overtake Flash games by 2013?
False

WP7 will eventually take off and Visual Studio will be on all of our computers.
True (If every computer is a PC)

Adobe AIR will become a wildly popular solution for cross-device development.
True

People will eventually get along and start being creative again.
False

Apple is evil.
True

I’ve known Seb for a few years now and have been a big fan of his work even longer. One of the reasons I decided to take this workshop was a desire to become more familiar with the new concepts going on in HTML 5 revolving around Canvas and WebGL. Seb is a great presenter. If you have seen him at any of the hundreds of conferences he speaks at each year you already know what I’m talking about. Seb has a great way of simplifying complex concepts like “maths” (as he calls it) and making it approachable by design-centric developers like me. Granted, a lot of the math covered is common knowledge, or at least is to me because I have been a Flash developer for the past 10 years, but it was really great to see how all of my Flash skills still directly apply to all the new HTML 5 and JavaScript.

What I Learned

Seb’s workshop is action-packed with a ton of code samples and demos. Here are a few things we covered:

Particles. Yup, Seb is the Particle King. For the past few years, he has always shown off how versatile particle systems were in Flash. It was great to get a refresher course on how to do them with Canvas, and some of the techniques he showed off are simple yet powerful ways to achieve really rich visuals. Here are a few of my particle experiments:

After the basic introduction on how particles work, I quickly built a confetti fountain.

From there, I accidentally created a particle WiFi signal. A big part of the workshop revolves around exploration time.

Soon after the basic particle system introduction, we began working on more complex things like explosions. A great tip on how to get the trails is to repaint the canvas with a slightly transparent fill versus a full clear.

After particles, Seb went into more complex uses for drawing such as drawing trees. It may not sound very interesting at first, but it’s a key skill to learn because it teaches you recursion and how the rotation system works in Canvas. With Canvas, you actually rotate the entire coordinate system when you perform a rotation, kind of how it works in Processing. Seb does a good job of explaining this concept; it helps to think of it as a real canvas so you can rotate it to help make drawing easier. Canvas has a save and restore system so you can save the previous coordinate state, rotate to do your drawing, then restore it to the original state. This is probably the steepest learning curve when drawing with Canvas versus Flash’s system.

From there, we moved onto the building blocks of asteroids, which is a Seb staple from his Flash presentation days and probably the best real-world and fun thing do to with a drawing API. Here is my attempt at making some graphics for asteroids:

Seb presents you with round asteroids, and it’s your job to make them look more random and irregular. It takes awhile to get used to Canvas’s orientation system, but the best part of the exploration time is accidentally coming up with cool things.

Another cool exercise was creating a thruster effect for the ship. Seb has an interesting use for Modulus in order to control and reset the length of the flame as the thruster burns at full blast.

After asteroids, Seb goes into building a simple 3D engine and eventually into Mr. Doob’s Three.js, which is a great 3D engine for JavaScript. The highlight of the 3D presentation was seeing the speed difference between Three.js’s Canvas implementation versus the WebGL version. WebGL is a serious contender in the 3D space, and when/if other browsers actually implement it as well as Chrome has, it will be a very impressive contender to dethrone Flash. Unfortunately, or fortunately, depending on how you look at it, that day is very far away.

Conclusion

If you are at all interested in HTML 5 Canvas, JavaScript, and WebGL, I highly suggest checking out this workshop. It is really perfect for Flash developers looking to transition into the HTML 5 world, and you will be relieved at how much is actually the same. You may also be shocked, like I was, that most of this is old hat by now and hopefully you will be less de-motivated than I was to be revisiting all of these concepts after mastering them several years ago. Seb is a great presenter and probably one of the only people I know who is perfect at giving a class like this. Check out his site for the next workshop time/date/location, and if you want to see how the classes evolve, make sure you follow the #CreativeJS Twitter tag when a workshop is going on.