Mobile
WP7 Emulator Screen Size Management
Mar 16th
I’ve been developing Android apps for awhile now and at times the emulators are SOOO big that they litterally consume the entire screen real estate and its very difficult to navigate through the enumlator. I was very surprised when I started up the WP7 emulator and started finding out how simple it was to scale the emulator to fit my screen.
All I had to do was select the settings:
Then, select the screen size I wanted:
The screen could scale accordingly now.
Examples
100% (Very Large) – Its so big that it falls off the screen.
50% (Smaller), now it fits nicely, however the UI is hard to read.
This makes life much easier when developing for a high resolution system on a non-high resoution system.
WP7 Boot to VHD
Mar 15th
Tonigt I downloaded the WP7 Developer Tools on a new VHD (Boot to VHD). I’d I’d have to say … its super easy.
File –> New
As soon as the tools are installed you can select File –> New Windows Phone Application, as seen below:
Selecting a new Phone app, I was able to get some XAML on the screen, edit the XAML and get my first Hello WP7 app up in running in under 5 minutes. This very impressive. The emulator started right up, I waited for about 30 seconds while it booted and then my app started. As shown below:
All in all, it was a super simple process.
Boot to VHD
It is important to note that working from a virtualized environment is not supported with the Dev Tools for WP7. However, you can boot to vhd and it will work great (which is 10x better than a VPC in my opinion for regular dev anyway).
So if you havent already, start utilizing Boot to VHD, set a a new one and get started with the new WP7 tools. Its cool/fun stuff.
I’m a Considered a Top Android Dev, Cool!
Mar 4th
This last Tuesday I received an email from the Android Market Seeding Program letting me know the following:
Due to your contribution to the success of Android Market, we would like to present you with a brand new Android device as part of our developer device seeding program. You are receiving this message because you’re one of the top developers in Android Market with one or more of your applications having a 3.5 star or higher rating and more than 5,000 unique downloads.
Very Cool. I wasn’t sure what device I’d get, but further down the email it was mentioned:
You will receive either a Verizon Droid by Motorola or a Nexus One. Developers with mailing addresses in the US will receive either a Droid or Nexus one, based on random distribution.
I’m hoping for a Nexus One only because I’m a T-Mobile customer and I would love to actually USE The phone as well as develop for it.
Why is Google doing this? Plain and simple: Most of us developers who received this have been developing for close to a year or more. That means almost all of us are running on old hardware – eg: G1’s. The new phones have more memory, better displays, multi-touch and most of all … the updated 2.x operating system. The G1 does not have those features. Google is trying to stimulate the growth of the 2.0 market by providing the top devs with new hardware to develop on. Genius. This theory is also shared by the guys at TechCrunch.
Whatever the reason, I’m anxiously awaiting my 2.0 device. I cant wait to develop for it.
Now… if I could only get Microsoft to send me a phone … hmmmmm 
Expanding Your Career: Mobile & API Development
Feb 17th
There’s no denying the fact that I’m heavily involved with mobile development. Currently my platform of choice is Android platform (the Google nexus one pictured to the right). However, I’m not just a Android programmer. My day job as most know is a .NET Developer. I spend most of my time working with ASP.NET MVC web applications. These two compliment each other very well (I’ll get to this in a minute), and since the Windows Phone 7 Series is going to be running .NET capable apps I’ll begin writing apps for those as well. I have no idea who will win the war in the mobile field in regards to carriers and operating systems (if the war can even be won) but I do know this …
The future of all software development will be heavily influenced by mobile development and mobile integration.
Why?
We’re all doing things on our phone. I check email, update twitter, update my Facebook page, upload photos, use navigation, look for restaurants (and a million other things), all from my phone. All of these features are only available because a developer (or team of developers) brought the features to the phone. Most of these applications are nice rich user interfaces which communicate with back end services via web API’s (usually REST API’s nowadays). For this to happen, the developer/team/company had to plan for this type of integration. You simply cannot fire up a Android app (or iPhone, WinMo, etc) and connect to a website and “get data”. Sure, you can open a web browser, but lets face it, that experience SUCKS. You have to plan and create an API that is agnostic to your platform if you want to survive on the mobile front.
For example – I’m currently developing a v1 product that is a mobile application. Currently I’m working on the Android piece, then I’ll port to WinMo & iPhone eventually. The application interfaces with a website via a REST API built with ASP.NET MVC. This allows me to program via “resources” that the client can interact with. This also opens up the doors to allow third party applications to be written against the API.
Why does this matter? Take a look at Twitter. Sure, its a great service and all, but the website stinks. It offers not great features and in the end, it really lacks what Twitter is a huge stream of information. Its hard to consolidate it so its readable and digestible. Twitter would be nowhere near the level of popularity without apps such as Twitterific, TwitterBerry, Tweetdeck, Twhirl, Echofon, Swift, Twidroid, Twikini, and many other apps. Of these apps, I’ve named a desktop app, a iPhone app, an Anroid app, a browser plug-in, a Windows Mobile App, a Blackberry app, etc, etc etc. This is all possible because the proper API’s were designed for consumption of third party devices. Now take away the mobile platform and we’re now stuck with a browser based “status update” system. Bringing the feature to the phone really hits home.
API’s
Twitter has many API’s, that include the REST style API as well as a US Short Code API that allows you to text your updates in. This is perfect. People can update on the fly if they need to. The reason why Twitter is successful is because its easy to use. There are no boundaries. Want to update while you’re on the train going into NYC? Sure, no problem. Text it in. Want to read your twitter feeds (friends, DM’s etc) while at the Dentist office? Sure, fire up your app on your phone. Don’t have an app? Download it from the app store, why not … it’s free. Sitting at home on the laptop, hit the website or fire up TweetDeck.
The interface options are endless. By preparing yourself for mobile consumption you can accomplish the following:
- Create an market for others to consume your content as they see fit.
- Allow yourself to consume your content via the apps you write for various platforms
- Expand your application service beyond the OS boundary of the problematic “this is a windows app” or “this is a MAC app” or “This is a Linux only app”
- … and … it will help your career, immensely.
The Future
I’ve been saying this for almost two years now. Mobile development will overtake classic software development because the rate of adoption of mobile phones is much higher than the rate of adoption of classic computers/laptops/net books. Overseas everyone uses their mobile phone for everything. This is a precursor to what’s coming to the US next as well as the rest of the world.
Even Google’s own Eric Schmidt believes that mobile development is the future of software development:
“Our programmers are doing work on mobile first,” he said. “We’ll still have a desktop version, but we’ll also have one on a high-performance mobile phone. The top programmers want to work on mobile apps.
“Phones are so much more personal and satisfying. The phone is no longer just a phone, it’s your alter ego – it’s fundamental to everything you do.” source
I’m not saying that classic desktop or enterprise software development will come to an end, but I do see that a lot more of it will be focused on “how” we as developers can make sure that the content we place online is consumable by external sources, such as mobile phones. REST API’s are soon to become more common than they are now, and I’m sure we as a community will devise better ways to expose and consume content as time goes on.
But if I can close with one thought, I’d close with this one: If you choose to learn anything new this year. Learn to program on a mobile platform. Learn Android, iPhone, WinMo, whatever, just learn to do it and … innovate. These devices are so powerful. They contain more hardware features than a classic computer. Storage (SD Cards), Cameras, Video Cameras, Microphones, GPS, SMS, Phone, Contact Management, Accelerometers. These are not phones anymore, they are computers in your pocket.
Android Tip: Watch Screen Sizes
Nov 7th
Yesterday was Droid Day. Honestly, it was crazy from my perspective. I’ve been a G1 owner for 6 months now and I love the phone. I’ve been trying to convince people to buy Android phones since. Some people did, some people said “Nah, I want to wear a turtleneck and drink mocha latte’s while discussing the influence art” (get an iPhone). But, droid day, whoa, serious people came out of the wood work and bought phones. The team at my client went from 3 out of 8 people having android phones to 7/8 literally overnight.
Anyway, the point of this post is this: With all the new Android phones coming out, screen resolution/density is something you HAVE to watch out for when developing Android apps. Use the emulator to test ALL different densities and resolutions. You MUST, otherwise your app wont get the attention it deserves.
Example: My apps looked great on the HVGA screen (default G1 size) but looked like poo-poo on larger density screens. Things were out of place, mis-aligned, etc.
A friend of mine, Joshua Dobbs, posted a great blog article on how to get around this in the short term (to at least get some “best-case” app rendering) by adding a few properties to your manifest.
Check out the post here.