Monday, June 16, 2008

Today, is day 15 of my 30 Days of .NET challenge. That marks the 50% point, and we have 15 applications for 15 days. Thanks for your support!

And we have made it through another week. If you missed the week one recap here it is: 30 Days of .NET [Windows Mobile Applications] - Week One.

What’s your favorite?

 

image image image image
Rotate Me Mobile Tipper What is My IP? Mobile Signature

Lots of variety, everything from network utilities, to graphics, to humor, to SMS text messaging. Great ideas, guys!

 

image image image image_thumb14
Mobile Quiz Pocket Death Calculator Mobile SMS Contact What will be next?

 

Feedback:

Got an idea? Got some feedback? Share it? Thanks!


Monday, June 16, 2008 02:48:00 (Eastern Standard Time, UTC-05:00)  #    Comments [7]  |  Trackback

Today’s application is about possibilities. It’s a new area we will explore in our future applications. It’s important to learn how to development applications, but it is also important to learn what kind of applications you can develop. Your goal is always to reach just a little further, and grow from the experience.

 

The important thing here isn’t what this application does with these ideas, but what you could do with these ideas.

 

People can use SMS to send and receive information through text messages, but with the power of Windows Mobile it is easy for application to send and receive commands and data. There is a big movement for software to expose its features and functions to other programs. But image a world, that probably isn’t too far, where your mobile device has it’s own API that you and others can use to access its data and functions.

Where could this be useful? Well many companies need the ability to send “Alerts” of some kind to their workers. It is easy to use the Windows Mobile SMS API to have a custom written application that check for specially “tagged” SMS messages.

 

image

Mobile SMS Remote

SMS Remote is an application that could run on two or more Windows Mobile device and allow each of the phones run to support “commands” on the phones. For example, a user could get the date and time of another device running SMS Remote. Or the user could run a command to get the other phone’s current GPS location information. The possibilities are limitless. Both devices are both servers and both clients in other words a very simple peer-to-peer network using SMS technology. How cool is that?

What if sometimes we don’t want others to be able to run commands on our device remotely? First of all we could always exit the application. The application must be running in other to execute remote commands. Be I have also added an “Allow Remote Commands” feature.

How can we send SMS remote commands? Use the SMS command ComboBox and choose a command, and enter the remote device’s phone number. Then just click “Send”.

How can we tell what commands have been remotely run on our device? There is a received commands listing at the bottom the screen. It shows the phone number of the device that send the command, the time the command arrive, and which command was requested.

This is a rough prototype of an idea that has HUGE potential. Some point in the next ten years this concept will take off and become something along the lines of Mobile 2.0.

The trick to this application is using the very cooly named Windows Mobile 6.0 SDK MessageInterceptor class. We can use it to have any SMS that begins with “30days:” fire an event in our application that we will then handle. This is very, very, very simple for something so powerful. Use it!

   1: MessageInterceptor _smsInterceptor = null;
   2: private void LoadSmsIntercepter()
   3: {
   4:     _smsInterceptor = new MessageInterceptor(InterceptionAction.NotifyAndDelete);
   5:  
   6:     _smsInterceptor.MessageCondition =
   7:         new MessageCondition(MessageProperty.Subject,
   8:         MessagePropertyComparisonType.StartsWith, "30days:", true);
   9:     _smsInterceptor.MessageReceived += SmsInterceptor_MessageReceived;
  10: }

The rest is simple. Was the SMS a “command” or a “result”? If command we need to run and return a result. If result we need to act on or display to device user.

Possibilities:

I implemented the get date and time function, but not the GPS function. This would be a very useful addition to the application that I would love to say a reader did. Or how about a way to add Internet Explorer Mobile favorites? Or how about something more Web 2.0 like what song is currently playing.

Download executable: mobileSMSRemote.cab

Download Source Code: mobileSMSRemote.zip

Feedback:

So what possibilities do you see for this type of application? for business? for entertainment?


Monday, June 16, 2008 01:58:00 (Eastern Standard Time, UTC-05:00)  #    Comments [2]  |  Trackback
Sunday, June 15, 2008

Today one of my readers, Paul Diston, made the following request.

Hi,
I have another idea you might be interested in. I would like to be able to type in a single SMS message and then hit the send button which would then send the same message to all my contacts that have a mobile number specified.


Thanks
Paul Diston

