Friday, December 30, 2011

Progress ...

Still working through the core, but am making progress.  The new version will be worth it.

Sunday, December 18, 2011

Progress ...

I sent a basic "does it crash" UI demo to some friends yesterday along with a solicitation for feedback.  I was able to dedicate a number of hours to the project yesterday and it continues to progress nicely.

Saturday, December 17, 2011

A New Version is Coming

I know, I know ... you've heard it before.  Life just sometimes gets in the way.

There's a new version of the app in active development.  It will feature:

  • An Action Bar UI that is compatible with all versions 1.6 and higher
  • Streamlined interface to reduce required clicks from 2 to 1 if the same groups will be sent to
  • Multiple groups selectable in 1 message
That's all I'm going to promise this far ;)  There will almost certainly be more new features included.  Stay tuned for details and screen shots as the release gets closer.

Wednesday, May 11, 2011

The Android Market is FULL of Viruses!

I first heard those words from a gadget loving iPhone fan-boy whom also happens to be a very good friend of mine.  We don't often discuss the pluses or minuses of the 2 platforms because he's not a geek.  He is, by all accounts, in love with anything Apple is willing to put on the shelves for us to consume.

He does ask how my application development is going and is at least interested in that I'm interested.  He asked me one day about all the viruses in the Android App Store and when refuted by me had the evening news on his side.  He did concede that they weren't necessarily viruses in the traditional sense, but rather poorly written applications that cause performance problems, consume more data than they should, etc.  I exclaimed that if that were the classification for a virus then Apple's own machines are the preferred platform for the world's leading virus ... Photoshop.  :)

His comment and the opinion of the main stream media stuck with me.  I can't do anything about it, but it did get me wondering about the complete lack of an approval process for Android developers' submissions.  Apple has one.  Windows Phone 7's is unbelievably thorough.  I have had 2nd hand experiences with both.  Android has none.  That helps keep a low cost to entry, but it does open the door for some poor code to end up on users' phones.

Thank goodness there are a few good developers out there writing quality code; like me!  But wait, I wrote a "virus."  It's true.  I downloaded the Android SDK, the Eclipse ADT plugin, Eclipse and even the Subclipse SVN plugin.  I have source repositories setup to store my code change by change and I maintain this blog to discuss the application, coding in general, etc.  I can Google anything and figure out how to make something work.  That doesn't mean that's how it should or needs to work.  Therein lies the problem.  I can write some fancy code, but you don't know what you don't know!

So, why was my app a virus?  Several versions ago I switched the UI to a tabbed view.  There was major refactoring involved in doing so.  Shortly thereafter I was experimenting with JSON string parsing and how that might benefit my app.  I was debugging something in the JSON app I was building and had left the DDMS perspective in Eclipse open while I was researching.  I kept noticing screen updates in my peripheral vision but it wasn't until I stopped what I was doing to investigate that I realized I had a coding mistake.  My other app had been opened to do some other work and it was the culprit.  It was requesting a new ad from AdMob even though the application was not in the foreground.  It should have been paused and had no activity going on.  In all the refactoring I had lost my onPause() method.  After getting that back into my code things were normal again.  Thank goodness it was for something as small as an ad!

That spurred me to start doing some reading on the Application Life Cycle.  There's fabulous documentation on it provided by Google.

So is the Android Market really full of viruses?  I can tell you that I've seen some really crappy code over the years.  I can also tell you that I take special care (certainly more than most!) to understand my code and do extensive testing.  There are no formal checks and balances and even with the best of intentions my code was consuming more data and thusly more battery power than it should have been.  Whether it's full of viruses or not I know that it has 1 less as of several weeks ago and I will be much more conscience of how my phone performs after I install something new.

Tuesday, May 3, 2011

What Goes Into Source Control, Android?

