Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

Wi-Fi Router Charts

Click for Wi-Fi Router Charts

Mesh System Charts

Click for Wi-Fi Mesh System Charts

Moving Past Images

Another feature in my plan for the app was including content in addition to images. For starters, I knew I would bring in Facebook and Twitter. Then once I had the ability to handle generic text data, I would bring in RSS feeds to greatly expand the possibilities for content.

Dealing with Facebook and Twitter meant some architectural changes in my app. Both of these feeds would obviously need to handle user authentication, something I had avoided to this point. I don't have enough room in this article to describe the process of authenticating against these services. But if you want to dig into it, both services use a protocol called Oauth. Facebook describes their interface here, and Twitter does the same here.

Using Oauth authentication turned out to be a big pain in my app because it is really designed for web-apps and not a native OpenGL app like mine. Figure 5 shows the screen that displays when a user has selected the "Facebook Feed" button within my app.

Facebook permissions

Figure 5: Facebook permissions

This doesn't look too bad, but the actual sequence of screens and user responses is very awkward. The user first uses my native UI to select Facebook. Then a web browser type interface spawns to go to where approval is granted (or denied) for my app. Then the browser goes away and you're back in my interface. Now repeat the same sequence for Twitter and it gets real awkward for the user.

Luckily, this only has to happen once per installation as the app can save and re-use the approval tokens received. It can also get real ugly, if the user tells the app "Use Facebook" and then tells Facebook, "Don't allow the app access". What does this mean for the app? Likewise, if the user selects one of these services when the Internet connection is down or spotty, the interaction can get even uglier. I still have a rare crash when flipping back and forth between the OpenGL display and the browser and it appears to be deep in the Android libraries. So I'm not sure I can catch it. Sigh...

Once I got these services up and going, I moved on to RSS. I wasn't experienced in dealing with raw RSS feeds, but I had hoped that it would be standardized. Instead, what I found was that the basic text in an RSS feed was easy to extract. But to get at additional content such as images from a news story or videos from YouTube, I'd have to write a bunch of "special case" code to handle selected sites. Ugh.

Parsing through a large RSS feed also turned out to strain the processor on the phones that I was using for testing. I could tell when a RSS feed came in, because the nice smooth scroll of images on the main screen would suddenly start stuttering and stalling. I'm not sure I have this completely solved yet, because there are a lot of slow phones out there. But in general, all my content is fetched in background threads of execution.

To give the user-facing code priority, I just cranked the priority down on the background threads and in the case of RSS, added randomization to prevent me from trying to process a bunch of feeds simultaneously. Figure 6 shows the app running with many of the content types, including Facebook, Flickr, RSS, etc. displayed.

App with multiple content types displayed

Figure 6: App with multiple content types displayed

One fun thing I added was a bit of a mashup where I used the curent twitter trending topics to search many different sources using an API from Using this API, I could get access to ebay, Craig's list, Zillow and more. It was kind of fun until I came upon an unexpected result that I luckily caught before the app went live.

One seemingly innocuous trending term brought up a triple-X image from a Craigslist personals section. Oops. So I had to put in a special case to skip the Craiglists personals section when using trending topics. If that's your thing, you can still explicitly (ha!) search for it. But I didn't want it to come up by accident. Note that there is still no guarantee of what you'll get from any of the photo sharing sites when you use a query term or just look for the top images.

The final feature I added was the ability to bring up the original content when the user selects an on-screen image. For example, when the user selects a RSS headline, the selected tile first moves to the forefront and stops scrolling. Then if the tile is selected again, a web browser is spawned to bring up the associated article.

In the Android world, the spawning of the browser or other external viewer is very easy and accomplished in just a couple of lines using the very flexible Intent subsystem. Once the user is done with the external content, the back button brings him or her right back to the app.

Once you've gotten close to finished with your app, you'll be ready to show it off to the world. To do that, you'll deploy it to the Android App Store.

App Store

From a developer's perspective, the Android App store is a breath of fresh air compared to Apple's iOS App store. Wrote a cool app? You can have it online and for sale in minutes with no prior approval required. Fix a bug in an existing app? Upload it and you're done. No waiting around for weeks to get an app approval gnome to look it over.

To me, it was very empowering to know that I was in control of my own destiny. I could have an idea, write an app and upload it for sale all on my own. To get into Apple's store, you'll be ponying up $100. For the Android store, it's $25. Of course there are other differences in the experience. From a user's point of view, Apple's store is a more polished and users know that some level of vetting has gone into the apps for sale.

Some reports are saying that iOS users buy more apps. But success can be had in the Android store as well. One developer reports that he made more money in the Android store than in the iOS store. But for most of us, making any substantial amount of money in either store is a long-shot.

Amazon also has an Android app store. It's a bit awkward to use, because users have to jump though an extra download step to get the app. Amazon's store is also moderated just like Apple's store so you have to get approval before your app will be listed.

To try it out, I signed up and got my app listed in a week or so. While checking out my entry one day I noticed that I had a "review" that was one star and along the lines of "Don't buy this app, It steals your credentials and spams your Twitter feeds!!!" What? Where in the world did that idea come from?

I was sure that that review would do wonders for my Amazon sales. Sigh. I was obviously doing nothing of the sort and there was no way for me to contact the issuer of the review, so I just added my own feedback denying it all. Then I contacted Amazon about the abusive review. To Amazon's credit, the bogus review was gone in a couple of days.

One thing this experience did was to make me go back and check the Twitter privileges I was asking for. I saw that I was at least asking for write permission. So I removed that privilege request so that there couldn't be any question.

Life in the Android store isn't all rosy for an app developer either. I wrote this app for fun and to learn about developing for a mobile platform. But I did put it up for sale at 99 cents. Just like the iOS store, it's very hard to get noticed among the thousands of new apps that show up every week.

Sales have been fairly low, and very few of the purchasers have bothered to rate the app and no one has left a review. Those who did rate it, gave it medium to low marks with no indication of why. It would be valuable to know if anyone was having problems or if somehow my description didn't match up to the experience. But I keep on plugging. I enjoy using the app myself on a day-to-day basis and hopefully the users I do have enjoy it too.

Figure 7: Video of the app in-action

Closing Thoughts

I don't have space in this article to cover the entire process of creating and debugging an app like this. But in summary of the process: It's hard work. Trying to get your app to be flexible, polished, bullet-proof and easy to use takes a lot of time and thought. I won't claim that I've succeeded yet. I continue to tweak, add features and fix bugs.

But developing for Android is a lot of fun, educational and empowering. As a software developer, I find it an exciting time in the industry. To have Linux-based, programmable, portable and powerful devices like those running Android around is really a kick.

And compared to developing for an iOS device? For me at least, developing for Android was much easier. I can use tools and a language that I am already familiar with. If I were a full-time app developer, I know that over time I'd get comfortable with the Xcode suite and Objective C. But I'm just an enthusiast doing this in the evenings and weekends, so the Android development tools are much easier to pick up.

As far as financial success, it's a long shot for either Android or iOS. But that wasn't my main purpose anyway. I'm just in this for the learning experience and the fun! If you'd like to check out my app, head on over to its web site where you can see some additional screen shots, documentation and a link so you can load it on your own phone.

Support Us!

If you like what we do and want to thank us, just buy something on Amazon. We'll get a small commission on anything you buy. Thanks!

Don't Miss These

  • 1
  • 2