I’ve been trying for a week to write a post about the recent demo/Android talk I did (along with Mike Koss and Alberto Fonseca) with the Google Technical Users Group in Seattle (huge thanks to Mike Koss for setting this up!) earlier this month.  There’s a comment I made in this talk that has been hounding me ever since.  Since then I’ve wanted to expand on it and make it clear what my position is.  At about 1:08 into the video, I made it sound like getting something out the door is more important than making sure it’s polished.  I strongly believe in the release early and release often mentality.  I have been on far to many projects that have belabored releasing because of some assumed polish that needed to be done.  Whether it was that one more magical feature, or that one more must fix bug, there was always something holding back the release date.  I certainly respect those companies that have the resources and skills to pull the “make sure it’s polished” standard…one of these companies is of course Apple.  They have an awesome sense for design and what customers want, and they have the resources to develop in house and behind closed doors….I don’t…I don’t even have the resources to hire a decent graphic designer or QA person, and if I spent all my time worrying if a certain icon looked pleasing or if that one bug was a show stopper, I’d never, ever get anything out the door.  So as a single developer trying to make the simplest product, I gotta just put it out there and see how it does.  Maybe it’ll suck?  Or, maybe for whatever reason it won’t gain traction.  But wallowing in “does it have enough polish” land doesn’t answer anything, so I choose to get it out the door, and the Android platform allows me to quickly do this.

Maybe I’ll stumble upon that one app that is an overnight success and is so nicely polished that everyone wants to pay me 99 cents for it, but I’m not betting on it…and that statement doesn’t make me feel any less talented then the person who does make that overnight success app.  That person was just luckier to came across (for whatever reason) that one idea that they stuck with and where able to pull off!  And I hugely congratulate them on their success!

Hope you enjoy the little talk we had at Startpad….here’s the link if the embed doesn’t work

Here’s the link in case the embed doesn’t work

Already have plans for some more features (filtering the image buckets shown in the Image Gallery) and with this re-write out of the way I think I’ll be able to get the next version out sooner.

Cheers, and thanks for all the support from the current users of MediaDroid, it’s great to hear all your feedback…good and bad!!

(more…)

(more…)

The new version of MediaDroid fixes the reboot bug.  It’s not as elegant as a fix as I’d like but it does work.  FYI to any developers, the SD Card isn’t necessarily mounted when the ACTION_BOOT_COMPLETED event is broadcast.  I used a CountDownTimer to wait 30 seconds after my BroadcastReceiver is called, then I’m able to access the files on the SD Card.

I added a couple features to Message Drop and fixed a few bugs.  The new features are spelled out on the Message Drop page  and include a new Setting for assigning the “Blank Tag” and a mode helping you build bulleted item lists.

My plan is to switch back to MediaDroid and perform some much needed polishing, and I ran into a Force Close that I haven’t been able to track down yet.  Always more to do!

One thing I’ve found out is that some of the classes from the books I’ve been using as reference have been deprecated.  Apparently, instead of using People.NUMBER, which has been deprecated for future support of multiple accounts, I should use the ContactsContact set of interfaces to get the contacts name and number.  Guess I’ll be upgrading to the Android 2.0 sdk sooner then I thought.  Although according to this forum thread the previous interfaces used to specify contact column, such as People, are still supported and will access contact information from the “primary” account.

Another cool thing I figured out was how to have the phone pad soft keyboard attached to an EditText widget.

It’s one of those, it was so easy I’m ashamed I didn’t know it, but then again, the SDK is large enough to where it’s hard to know ALL of it.  Anyway, all you need to do is define the “inputType” attribute value for the EditText widget which captures the phone number.

   	<EditText android:id="@+id/phone_nbr"
		android:layout_width="fill_parent"
		android:layout_height="wrap_content"
		android:inputType="phone"
		android:singleLine="true" />

Now, when the phone_nbr EditText box is entered, the phone pad comes up for data entry instead of the default Android soft keyboard.

There’s still many aspects of the Contacts API I haven’t investigated yet, but hopefully with the new apps I have the opportunity to work on, I’ll have lots of time to learn more about them.

There’s a trial version available, but if you find it useful I’d greatly appreciate it if you’d help my development effort and purchase the 1.99 version.  By the way, if you purchased Note To Me already, I’d be more then happy to refund your money if you email me an address that I can send the refund to.  I promise not to use your email for spamming!

I would greatly appreciate any comments you may have about Message Drop, Cheers!

AlertDialog.Builder ad = new AlertDialog.Builder( this );
ad.setTitle( "About My Mobile Application" );
ad.setMessage( "This text explains My Mobile Application, thanks for " +
                       "purchasing it from the Android Market!" );
ad.setPositiveButton( "OK", null );
ad.show();

I’ve recently cleaned up a bunch of my code with this simple Dialog. And next I may have to look into the FrameLayout feature mentioned in the Android documentation.