From the very beginning of my Android App development I knew I would be releasing it into the market.  As such I wanted to keep it in source control.  I'll explain my reasons for that in another post, but here I want to talk about what exactly goes into source control, what to do if you inherit a project that needs cleaned up and finally, how to coerce Eclipse into helping you long term.

I had never created a project outside of Eclipse's new Android Project Wizard so what was part of it's overhead versus what was needed for someone else to build this project on a difference machine?  I asked a few guys around the office and Stack Overflow.  As is always the case I got, "whatever isn't required to build the project doesn't go into source control."  Thanks geniuses.  At least one of them actually pointed me to the official documentation from which I could start to cherry pick the fluff out of my project.  Here's the official documentation on what is required for your project: http://developer.android.com/resources/faq/commontasks.html#filelist

My development environment is Eclipse with the Subclipse SVN plugin and I'm using online repositories from both BeanStalk and Assembla.  A quick scan of my repository and I was a little bummed to find several things in there that did not need to be:

  • bin/
  • gen/
  • .classpath
  • .project
  • default.properties
  • proguard.cfg
A friend and longtime developer asked me why I wouldn't want .classpath included?  Our office has a mix of both Windows and Linux development platforms so I've tried to mimic that as often as possible when doing personal development so I'm familiar with the challenges faced by my colleagues.  Everytime I would sync my local machine after the alternate environment had updated the repo I had .classpath issues.  Some of this could be my own inexperience so if you know the way around this please share ;)

Back to the point ... I did some research and found that I needed a local SVN client in order to accomplish what I wanted to do.  The command is:

svn rm --keep-local {filename/folder}

Execute that for each of the files or folders you wish to get out of source control, but keep your local copy.  I had read on SO that you needed the trailing / after folder names, but I've found that to be inaccurate.  Simply listing the folder "bin" works and actually adding the trailing / does not.

After running the svn command to remove (rm) each of the items I wanted out of source control I executed a commit:

svn commit -q -m "Removing unwated files/folders from source control" .

The next thing I did was set the filesystem level properties to keep them from accidentally ending up in Source Control in the future, but it is leading somewhere.  You can execute the following command from your project folder to add the items to the ignore list:

svn pe svn:ignore .

Just add each item, 1 per line, as above again excluding the trailing / on folder names.

I had tried to do all these things in the SVN perspective from within Eclipse but it would not let me set file/folder properties.  That's what lead me through the exercise outline above.  My next goal was to start with a fresh project and get things into source in the easiest way possible.  As I dug through the entire process I found that I can actually add the ignore property from within the Team Sync perspective!  That's huge as it keeps me (and you) from dinking around at the command line unnecessarily.  After you've "shared" your project go into the Team Sync perspective, right click the project and choose synchronize.  In the left pane you will be presented with a list of files that will be placed under source control.  You can right click them and choose to ignore them.  From here I can control exactly what is and is not going to get into my repo.  That was a big win and almost perfect, but curiosity had me wondering if I could go further.

Eclipse can help by default!  If you look at the Team section in Eclipse Preferences you can add the items to the "Ignored Resources."  I added each item and again created a new project.  This time after sharing it and going to the Team Sync perspective I had only the items listed that were identified in the Android documentation.  Obviously you can start by just doing this and save yourself all the hoop jumping that I went through.

Friday, March 25, 2011

Google Analytics Tricks for Android

I previously did a post about how to track version usage with Google Analytics, but I think I've taken that work and created something better.

I'm using the app preferences to determine if a previous version was already installed.  If it's not then the value of appPrefs.getAppVer() will be equal to a null string.  In that case I record an Application Install event with a label of the application version and a value of 1.  That increments our given version label by 1 in Google Analytics.

If our appPrefs.getAppVer() wasn't "" or "N/A" then it was an upgrade so I record an Application Upgrade with a label of the OldVersion->NewVersion and a value of 1.  That increments our given label by 1 in Google Analytics.  To explain, that means I'll get a count of upgrades from 2.9.4->2.9.5 for instance.