The thing that I really liked about Paul’s suggestion is that is cover two very important mobile development topics: one is working with contacts stored in Outlook Mobile, and the other is working with SMS messaging.

image

image Mobile SMS Contact

I changed it a little bit from Paul’s original request. I decided to incorporate a filter into the application. This way you can send SMS messages to your personal contacts, or your business contacts. You could even create a custom category. I didn’t include an option to select contacts that do not have a category assigned to them. This would be a great modification for a reader to implement. Simply add a ‘<none>’ item to the list, and if that item is selected add any contact that doesn’t have a category.

I added a ListView so that users could see the contacts they were about to text message. Another great enhancement, would be the ability to modify this listing. Just a remove option would be a great addition in functionality.

One feature I added as a polishing touch, was the live character count feature. This feature lets users know how much more text they can send. And we have found another opportunity for improvement here. I limit the text to 160 characters, but if someone entered in more text we could send X number of text messages until the complete message was delivered.

Next with have our SMS Message TextBox where we can type the message we will send. Nothing special here, but I didn’t set a MaxLength of 160 characters.

At the bottom I exposed the RequestDeliveryReport property of the SmsMessage class. What ever the user picks here will be assigned to that property.

One feature that I really love about Windows Mobile programming, that especially came in useful for this application was the Cellular Emulator.

GetContacts Code:

   1: private List<Contact> GetContacts(string category)
   2: {
   3:     List<Contact> contacts = new List<Contact>();
   4:  
   5:     ContactCollection contactsCollection = outlookSession.Contacts.Items;
   6:  
   7:     foreach (Contact contact in contactsCollection)
   8:     {
   9:         if (contact.Categories.Contains(category))
  10:         {
  11:             contacts.Add(contact);
  12:         }
  13:     }
  14:  
  15:     return contacts;
  16: }

SendSMS Code:

   1: private void SendSMS()
   2: {
   3:     List<Contact> contacts = GetContacts(comboBoxCategories.SelectedItem.ToString());
   4:  
   5:     SmsMessage smsMessage = new SmsMessage();
   6:     //Set the message body.
   7:     smsMessage.Body = textBoxSMSMessage.Text;
   8:  
   9:     foreach (Contact contact in contacts)
  10:     {
  11:         string name = string.Format("{0} {1}", contact.FirstName, contact.LastName).Trim();
  12:         string address = contact.MobileTelephoneNumber;
  13:  
  14:         if (address.Length == 0) break;
  15:  
  16:         //Add recipients.
  17:         smsMessage.Body = textBoxSMSMessage.Text;
  18:         if (name.Length == 0)
  19:             smsMessage.To.Add(new Recipient(address));
  20:         else
  21:             smsMessage.To.Add(new Recipient(name, address));
  22:         smsMessage.RequestDeliveryReport = checkBoxRequestDeliveryReport.Checked;
  23:     }
  24:  
  25:     if(smsMessage.To.Count == 0) return;
  26:  
  27:     //Send the SMS message.
  28:     smsMessage.Send();
  29: }

Download executable: mobileSMSContact.cab

Download Source Code: mobileSMSContact.zip

Feedback

One thing I decided not to do with this application is spend any time on the UI. I wanted readers to see one application that was plain Jane vanilla. Consider what you could do to this application to make it appealing to end users. Share your ideas, and maybe I’ll do them, or even better try taking the code and making the changes yourself. If you do this for the application or any other I will link to back to you so everyone can “see” and “learn” for your efforts.


Sunday, June 15, 2008 02:10:00 (Eastern Standard Time, UTC-05:00)  #    Comments [2]  |  Trackback
Saturday, June 14, 2008

Let’s have some fun today. And do an application that is just for kicks. I had a really hard time coming up with a Friday the 13th themed mobile application. I finally thought of one: The Pocket Death Calculator. Yeah, it’s a bit crazy, but it’s good not to take yourself too seriously. There are lots of these Death Clocks on the Internet, here’s a famous one: The Death Clock.

 

image

image

Pocket Death Clock

This application is about how many lines of code you can write. It shows how a simple idea in a good looking package can really charm a lot of people. Most people enjoy a surprise, or something unexpected, something to break the day from being ordinary and routine. Sure you can write the next great mobile financial planner package, or you could write a quick “fun” app to put a smile on someone you know’s face.

