Marc Melvin’s Blog

I recently had to find a way to merge a ResourceDictionary that is embedded in a class library into my application’s MergedDictionaries collection, so this is how I did it. I created the following extension method:

    static public class ExtensionHelpers
    {
        static public void AddAssemblyResource(this Application app, string assemblyName, string path)
        {
            if (!UriParser.IsKnownScheme("pack"))
                UriParser.Register(new GenericUriParser(GenericUriParserOptions.GenericAuthority), "pack", -1);
 
            ResourceDictionary dict = new ResourceDictionary();
            Uri uri = new Uri("/" + assemblyName + ";component/" + path, UriKind.Relative);
            dict.Source = uri;
            app.Resources.MergedDictionaries.Add(dict);
        }
    }

Then, to add my resource, I simply call

App.Current.AddAssemblyResource("My.Assembly.Name", "Path/To/Resource.xaml");

It’s a new one on me… seems that everyone on the internet is whining that Android 2 (the update currently available on Droid, Nexus One, etc) doesn’t have multitouch support… what they mean to say is that the built-in Google Apps, like Maps, Gallery, etc. are limited in multitouch support. As an Android developer, I’m perfectly capable of writing the same multitouch applications for Android 2 right now that you see on the iPhone, so stop spreading your Apple fanboy FUD all over the internet. Thank you.

Here’s a link to the Android SDK for proof.

The company I work for is making a huge deal about dress code lately. Anyone that knows me knows I’m not a big fan of dressing up because it stifles my ability to focus on my work. Dress pants are uncomfortable and get more uncomfortable throughout the day as you move around, and dress shirts have the same problem, in addition to the fact that long sleeves just aren’t practical in South Florida due to the weather. I don’t mind wearing nice shoes, but if they expect me to keep them nice and polished, just like if they expect me to iron my shirts and pants every morning, then they are just setting me up for failure. After all, the whole reason I took the job in the first place was because of how relaxed the environment seemed. I have better things to do than to worry about whether or not I have a crease in my shirt. It may seem petty, but comfort is my #1 productivity fuel.

So, in an attempt to be objective, I decided to look up information on dress codes and see if maybe I’m missing the big picture. I came across a post by Jason Warner that I really agree with. He says that dressing for success is important, and that you should try to always dress to be who you want to be to further your career goals. That’s when I realized that only a small part of my problem is with the clothes themselves. The problem I have with dressing for success is that I don’t want to be the person that wears suits to work because it isn’t me. The day I wear a suit to work is the day that I own my own company and am doing it on my own terms. Right now, I’m a programmer, and I’m not supposed to be seen. That’s how I like it.

Regardless, I’ve decided that I’m going to start dressing for success in my own way. I am going to wear the clothes that remind me of who I want to become, and that show my desired career path. While I’m sure my coding abilities will get me 95% of the way, maybe my new style is the 5% I’ve been missing to actually get me over the hump that has been holding me back. That’s why I’ve decided my New Year’s Resolution will be to fill my closet with these.

Thanks to UserVoice, Tetroid users now have an efficient way of suggesting and voting for most wanted Tetroid features. Check it out and let me know what is most important to you!

The current version of Tetroid has hit somewhat of a brick wall in terms of ability to move forward, and the fact that everyone is making extremely clear in their comments to me is that it is lacking several key features that should’ve been there since the beginning. Since I had never planned on releasing it in the first place, I skipped over some of the seemingly fundamental design elements needed for a successful mobile game, the biggest of which would be the pause feature.

With that being said, I’ve decided to take an all or nothing approach and rewrite Tetroid from scratch, this time following the recommended practices provided by Google. Here are some of the features that I’ll be focusing on:

• There will be a pause feature in the next version, both manual and automatic.
• There will be plenty of room, performance wise, to add in sound effects and animations.
• Multiple styles of play (not just classic Tetris) that should keep the game interesting.
• Online high score system to make it competitive.

This game was my first Android game and my first mobile game, so I’ve learned a lot in the process. I’m going to take one last stab at going back and doing it right from scratch, then I’m going to move on to my next project which should be a much more original, and hopefully way more fun, mobile game.

Tetroid v1.0.5 for Android is released to the marketplace.

Tetroid v1.0.4 for Android is released to the marketplace.