In the case that appPrefs.getAppVer() was equal to "N/A" that means it was a new install and the user clicked cancel on the usage agreement the 1st time.  So, we don't want to record anything.

// Display Recent Changes on 1st use of new version
if (!appPrefs.getAppVer().equals(getAppVerName())) {
 if (appPrefs.getAppVer().equals("")) {
         tracker.trackEvent("Application", "Install", getAppVerName(), 1);
      } else if (!appPrefs.getAppVer().equals("N/A")) {
         tracker.trackEvent("Application", "Upgrade", appPrefs.getAppVer().toString()+"->"+getAppVerName(), 1);
 }
 // display recent changes dialog
 tracker.trackPageView("/RecentChanges");
 appPrefs.saveAppVer(getAppVerName());
 appPrefs.saveAcceptedUsageAggrement(false);
}

// Display Usage Agreement on 1st use of new version
if (!appPrefs.getAcceptedUsageAggrement()) {
 tracker.trackPageView("/UsageAgreement");
 // display usage agreement dialog
 // negative button actions here
        appPrefs.saveAppVer("N/A");
 // positive button actions here
        appPrefs.saveAcceptedUsageAggrement(true);
}

With these tricks and a couple of others I am recording:


  1. For category "Application" I have the following events:
    1. Run -- What version is being run every time the application starts
    2. Error -- If there was an error I capture the version number that was running
    3. Upgrade -- Capture the old version and the version the user is upgrading to
    4. Install -- Capture the version of a new installation
  2. For category "Groups", "Send Message", and "Files" I have the following events:
    1. Success -- Record when something went well like, the user was able to pick a group that contained contacts, or our SMS message body contained text
    2. Error -- Record when something went poorly like, the user tried to send, but had exceeded the hourly message limit, or the SMS message had no addressees
These events are in addition to regular Page Views and should give me a lot of insight into how people are using my app.  One thing I already see a lot of: Groups -> Error -> No Records Added.  That means the user is successfully picking a group off their phone, but it either has no contacts or no contacts with a valid mobile number.  I'll have to find a way to make them more successful!

Sunday, March 20, 2011

Splitting Text At A Fixed Length

As part of my message app I had originally been splitting my message text "by hand."  I found a method in the SmsManager that does the job for you.  Again, it's still a good bit of code so here it is.  Hope you find it helpful.

This will split the message into 160 character chunks to include anything up to 160 characters at the end of the message.

protected ArrayList<String> splitMsg(SmsMessage smsMessage) {
        ArrayList<String> smt;
        Pattern p = Pattern.compile(".{1,160}");
        Matcher regexMatcher = p.matcher(smsMessage.getMsgBody());
        smt = new ArrayList<String>();
        while (regexMatcher.find()) {
            smt.add(regexMatcher.group());
        }
        return smt;
    }

Sending a Single SMS to Multiple Addressees

The net-net-net of this, if you're wondering is, it can't be done.  Hear me out.  I don't want to send 10 SMS messages to 1 addressee.  I can do that just fine.  I was trying to send a single message to 10 addressees in order to get 1,000 addressees the same message rather than Android's 100 addressees/messages.  I learned a valuable lesson about the SDK documentation.  When it says it accepts a "String" it doesn't mean you can trick it to accept a String [].


public void sendDataMessage (String destinationAddress, String scAddress, short destinationPort, byte[] data, PendingIntent sentIntent, PendingIntent deliveryIntent)

I spent a lot of time yesterday getting the code in place to provide "destinationAddress" as a comma (as well as space, semicolon, and new line) delimited list.  No messages get sent unless your list contains only 1 item.  *sigh*

But, I do like the code I came up with so I'm storing it here in the hopes that it might someday be useful in another context.


