Categories
Articles Software

"Conversion to Dalvik format failed with error 2" with Android and the Team Foundation Server 2010 Eclipse Plugin

Recently I’ve been working on an big Android application where I work set for release later this year.  It’s going to be a great help to employees and distributors in the field letting them do all sorts of things they normally need to be at a computer for.  I’m using my Macbook Pro to do development as it’s easier to not have to switch back and forth from OSX to windows as I’m building application features in parallel in an effort to release simultaneously (which may or may not be smart).  One thing, though is that we use Microsoft’s Team Foundation Server at work, which is, of course, a Microsoft product.  Luckily they bought TeamPrise somewhere along the line and now there’s a great Eclipse plugin (unfortunately and frustratingly, only available to Bizspark or MSDN Ultimate subscribers – license key required upon install) to let you check in/out right from within Eclipse.  However, I had one problem that I couldn’t seem to figure out until I accidentally seemed to find something that works…

Categories
Articles

How To Sync Multiple Outlook Calendars and Google Calendar Using Google Calendar Sync

One of the most annoying things that I had to face when I got my Android phone was the calendars.  Android uses Google as the service behind email (gmail) and its calendar.  I, like many of you, use Outlook as my primary calendar, since it has all of my meeting requests built-in with it.  In Android, the Corporate Calendar app lets you connect to the Exchange calendar, and the regular Calendar app connects to Google’s service.  Sure, fine, right?  but what happens when you have conflicting appointments across your personal Google calendar and your outlook calendar?  What if you want everything all in one place so you can just put up one calendar widget on your Android desktop?  Well, the answer my friends is Google Calendar Sync.

Categories
Articles

Why I don't write for the iPhone (Or, Why I'm Not Scared to Invest in Android)

One of the things I say a lot is the quote “Incentives make the world go round”, and that, my friends, is true.  So why do I develop for the Android platform and not the iPhone?  The iPhone certainly has that “cool” factor about it.  I even own a MacBook pro and have access to an iTouch for testing, so I have everything I would need.  When I was looking for a new phone last November, one of the top priorities for me the prospect of developing and releasing new applications for my device of choice.  So why then didn’t I pick up an iPhone?  Let me explain…

There were three major phone platforms out in the Winter of 2009: iPhone, Windows Phone, and Android.  I knew iPhone would currently be the most popular device to release an app for.  Second would be Android, since its market share was (extremely) rapidly increasing.  Then, there was Windows Phone, which showed great promise with Zune integration (I LOVE my ZuneHD).  There were a few different things that I had to consider when I was picking out a phone (and ultimately, a platform), but let’s focus on the ones that matter from a software development and business aspect:

  • Current and Future Popularity
    • iPhone was definitely leading the pack at the time, but Android was passing it up quickly, and is doing quite well now.  Windows Phone looked great, but was late to the party for me to consider it at the time.
  • Interfaces
    • No lie here, iPhone has an amazing interface, partly due to no (and now minimal) multitasking.  Android is good, but could use some work, partly because screens are different across devices, so apps have to be built in such a way that all devices have a great experience.
  • SDK
    • The SDK for both are great.  There are lots of APIs to hook into and lots of functionality to leverage (I wrote a very light iPhone app for version 2).  The documentation for iPhone is good, with several videos explaining the development process.  However, Android’s developer center is absolutely top-notch.  They have videos and in-depth tutorials that are the best I’ve seen in a long, long time.  The best part, however, is that Android’s developer forums (used for Q/A) is actually officially integrated as a part of StackOverflow.  That community is amazing and very quick to help you understand anything you’re banging your head against.
  • Development Language
    • If you’ve ever switched from Java to C#, or vice versa, you’ll know they are very, very similar.  Windows Phone is C# (.NET) based.  Android is Java based.  Both are popular, solid languages with tons of support and lots of community involvement.  iPhone development uses objective-C, an extremely popul…wait…objective-C?  Oh, you didn’t say C?  Not even C++?  So, wait, wait…is it anything like those?  The syntax is totally different you say?  Oh…well, looks like you had better start your steep learning curve so you can get that app out the door.  Also, you better ask your boss for an extension, because this could take a while.  Or, you could always write for the iPhone using a mixture of .NET and the convolutedness of the the way objective-C and development on the iPhone is structured.  Good luck with that.
  • Marketplace
    • The marketplace on both are good…once you get and stay there.  The iTunes store feels like the cheapest app is $0.99, whereas the norm for Android apps is Free.  So, if you’re after making money, iPhone is probably the way to go.  Of course, you have to be approved…and stay approved…and Apple has to not change their mind.  You see, on Android, Google and the community builds in functionality like tethering, and cool apps like the Google shopping app.  Also, you have community options like ShopSavvy.  Just because ShopSavvy’s functionality is the same as one of Google’s apps, Google just tries to BUILD A BETTER APP, whereas Apple simply bans you from the marketplace altogether and causes your app to shut down.  From Apple’s perspective this reduces competition, provides a more consistent interface, and cleans out duplicate apps (read: anti-capitalism).  From an app developer’s business point of view, this increases risk DRAMATICALLY.  Would you be willing to invest hundreds of thousands of dollars into an app, only to have Apple steal your idea, integrate it, and then kick you out?  Tough luck, chump.  Android is the only sure bet that you will 100% have a chance.

