Beta books are awesome

I feel like I spend more money on Beta books than real books.

For those of you not familiar with the Pragmatic Programmers they have a great concept called "Beta Books". When they have a book idea, instead of sitting on it for a year and half before it's completed, they give it to the world in Beta form. The idea is simple enough: A good book, like good software, needs time to iterate in order to make it better. Beta books normally come out months before the actual release date and the authors and community of Beta readers start a dialogue. It's all very Agile. Readers can do simple things like point out typos and grammar problems, or more ambitious readers can critique the actual content, suggest better ways of implementing something or suggest additional content. In fact, if you look through some of the Pragmatic Programmer Forums you can see that some books went through significant changes before going to the presses. This process is fantastic and provides a better product in the end.

The latest in this series is a real gem, Cocoa Programming: A Quick-Start Guide for Developers.

I love this book for a lot of reasons but the main one has to be that I read and followed through the entire Beta Book (around 100 pages) in two nights. I wasn't rushing, but I moved through it quickly. I was excited to read more. I wanted to learn more! The idea of the book is to give programmers with no Objective-C or Cocoa experience a Feet First look at the language and more importantly, the tools that Mac OSX provides for building awesome Cocoa and iPhone applications. (Not totally true, because of the Apple NDA, they can't give much detail about the iPhone SDK, but most of the Cocoa topics apply so it's all good).

Daniel Steinberg does a really good job at getting you excited about the language and frameworks really early on. In true Agile form, you make little things that work throughout each chapter. In fact, your first project is to build a Web Browser. Yes... a browser. Granted, this is no Chrome or Safari but suddenly seeing how you might build your own robust one is not so far off. The book also encourages the courageous and inquisitive programmer to explore more advanced topics that he doesn't feel necessary to cover due to the scope of the book. All in all, this Beta book is shaping up for a great finish. I can't wait to re-read it as the iterations are released.

Thanks to Pragmatic Team for once again delivering books that I actually want to read!

Kent

Serving .cab files using Google

After spending some time trying to get nginx to serve up .cab files I found a really cheap, really easy alternative, Google Sites.

Google Sites is a great way to easily and quickly publish content to net for your users to download. For my Masters thesis, I am developing a mobile application that is currently being targeted at the windows mobile platform.  As much as I dislike many aspects of this platform (see my other posts). I really like how easy it is to deploy your application using the built in tools.   Microsoft has fantastic documentation for deploying your windows mobile application using the built in tools, however that is only half the battle.  Unless you want to send this file via email to all your users, they need a way to download it fom the web.

I tried getting the cab file up there in a few ways.  My application is written in Ruby on Rails and I am using a newly popularized rails server stack that sits on nginx.  Problem was the documentation for nginx isn't stellar for anything other than serving rails or django.  I had trouble configuring the mime types to server up the cab files consistently.  Cab files are really just a different form of compression like .rar or .zip but it wasn't recognizing it the way I wanted to.

Then it hit me!  Use Google Sites!

That's exactly what I did.  I posted the file that way and directed my users to that link on their mobile browsers.  Once they click it the file downloads and installs from there.  Google Sites also tracks versions of the same file which for me was perfect since the application is changing on a weekly basis.  I've been using it on the past couple of builds and it's been great!  Thank you Google for another fantastic service.

Kent

SqlCe Connection String

I am leaving this post for the generation of Windows Mobile programmers, who like me spent over 45 minutes trying to find how to get the connection string work for SQLCE 3.5 using the .Net Compact Framework.

I don't know why this information is so cryptic, or why I felt like Indiana Jones when I uncovered the truth!

Of Course its so simple!

Why didn't I find this sooner?

How come this wasn't in the first line of documentation?

If you are reading this post with earnest and eager anticipation like a child ready to devour an unopened present, then you will be saying the same thing in several minutes. Read on, read on.

Basically, unless you do some digging you will find that Microsoft did something less than obvious when setting up Database Connections using Visual Studio and a Mobile Device. You would expect to be able to use relative paths for everything right? It makes sense that if you create something in a given project, then to reference it you would use a relative path right? Well, you are clearly wrong! You have to use different paths depending on whether you are developing or deploying! Don't ask me why but you do!

I will not try and re-invent the wheel and give you all the details on how to set up the connection using Visual Studio since Sam Allen has done such a job of doing so here, http://dotnetperls.com/Content/SQLCE-Database-Use.aspx.

I ran into a few problems since Sam made a few assumptions that didn't work out for me and might cause some problems for others as well. He suggests using the system properties object like so,

Properties.Settings.Default.datanameConnectionString;


However, this doesn't always work depending on how you have your environment configured and when starting a Smart Device Project, you might not have access to this.

So really what you are looking for is something like this,

string conString = @"C:\work\projects\vsproject\database.sdf";
using (SqlCeConnection con = new SqlCeConnection(conString))
{
con.Open();
}


Problem is, Visual Studio assumes you know that all of the files for your Smart Device Project are copied to the Device you are deploying to. The default location is in the Program Files directory of your device. Okay, this sounds easy enough! Yet, if you read the documentation you will see this sprinkled around,

string conString = @"My Device\Program Files\SmartDeviceProject\database.sdf";


This does not work! It might have worked with .Net 2.0 or Visual Studio 2005, but it doesn't work with the newest software. Good news is that there is an easy fix! All you have to do is remember that Mobile Devices have a root directory '\'

So here it is! Are you ready? It's been a long journey but I was happy to go along with you.

SQLCE 3.5 Connection String for a Windows Mobile Device Project is...

string conString = @"\Program Files\SmartDeviceProject\database.sdf";


Where SmartDeviceProject is the name of your Project and database.sdf is the name of your database!

I hope this helps!

Good night,

Kent

I Can't Touch Windows Mobile

I have been using Windows Mobile for about six months now and have finally gotten to the point where I need to start talking about some of its shortcomings. All in all, I do not regret using it since it has been very easy to prototype with but having looked at all of its competitors save maybe Symbian, I can't help but feel that they will be in trouble if they do not make significant changes in the coming years.

One of Windows Mobile's biggest shortcomings, is the lack of a Touch Screen API. While some might disagree with me on this, there is NO easy way to handle touch screen input in Windows Mobile 5 or 6. Having explored this topic quite a bit, I have found that most ways of dealing with touch normally rely on creating custom form controls that use some button hacks to listen for a touch and drag operation. I understand that when this platform was released the number of touch devices were limited, however, in this market they are not. In fact, windows mobile had by far the largest number of touch screen phones yet gives developers no easy way of using utilizing them.

A lot of this comes from the fact that Microsoft seems to want developers using the new Managed C# frameworks rather than the Native C++ frameworks. I thank them for this! Writing Visual C++ is hard enough on the desktop and gets worse on the device when memory is such an issue, however, some key features are not included in the Managed Libraries, such as a Touch API.

Needless to say this will be addressed when Microsoft unveils their new Touch Framework for devices and for Windows Forms, but they might loose some developers like me in the process. Apple and Google have very nice Touch APIs for their mobile devices and its obvious given the amazing applications people are writing for them. It's funny how Google still has the killer app for Windows Mobile... Google Maps Mobile. It really utilizes the touch screen, but like many amazing Windows Mobile Apps is completely written in C++.

Maybe this is Microsoft's way of getting serious developers into programming for Windows Mobile by only showing off these advanced features for skilled C++ developers, but why are pushing this C# thing so hard then. I would love for someone to correct me and give me a great solution that doesn't involve me going over to the codeproject and downloading some half baked control.

I Love you for so many things Windows Mobile, but wish you were a bit taller!

Kent