protected void sendMsg(Context context, SmsMessage smsMessage) {
        SmsManager smsMgr = SmsManager.getDefault();
        ArrayList<string> smsMessageText = smsMgr.divideMessage(smsMessage.getMsgBody());
        PendingIntent sentPI = PendingIntent.getBroadcast(context, 0, new Intent("SMS_SENT"), 0);
        PendingIntent deliveredPI = PendingIntent.getBroadcast(context, 0, new Intent("SMS_DELIVERED"), 0);
        int AddresseesPerMessage = 10;
        StringBuilder builder = new StringBuilder();
        String delim = "";
        for (ContactItem c:smsMessage.getAddresseeList()) {
            //  For every phone number in our list
            builder.append(delim).append(c.getPhoneNumber().toString());
            delim=";";
            if (((smsMessage.getAddresseeList().indexOf(c)+1) % AddresseesPerMessage) == 0 || smsMessage.getAddresseeList().indexOf(c)+1 == smsMessage.getAddresseeList().size()) {
                // using +1 because index 0 mod 9 == 0 
                for(String text : smsMessageText){
                    //  Send 160 bytes of the total message until all parts are sent
                    smsMgr.sendTextMessage(builder.toString(), null, text, sentPI, deliveredPI);
                }
                builder.setLength(0);
                delim="";
            }
        }
    }

Wednesday, March 16, 2011

Broadcast SMS Lite v2.9 Released (Feature Complete)

After just 6 short weeks I am proud to announce the Feature Complete version of Broadcast SMS Lite v2.9!

Broadcast SMS is not intended to replace your handset's SMS messaging tool.  It's rooted in direct marketing.  It was built to talk a sales leads file and broadcast a SMS message to all the phone numbers contained within.  That part was working from version 1.0, but it did get me thinking: I want to be able to send a message to a group of people as quickly as I can.  So, I leveraged the basic idea for Broadcast SMS and created just that!

I send a lot of group texts: to my kids, to friends, etc.  I always hate composing them because I had to select the individuals or get my messaging app into the right place to do so.  Broadcast SMS does this by default. In fact, I will not be building a way to add a single contact to the list of addressees.  Of course I can be convinced otherwise, but that's my going in position.

When you launch the application you're presented with the status screen.  Remember, it's rooted in direct marketing ;)  From there you only have 2 selections: 1 lets you read an input file and the other lets you choose from your predefined contact groups.  You're immediately presented with the message window and a Send (Broadcast) Message button.  That's almost as few clicks as you can make to get a message out to your friends, family, etc.

As always, bugs and feature requests equally appreciated to bill@aydabtudev.com.

Monday, March 14, 2011

Broadcast SMS v2.8 Released

A simple status screen has been implemented.  It will show you how many messages you can send in the next 60 minutes without hitting Android's 100 messages per application per hour limit.

Saturday, March 12, 2011

Broadcast SMS v2.7 Released

It's finally ready! v2.7 introduces a new tabbed UI. Many more under the covers (refactoring) updates, and some other minor tweaks.


Wednesday, March 9, 2011

What's new with Broadcast SMS?

You may be wondering why the next update is taking so long. It's a lot of work. That's why ;) Here's a sneak peak:

Sunday, March 6, 2011

Android: Working with Sqlite Cursors & Queries

If you're like me you learn to code by example.  One of the things I was having trouble with was selecting data from sqlite.  Not that I couldn't figure out how to get all the data, but how could I get just the data I needed.

The generic getContentResolver.query(Groups.CONTENT_URI, null, null, null, null); just seemed wasteful.  Here's what I've gleaned from other posts around the internet and from the SDK documentation:


ContentResolver cr = getContentResolver();
        Cursor groupCur = cr.query(
                Groups.CONTENT_URI, // what table/content
                new String [] {Groups._ID, Groups.NAME},    // what columns
                "Groups.NAME NOT LIKE + 'System Group:%'", // where clause(s)
                null, // ???
                Groups.NAME + " ASC" // sort order
        );

