Posts Tagged ‘.netcf’

Accessing authenticated Google App Engine services from a .NET CF client

Monday, August 24th, 2009

Google App Engine (GAE) gives you an easy way to build and host web applications for free.

For any address you specify in your GAE app, you can require users to be authenticated. For example, if you have this in your app.yaml:

- url: /authme
  login: required

When a user goes to in their browser, they get taken first to a logon page and promtped for their google username and password.

Only if they authenticate correctly will Google pass them back to your page, and let them access your /authme page.

(This is kinda nice, because as a GAE app developer, you shouldn’t need to see the user’s password. Although, I guess most users won’t make a distinction between typing in their username and password into the login page and into a login form on an page.)

If you are writing browser-delivered apps, this is all fine and works as described. This is slightly trickier if you are writing a web service that you want to be accessed by a client app. I wanted to access a GAE web service from a mobile client – this is how I’m doing it.


Programmatically getting the CellID from your Windows Mobile phone

Wednesday, March 12th, 2008

I’m still on paternity leave at the moment, so time near a computer is limited to 20 or 30 minute periods in the rare occasions while Faith is asleep!

But in the last few days, I’ve still been playing with a few new geeky things. One of these is FindMe – a Windows Mobile application from Electric Pocket.

screenshot of FindMeThe basic idea is:

  • it gets the CellID of the GSM transmitter that your mobile phone is currently talking to
  • if it hasn’t seen this CellID before, it displays “You are in a new place” and prompts you to type in a name for where you are
  • if it has seen this CellID before, it uses the name you last entered for it

Then it uploads your name for the CellID (your description for where you are) to your Facebook profile.

Hey presto – location tracking without the need for GPS.

It works quite well.

I’ve played with location based stuff on my phone before but never tried to use GSM cell id before. I did consider it, but after failing to find a free database that could transform the cell id string into a location I could plot on a map, I didn’t really pursue it any further.

Playing with FindMe encouraged me to give it a try.


Cryptography with C# in Windows Mobile

Monday, February 11th, 2008

I wrote last week about an evening I spent throwing together a password manager for Windows and Windows Mobile. As I wrote at the time, one of the motivations was to try writing some encryption code.

I’ve finally got around to writing it, and wanted to post it here with a few comments.

This is what I needed code to be able to do:

  • Encrypt and decrypt data based on a user-provided password
  • Encrypt/decrypt consistently on both Windows desktops and Windows Mobile devices – a file encrypted on a Windows Mobile PDA should be able to be decrypted on a Windows desktop, and vice versa

The System.Security.Cryptography library in .NET makes this fairly straightforward – the class I have written to add crypto support to the password manager app needed only a few hundred lines of code in total.

I’ve shared a simplified version of the source at the end of this post.


Writing a mobile password manager

Thursday, February 7th, 2008

I miss developing mobile apps. With the exception of the never-ending tweaks and revisions to my mobile wiki app, I’ve not done any mobile development in weeks. (Is it very sad that I missed it? 😉 )

Until tonight. Hurrah – back to playing with fun stuff.

One of the things I typically want to use on my phone is a mobile password manager – particularly as I do more web browsing on my phone, and mobile browsers like Pocket Internet Explorer and Opera Mobile don’t remember passwords.

I’ve tried several existing password managers – I’ve even paid for a couple, like eWallet (love the way it shows credit card details to look like a pretend credit card) and SplashID (always loved the desktop version). But I never found one that I really liked. At the moment, I’m back to storing passwords in a text file, and using mobile Notepad to access it.

There were problems with all of them…

One-handed or stylus-free navigation is bad – Teeny-tiny controls. Drop-down lists that you need to not only touch the screen to open, but then scroll up and down in. Basically, take a look at a design doc like this and do the opposite of pretty much everything 🙂

Too many clicks/presses to get to a password – SplashID for example: to get a website password, you touch the screen to open the category drop-down list, touch the screen to scroll to the “Web Logins” category, scroll through the list to the website you want, touch the screen to select it, press the “Tools” button, then press “Unmask Fields”. Too much.

No clipboard access – Unforgivable, this one. I like to use randomly generated passwords where possible. Once you’ve used the fiddly controls, and gone through all the steps, you can see the password on the screen – hurrah! Can you copy it to the clipboard for pasting into a web form? Nope. Even Ctrl-C / Ctrl-X / Ctrl-V don’t work – and most apps at least leave that basic Windows clipboard support in. So you have to remember your password after reading it. And with my passwords, that’s a pain. I used to find a scrap of paper, and write it down to make it quicker to type back in. So secure(!)

Actually, to be honest, even after all that, the final straw that stopped me using SplashID was the fact that it’s sync plugin consistently hosed my ActiveSync. Not only would it not sync, but it’d crash ActiveSync and stop everything else from syncing too. The day I uninstalled SplashID, my phone became a million times more useful from that alone!

This was all enough of an excuse to try throwing together my own password manager.


New file and directory open and save dialogs for Windows Mobile

Tuesday, November 20th, 2007

Windows Mobile – like standard Windows – has a default “file open” and a “file save” dialog that all applications can use. If you’re writing an app, you can use it in your code with just a few lines. Great!

Except… no. Because they’re rubbish.

This has come up as an issue raised with a couple of apps that I’ve written that use the standard dialogs. I would defend my apps by saying that I didn’t write the dialogs, and that they’re the same that you get in other Windows Mobile apps like Microsoft Word Mobile. But I can’t, really. For a user, this is just an excuse. Wherever the dialog came from, it is rubbish.

I’ve written a couple of new ones for use in my applications. They’re fairly small, so I’ve made them available if anyone else wants to use them with their apps.

In this post, I’ll quickly outline what is wrong with the standard dialogs, and introduce my new ones.