Just as the title says… I’m currently sitting in Kendell Regional with my amazing, wonderful girlfriend, Debby. She’s sleeping right now, so I’m trying to be as quiet as I can be. I had the chance to talk to the EMTs that pulled her out of the car and brought her here… one of them said something that I will probably never forget. He said, “she is very lucky.”

Now I’m thinking… a lot… considering that I have plenty of time to do so at the moment… and it is really hitting me how fragile and short life really is. If I had lost her tonight… well… thank God I didn’t. There is a whole lifetime of experiences that I want to share with her. She has changed my life in ways I can’t begin to explain. Every day has a reason now since I’ve met her. She makes it all worthwhile. And I love her for it.

Anyways, for anyone that might be wondering, she is going to be ok. She may leave here with some broken bones, but the point is she is leaving here. And soon. I’m sure that annoying beeping sound isn’t helping her sleep.

Tetroid v1.0.3 for Android is released to the marketplace.

• Complete facelift on gameplay screen.
• Movement calculation algorithm for all supported inputs have been improved.
• Sensitivity settings have been improved.
• Width/height of play area can be changed.
• Touch movement support added.
• Touch/drag up and down options for rotate/drop added.
• Level and lines indicator added.
• Game gets a tiny bit faster with each level increase.
• Next and swap preview added.
• Touching the swap area will exchange the next and swap pieces.

And probably a few things I’m forgetting. Here’s a few screenshots of Tetroid for those that haven’t seen it and are curious. Click for larger image:

As always, keep your eyes open for more updates!

 
I’m a strong believer in agile development. No matter how big or small the project, from my experiences, agile methodology always yields the best results. Release early and release often should be every developer’s mantra, and user feedback should be the device that drives future development and modifications. In a perfect world, this should always result in a solid product that matches user expectations while reducing the development time involved.

I’ve been asked by several people in the Android community, “What in the hell were you thinking releasing Tetroid the same night you started it, and especially when you knew that you would get negative feedback on the flawed controls and missing features? Aren’t you worried about all of the negative feedback that will follow the game all the way through to the point when it is polished and perfect?” My answer to this is no. I have nothing to lose from it, and the end-user will win in the end because of it.

First, let’s examine the alternative. Let’s assume for a moment that I had started working on Tetroid over a year ago when the Android SDK was first announced by Google. A year is a lot of time to develop a product, test a product, provide a featureful application, and remove any inherent flaws in the process. After a year of waiting, the first release of the game would probably be very polished and very clean; however, no matter how hard you try, you can’t make everyone happy. There is no software product in the world that is without a negative review by someone somewhere. There would still be negative feedback regardless of how “perfect” it seemed at time of release because everyone’s view of “perfect” is quite different. Unfortunately, after a year of development, most of the processes have been decided upon and are tightly coupled in the application to the point of not being able to be changed easily. To change a piece of an application that is so deeply embedded in the logic at this point is extremely difficult and takes a lot of time, therefore creating much longer release cycles. Something that would seem so simple to change could take weeks, and might not be able to be changed at all without producing a seemingly different application in the end.

Now, let’s examine the agile methodology of “release early and release often.” By immediately releasing the semi-working Tetroid that was designed, developed, and tested in a period of 8 hours, I was able to receive immediate feedback from the user base. Of course the feedback was 99% negative (and actually surprisingly more constructive than I was expecting!), but unhappy customers are the best source for great product feedback, and man did I receive plenty! The following day, I released a second update that attacked the issue that I felt was mentioned by at least 75% of all negative feedback I received: trackball support. Believe it or not, I never had any intention of supporting the trackball (after owning a Blackberry for several years, I am fairly ANTI-trackball). If I had waited years, months, or even a week to release Tetroid to the public, it still would not have had this feature and I might not have put myself in a position where I could add trackball support in a single day like I did. This easily could’ve required weeks to refactor the logic to support trackball input, and the user base’s faith in the product would’ve been completely destroyed by that time.

There are plenty of advantages/disadvantages to using agile and not using agile, but I believe that it has really made a big difference here. Tetroid went from being unplayable to playable in a single day, and it may be only another day or two before the negative feedback relating to ”fun factor” is resolved.

As for the negative feedback following the product through each update, I am counting on the users to change their comments and ratings as time goes on and Tetroid improves. My logic for this is that if they had time to bash it initially, they will probably put in the time to praise it for its improvements. If they don’t, then oh well. The only thing that matters is that the product is improving and the people that are willing to ride the updates and provide constructive feedback along the way are the ones who will win in the end.