Further, if you want to just get a single row by it's _ID you can do this:

ContentResolver cr = getContentResolver();
        Uri myGroup = Uri.withAppendedPath(Groups.CONTENT_URI, "16");
        Cursor groupCur = cr.query(myGroup, new String [] {Groups._ID, Groups.NAME}, null, null, null);

Hope this is helpful and saves you some grief ;)

Thursday, March 3, 2011

Android: Tracking Version Usage

I had wondered and I've heard it asked, "How do I know what versions of my Android application people are using?"  The quick answer that you'll get is, "You don't."  I found a way using Google Analytics to track a couple of things: 1) you can track the number of people upgrading and/or 2) you can track the specific version usage!

I created a pop-up dialog that announces the recent changes to the user after an upgrade.  Inside that logic I put a trackEvent call to Google Analytics with a label of the Application Version and a value of 1 so each time that dialog is presented I get a +1 for that label.  Here's how:

if (!appPrefs.getAppVer().equals(getAppVerName())) {

    ...

    tracker.trackEvent("Upgrade", "Click", getAppVerName(), 1);
    appPrefs.saveAppVer(getAppVerName());
    appPrefs.saveAcceptedUsageAggrement(false);

 }

getAppVerName() is just a helper method that does the following:

public String getAppVerName() {
    String text;
    try {
        text = getPackageManager().getPackageInfo(getPackageName(), 0).versionName;
    } catch (NameNotFoundException e) {
        text = "Version Not Found";
    }
    return text;
}

On your application's main activity screen you can also add a trackEvent to help keep track of which versions are being executed like so:

public class MyActivity extends Activity {

    GoogleAnalyticsTracker tracker;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        tracker = GoogleAnalyticsTracker.getInstance();
        tracker.start("UA-12345678-1", this);
        tracker.trackPageView("/HomeScreen");
        tracker.trackEvent("HomeScreen", "Click", getAppVerName(), 1);
        tracker.dispatch();
        setupViews();
    }
}

Google Analytics will record 2 events for you: one called Upgrade and the other called HomeScreen. Both will have a label of the version making the call and a counter.  Also of note; in the recent changes logic I also set the Accepted Usage Agreement to false allowing me to re-display the usage agreement on upgrade.

Tuesday, March 1, 2011

My First Troll!

I, or my App rather, have/has arrived!


1-star
by rudo (March 1, 2011)
It sucks, does not work at all and freezes m phone
I figure if I'm not doing something right I wouldn't have hate mail.  Internet trolls are an odd bunch.  The Android Developer Console doesn't report any Force Close or Freeze issues so my best guess is a competitor not liking how well my app is doing :)
1,400+ downloads with ~400 active installs totaling more than 13,000 activity views since February 12.  There hasn't been a reported error from the app or from the Android Developer Console in over a week (since version 2.2.3).
The best feature to date is very close.  If you text groups of people frequently and are, or are not a direct marketer you're going to really like the next update.

Monday, February 28, 2011

Broadcast SMS v2.6 Released

Broadcast SMS is really, really getting close to feature complete for the Lite (ad supported) version.  Today added some more Help and About changes.  A couple of subtle tweaks and an Accepted Usage Agreement on Send.  Working on stitching texts together so they show up as 1 on the remote phone.  Also working on selecting a "group" from your contact list in addition to reading from a file.  That should make the application more usable for the general populous in addition to direct marketers.

Sunday, February 27, 2011

Broadcast SMS v2.5 Released

The help and about texts have been reworked.  I implemented a change list pop-up on 1st use after an update.  More refactoring work.  Really enjoying the direction the code is going.

Broadcast SMS v2.4 Released

I added Google Analytics to the application as well as some major refactoring of the file management portion of the application.  Added a restriction of 1,024 bytes to each line read from the input file.  Closer and closer to feature complete with the free version.

Saturday, February 26, 2011

8 Days ...