The UI is really simple just a background image file, but it is a good looking background image file. And that is pretty much what is pulling off the application. I thought about putting glowing red eyes on a timer and having their visibility randomly change, but decided to leave it as an exercise for my readers. Try it you’ll be surprised how much it really sets off the application. And makes it stand out.

The death calculation engine is straight forward: we take the user’s age and gender and modify the average human life span appropriately. Then we subtract the users present age from their expected life span. Next we calculate the number of seconds in a year. We use our cryptographically strong random function to pick a random second in that year for the user to “die” on. Now we have our death date. It’s a simple matter to calculate the number of seconds the user has left. We put everything on the screen and update on a timer.

There you have it.

Possibilties:

Simple applications always have the best possibilities. We talked about adding glowing eyes. But you could also add random death quotes. You could also ask the user more questions and better guesstimate their death date. You could also “guesstimate” where and how they would die using data easily found on the Internet.

Always good to know you have less than a million seconds before you are going to die from a shark attack in Quebec. Plenty of time to pick up some shark repellent.

 

 

 

 

Download executable: pocketDeathClock.cab

Download Source Code: pocketDeathClock.zip

Feedback:

I think this is our first humorous application, not counting Mobile FX, what did you think of it? Would you like to see more of these types of applications, that are creative idea based, or more of the technically focused applications? I like to keep a good bit of variety to show all the possibilities, so I hope that is working for everyone.

If not, share your idea for tomorrows application.


Saturday, June 14, 2008 00:14:00 (Eastern Standard Time, UTC-05:00)  #    Comments [5]  |  Trackback
Friday, June 13, 2008

Today we are going to look at another classic goal in Mobile development, data collection. You might need it for a line of business application, for example a field service application where workers need to inspection equipment and fill out a questionnaire. Or you might need it in a mobile poll taker application. You could even use it in a trivia game. There are few applications actually that couldn’t take advantage of a question and answer system like the Mobile Quiz.

 

image

imageMobile Quiz

There is so much potential with this application. I hope you can see the concept and see the potential here. There are a world of possibilities here. Hopefully this application will help you get ever so slightly closer to realizing some of them.

The UI is a straight-forward and clean design, which was easy to make but should appeal to users. Everything is meant to be intuitive and self explanatory. Users should simple be able to look at the screen and get it.

The first screen is an quiz introduction form. All we have here is some eye candy, the name of the quiz, and some basic menu options: Start, About, and Exit.

After this the user is presented with the questions screen. This is the main meat of the application.

Questions are pulled from an XML file which could be retrieved from a remote server.

 

   1: <?xml version="1.0" encoding="utf-8" ?>
   2: <quiz name ="Family Guy Quiz">
   3:   <question>
   4:     <text>In what state do the Griffins live?</text>
   5:     <correct>2</correct>
   6:     <answer>Connecticuit</answer>
   7:     <answer>Rhode Island</answer>
   8:     <answer>Massachusetts</answer>
   9:     <answer>Deleware</answer>
  10:     <answer>South Carolina</answer>
  11:   </question>
  12:   <question>
  13:     <text>What television actor is the mayor of the town?</text>
  14:     <correct>1</correct>
  15:     <answer>Adam West</answer>
  16:     <answer>David Hasselhoff</answer>
  17:     <answer>Leonard Nimoy</answer>
  18:     <answer>William Shatner</answer>
  19:     <answer>Harrison Ford</answer>
  20:   </question>
  21:   <question>
  22:     <text>What is Cleveland's last name?</text>
  23:     <correct>1</correct>
  24:     <answer>Brown</answer>
  25:     <answer>Smith</answer>
  26:     <answer>Craft</answer>
  27:     <answer>Cub</answer>
  28:     <answer>Jones</answer>
  29:   </question>
  30:   <question>
  31:     <text>What is the name of Stewie's stuffed bear?</text>
  32:     <correct>3</correct>
  33:     <answer>Barry</answer>
  34:     <answer>Chris</answer>
  35:     <answer>Rubert</answer>
  36:     <answer>Edward</answer>
  37:     <answer>Paddy</answer>
  38:   </question>
  39:   <question>
  40:     <text>What is Quagmire's profession?</text>
  41:     <correct>4</correct>
  42:     <answer>Developer</answer>
  43:     <answer>Police Office</answer>
  44:     <answer>Barber</answer>
  45:     <answer>Pilot</answer>
  46:     <answer>Teacher</answer>
  47:   </question>
  48: </quiz>

 