So that, in a nutshell, is why I write for Android and not the iPhone.  Or, it could just be that I have a Droid and AT&T service is terrible where I live.  You know what they say, “Incentives make the world go round”.

Categories
Articles Software

Android Project Part II: Reading RSS Feeds

The first real goal for the Android app was getting news updates into the app.  One of the main goals of the app is to be able to get up-to-date information that mirrored that of the harvesttn.com website.  As you probably already know, content is typically served up using an RSS feed in today’s world.   With that in mind, the first real piece that I needed to write for getting news notifications was to build a way to consume and display an RSS feed.

One of the great things is that reading an RSS feed
in code is an extremely common activity.  The first thing I did was look for a library that I could use to grab and read the feed.  I eventually found an article from IBM with code using Android’s SAX parser to parse an XML feed and place it into a ListActivity.

I copied over the code, and basically used the MessageList class as a template for my NewsUpdates class in my app.  Not much needed to be changed, except for the way it loads the feed.  The code on IBM’s site grabs a feed from a hardcoded URL in the FeedParserFactory, and out of the box only contains a .getParser(ParserType type) method, passing in what method you want to use to parse the XML (I used Android-SAX).  I figured that I may need to reuse the FeedParser again, so I overloaded the getParser method to pass in not just the type, but also a feed url, as you can see me using  in the code below.Once I did that, the rest of the code is just getting and displaying the information that the FeedParser got for me.  first, you just get the items out of the parser into something that you can use. Here’s a simple way to get and parse the RSS feed, modified from the ListActivity in IBM’s code and simplified for easier use. Here’s a simple way to get and parse an RSS feed once it is modified (read the whole article if you’re cutting corners):

/*In a ListActivity class, this is in a loadFeed(ParserType type) method. Of course, this isn’t really necessary to read a feed. Only down to the “List<Message> messages = parser.parse();” line is necessary. You can then iterate through each message and call standard getters for each of the items to get the Title, Description, etc.*/

//Get a new FeedParser from the factory.
//Pass in the type of library you want to
//use as well as the URL of the feed
//you want to grab.
FeedParser parser = FeedParserFactory.getParser(type, getString(R.string.News_RSS_Feed));

//Parse the feed into the Messages so you can
//use the feed data more easily in your app.
List<Message>= parser.parse();
String xml = writeXml();

//Iterate through each RSS entry and grab the titles to use as the content in the ListView
List<titles>= new ArrayList<string>(messages.size());
for (Message msg : messages){
titles.add(msg.getTitle());
}

//Add the ListView via an ArrayAdapter
ArrayAdapter<string> adapter =
new ArrayAdapter<string>(this, R.layout.row,titles);

this.setListAdapter(adapter);

DONE! Simple as that. RSS is a great way to integrate content into you mobile application and have a similar (and often better) experience to the web version. The original IBM post is located below, where you can also download the full source.  This code was writted for Android SDK release 3, but it worked perfectly with the 7th release (Android 2.1). Remember that when you copy over the code into your project, ensure your manifest file properly registers all the appropriate activities. Otherwise, you’ll get a force close.: http://www.ibm.com/developerworks/opensource/library/x-android/index.html

Categories
Articles

Android Project Part I: Background

For starters, let me give you some background on starting this blog series.  I spend a lot of time looking things up and learning.  The downside?  I forget things.  So, this will be a win/win.  I can write things I find out down here so that I don’t forget them AND since Google will crawl this site, I will be more likely to re-find it in the future!

I’m going to be writing a miniseries on Android App development.  My home church is Harvest Community Church (or Harvest for short) in Kingsport, TN.  Like many churches, you can get updates, listen to sermon recordings, watch videos, and the like.  The problem for people like me who are very mobile oriented, is that I rarely “go” to a site from a real web browser anymore.  There’s an “app for that” on my phone that aggregates all that information and brings it straight to me.  My calendar, contacts are all synchronized with Facebook and Twitter and my information is all brought to me via Google Reader and the magic of RSS.

The problem is that trying to stay up-to-date with what’s going on at the church from day-to-day is hard!  Nobody wants to have to spend 15 minutes swyping the bulletin calendar into their phone.  This is the motivation behind HarvestDroid and what I want eventually to be an open source ChurchDroid template for any church to use (replacing RSS/Photosharing/Content addresses and locations). My initial requirements and posts will be:

Requirements

  • A Tab menu to divide the following sections
  • News Tab
    • This is a list of announcements
  • Radio Tab
  • Sermon list
  • Videos
    • Open media with music player intent
    • Open media with embedded player
  • Visit! Tab
    • Phone call integration
    • Email integration
    • Google Maps Directions/Navigation Integration
  • Future Enhancements
    • Android notifications of updates
    • Social integration
      • Facebook?
      • Foursquare?
    • UI Skinning (Gotta fancy it up, right?)
    • Offline Access/Caching (This targets 3G/Media, so I assume the app to be connected 99% of the time you use it)
    • Add events to the Google Calendar app

So, as of now, that seems like a nice list.  What do you think?  If you had a mobile app for your church, what would you want to help you stay connected?