It's been 8 days since the last force close or freeze (ANR) error.  7,000+ activity (screen) views.  Versions 2.2 and 2.3 definitely did a lot for stability and error checking.  I've added Google Analytics to the application though I have not pushed that version to the market yet.  Making sure I am getting the kind of use data that will make future development smarter ;)  I'm getting my activity view stats from AdMob at the moment.

I've also started refactoring the data management 1/2 of the application.  The whole app has come a long way since its humble 3-activity screen beginnings.  Everything was tied together with static variables and methods.  Surprised it worked at all honestly ;)  Probably the funniest part about that is I had a simple null line check in place to keep people from getting empty items into the addressee list.  When I started refactoring I broke that check.  My force close errors went from 2 to 8 in a couple of days.  That's when I realized I needed to redouble my efforts and get the SMS 1/2 of the application refactoring done.

There's some cool stuff coming.  Stay tuned.

Thursday, February 24, 2011

Broadcast SMS v2.3 Released

This version is almost feature complete for the free version.  I added a rolling history of messages transmitted to ensure you don't violate Android OS' 100 messages, per application, per hour limitation.  I continue to refactor and harden the application.  The rolling history check should eliminate the last known Force Close issue.

I have one outstanding feature request to investigate for the free version and some general cleanup work to do.  Darrell has asked that I find a way to stitch the messages together to appear as 1 large message on the receiving phone.  I will be working toward that end before the final free release.

Feature requests and bug notifications equally appreciated!

Tuesday, February 22, 2011

1-hour History

At present the app is dependent on you, the user, to regulate yourselves by not sending more than 100 messages in an hour.  An hour is surprisingly long time when you're waiting to send more messages and the occasional Force Close report supports my suspicion.

I'm on the verge of a release that will keep track of how many messages you've sent in the last 60 minutes and present a dialog to keep you from making a mistake.

Trust me; this isn't the end of the message limit issue.  I just want to eliminate as many force close issues as I can before starting any new feature development.  I also have a lot of refactoring to do.  Quick and dirty means I ended up with a lot of "work" being done on "screens."  That has to go ;)

Monday, February 21, 2011

Helper Classes

Lots more OO implementation work on Broadcast SMS.  Nothing to release tonight, but I've moved all the Application's Shared Preferences into a helper class.  Sure makes things easier to follow.  Assembla source control and the good ole telephone make code reviews possible across several hundred miles.  I can always tell when my buddy thinks something is odd ... he has this long pregnant pause.  Many thanks GPZ!  My code wouldn't be what it is today without your help.

SMS Message Limit Identified

And there it is ...


/** Default checking period for SMS sent without uesr permit */
private static final int DEFAULT_SMS_CHECK_PERIOD = 3600000;
/** Default number of SMS sent in checking period without uesr permit */
private static final int DEFAULT_SMS_MAX_ALLOWED = 100;


You can send 100 messages from any 1 application every hour.  Any more and your phone will get cranky.  Stay tuned.  I have a way around this that doesn't require you to elevate your permissions ;)

Sunday, February 20, 2011

Broadcast SMS v2.2.3 Released

As previously mentioned the Android OS has a hard limit of 100 messages. I am working on a way around this without rooting your phone. As an immediate fix to a force close issue I published a version this morning that locked the SMS message to 160 characters or less.

As of version 2.2.3 your messages can be greater than 160 characters but you'll have to send to fewer recipients. So, if you have 161-320 characters in your message you'll have to reduce your addressee list to 50. If you have 320-480 characters = 33 addressees, etc.

If you try to send again too soon you'll get a force close. If anyone can identify what that timeout period is it would be much appreciated.

Force Close Issue Identified

Darrell Y. wrote me to inform me that messages greater than 160 characters were causing a force close issue.  I have put in a hard 160 character (byte) limit to eliminate that issue.  I will be implementing multi-part SMS messages in the next release.  Thank you Darrell!