It’s a snap to open the XML file and read in all of our data.

   1: DataSet dataSet = new DataSet();
   2: // read quiz data file
   3: dataSet.ReadXml(@"\Program Files\MobileQuiz\quiz.xml");

One thing that I decided was important was to avoid showing modal MessageBox dialogs often. Sick Instead I choose to use a label, place it at the top, set it’s background color to Info, and use it accordingly. This works out great and I think is a much better user experience. Data entry on a mobile device is a huge pain, and if you can take a dialog out of the equation that’s a good thing.

Download executable: mobileQuiz.cab

Download Source Code: mobileQuiz.zip

Feedback

There’s a lot here for a little effort, a couple hours, and there is a huge potential for this type of application. This would be a great project for someone to expand on and create something really special from. Consider it if you are looking for your first mobile project.


Friday, June 13, 2008 02:49:00 (Eastern Standard Time, UTC-05:00)  #    Comments [0]  |  Trackback
Thursday, June 12, 2008

image

You know sometime someone tells you about something, and you can tell there is a whole lot more to it than they are telling you about. Well, signature capture for Windows Mobile is one of those things. It’s really not bad today and you can do it in one sitting easily now. But there was a time, when if your life depending on it you might be able to get it right. At least we have managed code now. A few of us attempted to do this feat in embedded Visual Basic years ago and I’m surprised it didn’t cost us our sanity. Oh the humanity…

You could do it you just had to copy each color pixel by pixel and save it into a bitmap, and that was a challenge too. And GetPixel() had to be the slowest function call ever. It took at least a second. No way, you were going to give someone a full screen to put there signature.

That was then, this is now…

image

Mobile Signature

Office 2007 might have 2007 features in it. And it works for Office 2007, well to a point. But with Windows Mobile applications less is more. Don’t get me wrong I really do think Mobile Signature would make a great feature in a more complete application. But as far as the feature of taking a signature on a mobile device this is a great approach.

Also note that Mobile Signature could be easily adapted into a drawing application, and so on, especially for kids.

Let’s talk about UI first. Notice how much space is dedicated to taking the user’s signature. This is important; I’ve seen almost the reverse before and that just isn’t very usable. I took a little extra time and care to make sure all control had a black border around them,expect the black color square. It has a gray border.

One thing to note is a wanted the user to be able to tell what color they would be writing in without having to draw on the screen. This is accomplished by having the borders around the active color flash on and off. This is a great visual effect that was easy to implement with a timer. We track the currently active color in a form level variable, and on the timer tick event, which happens every 500 ms, we toggle the visibility of the border around the active color. Works great! Check it out!

The menu is another area that is simple but you can learn from it. Save is very important to us, so it is prominent and has it own hardware button that can cause it to occur. On the menu we have an option for clearing the screen, showing the about form, and exiting the application. But we also have a menu option to change the size of the line we are drawing with. It can be set from any of the following: 1 pixel, 3 pixels, 5 pixels.

The core of the application is the code that actually draws the lines on the screen. Here it is:

   1: private void pictureBox_MouseMove(object sender, MouseEventArgs e)
   2: {
   3:     if (pen.Color != signatureColor)
   4:         pen = new Pen(signatureColor);
   5:  
   6:     if (pen.Width != width)
   7:         pen.Width = width;
   8:  
   9:     x1 = x2;
  10:     y1 = y2;
  11:     x2 = e.X;
  12:     y2 = e.Y;
  13:  
  14:     if (x1 == -1 && y1 == -1)
  15:         return;
  16:  
  17:     pictureBoxSignature.CreateGraphics().DrawLine(pen, x1, y1, x2, y2);
  18: }

 

One area of code that is worth checking out is the code to save the bitmap of the signature. It’s pretty advanced and powerful.

   1: // P/Invoke declaration
   2: [DllImport("coredll.dll")]
   3: public static extern int BitBlt(IntPtr hdcDest, int nXDest, int nYDest, int nWidth, int nHeight, IntPtr hdcSrc, int nXSrc, int nYSrc, uint dwRop);
   4:  
   5: const int SRCCOPY = 0x00CC0020;
   6:  
   7: private void Save(string filename, Graphics gx, Rectangle rect)