Saturday, February 19, 2011

Message Limits

I'm working on it. I have several ideas about how I'm going to handle this problem. If you send more than 100 messages in a given amount of time you're presented with a pop-up dialog box (see below) that you must click in order to continue sending. 100 messages seems to be the limit on Verizon in the Android OS though I do not know the period.

Sending SMS Messages -- Unknown application A large number of SMS messages are being sent. Select "OK" to continue, or "Cancel" to stop sending.

Friday, February 18, 2011

AYDABTU Development's 1st $1.00

After just 5 days AYDABTU Development has made it's first $1.00! Whether that really goes anywhere or not remains to be seen. This is all 1 big experiment for myself in application development. I'd be doing it for free, but since it's so easy to add ads to the application I might as well earn a little coin (very little!) for the effort. Keep using the app ... (keep viewing the ads!)

Proud of Broadcast SMS v2.0+

Now Broadcast SMS looks and behaves completely differently than it did in its 1.0 iterations. It's managed by an umbrella application and all the static methods and instance variables have been removed. Everything is behaving in an orderly OO fashion. My friend Android Code Monkey, aka Greg Z., has been so very helpful through this entire maturation. He has to repeat himself so many times until I smack my forehead like the V8 commercials as it finally sinks in. Thanks Greg!

In addition to managing everything much better I've added very robust regular expression checking to the phone numbers that are read in and used as the addressee list for the application. Localization is nearly complete with only the Help and About dialogs needed to be finalized. I used Google Translate to provide crude Spanish translations mostly as a test, but I did release the app in Spanish as well. I have done some work to reposition my ads around the screen.

There's still lots of feature work to do, but I've been focused on fixing any force close issues over the past couple of days. There little tiny mysteries and they're very tricky to track down!

I have sent myself 100 SMS messages several times tonight trying to force the issue. All-in-all it's coming along nicely. So, if you're a current user and have been frustrated please hang in there! It is under active development.

Broadcast SMS Features & Enhancements

There was a lot of furious development between 2/6/2011 and 2/12/2011 and a fair share of lost sleep. Help and About dialogs were added. Backgrounds, icons and subtle tweaks to the UI were made in an attempt to pretty things up. Storing items in the local preferences for the application was added. Lots of little error checking methods were added.

Then on 2/12/2011 something else hit me. I'm doing this out of sheer love for coding, but why shouldn't I earn a little coin in the process?! I added AdMob ads to the application. By 2/15/2011 I had done a considerable amount of refactoring, added ads and had most of the application ready for localization. It's at version 1.3.4 now.

Broadcast SMS v1.0 Released

This is a historical posting as this really happened on 2/6/2011!

I was approached by Stuttering John Smith for assistance with a telemarketing application he was having trouble with. I started looking through the code and identified some quick fixes to the issues he was having, but I also noticed some glaring design issues. Within a few days I had it in a working state and gave him the source code.

That app really got me thinking ... I can do something like this and I had a lot of ideas about how to make it better! The original code I hobbled together was a collection of a few activities and some static methods to handle the data transports. This is my 1st attempt at OO code and my 1st attempt at Android. I always want to learn and improve so I took this code to the local Cincinnati .NET Users Group meeting called BitSlingers. It's an informal affair but I figured that was a good place to get a code review. My good buddy Nate went with me and offered to provide some feedback. That was awesome because I knew we were good enough friends that he could be brutally honest. Man was my code a mess. I was so proud to have published that app in the Android market, but it was a train wreck. I took notes and watched a few more of O'Reilly's awesome videos "Developing Android Applications with Java." That set me on a path of extensive refactoring ...

Bringing It Altogether

There's a lot more to publishing an app than slapping some code together in an editor and uploading it to the Android Market. Over the next few days/weeks I'll be getting everything consolidated here: where it should be. Thanks for being patient. Remember, this is a hobby not a job. Giving it every spare moment I have.