Reducing Soft Barriers in Mobile Apps

I got the pleasure to listen to someone talk about mobile software development and one of the things he mentioned that stuck with me is "Reducing Soft Barriers to Adoption". So in keeping this in mind, I thought I would come up with some ideas to help reduce the soft barriers of SportsFlash.

1. Create as minimal clicks/presses to important screens where the data is targeted and minimal. In SportsFlash, one press from the home screen to see your leagues and then one click to see the team standings.
   
2. Use big fields and buttons to allow people to easily see the data they input, and use a touch screen with.


3. Give users access to community/social tools to help them learn from others. The message board is part of Version 1.0, with more to come.

Designing Personalization in Mobile Apps

People can sometimes have a very personable attachment to their mobile devices. Whether its how its decorated, adorned, configured, it's contact list, even the phone plan, each reflect in someway it's owner. So why not it's applications as well???

With SportsFlash we tried to do this through the use of personal touches like images galleries, and then allowing these galleries to be personalized for that specific user. What this means is that the source of the images used in the image galleries are defined by the user, so that SportsFlash not only keeps them up to date on their fantasy league teams, but also it's customized with the images of their favorite players, or even their vacation shots. Version 1.0 just put into place the personalization classes (i.e. define the source of the images in a class that allows the data structures to be modified). In Version 2.0, we will create interfaces to the personalization classes to allow these data structures (i.e. the array of image sources to revolve), to be defined by the user.

As more ideas like this come to light, the end goal is to make each application of SportsFlash have a personality reflective of their owner, much like the mobile device.

Mobile Apps New Social Community

One of the things I want SportsFlash to embrace is the intrinsic community available to it. We use mobile devices to connect and communicate with others, and for others to find us, so why shouldn't its applications take advantage of that. Web 2.0 can be characterized by many things, but one thing that has emerged is social networking. The ability to connect with friends, colleagues, people we know well, and those that maybe a few degrees of separation away to help us share pictures, look for jobs, spread news, collaborate ... etc. I believe SportsFlash offers the ability to evaluate it's social network of league members, identified by their phone number, to enable relevant information discovery, connecting players and their sports interests, ... etc using social network analysis and other approaches. Some of the things we want to do with SportsFlash to enable community include (but not limited to) the following:

• Limit the data on the phone to only store the leagues you belong too. For information about your teams standings, the players statistics, messages being shared, ... etc, the phone will connect with the community to view/share.
• Use message boards to communicate with the community, one to many broadcast communication.
• Develop services (i.e. alerts, SMS, GTalk, XMPP, ... etc) to push relevant information to your phone, utilizing the relationships you create with others in the SportsFlash community, and your interactions in the league.
• In Version 1.0, player stats will be updated, monitored and mediated by the SportsFlash user community. This way it spurs more interest in monitoring and playing with SportsFlash.

Another interesting aspect is that the content will be constantly changing, and the tone, mode, atmosphere of the SportsFlash community will also be constantly changing, in some cases, evolving. This is important, because the algorithms we use to create a relevancy model for our community could also use evolutionary computing algorithms to track how the model is changing in our network analysis.

One term that always comes to mind, Continuous partial attention. In the context of Gen Y, SportsFlash will help with continuous partial attention, at least in terms of our love affair of sports, by supplying a convenient way to participate in a fantasy sports league community when it's convenient for you, or when SportsFlash tells you something interesting is happening.

How do I code for Performance, Memory, ... etc in Mobile Apps

The following are just a list of running rules I'm comprising to help in developing mobile apps:

1. Limit object creation and references. The more objects your application creates, the more that has to manage. One suggestion is to use stack based variables instead of heap based member or object instances , especially when they are referenced numerous times. For example, if I have an object variable that I reference numerous times in a for loop, copy it to a local variable and use that instead in your loop.
2. Limit data packet size and processing. If your mobile app depends on data from an external source, try to retrieve it in as small packets as possible, and if the data can be pre-processed on the server before transmitting to the mobile app, take advantage of it. Also, if a packet is lost, it's easier to re-send a smaller packet, as opposed to a larger one encompassing all the data. These are practices we strived for in SportsFlash.
3. Utilize PowerManagement to power down the application when not in use.
4. Use threading to ensure that complex tasks, if they fail, don't crash the rest of your application.

Coding REST Web Services on Google Android

When looking at utilitizing a SOA architecture to support SportsFlash, I had to investigate Android's ability to work with web services. From Google Android forums, I was first pointed to KSoap2 (http://ksoap2.sourceforge.net/), with implementations described here:

• http://groups.google.com/group/android-developers/browse_thread/thread/9b246db7d612a6b5/44bb777f03c5c8ac?


• http://groups.google.com/group/android-developers/browse_thread/thread/9b246db7d612a6b5/0f75e1da6be54209?lnk=gst&q=soap#0f75e1da6be54209

However, I was a little concerned by some of the difficulties described here, and I wanted to look at REST based services, which I thought would create the simple, lightweight API to our database that we require. I credit the publication "Unlocking Android", by W.Frank Albleson, Charlie Collins, Robi Sen, and Robert Cooper and Professor Ron Czik of Boston University. Using the SAX XML Parser

(http://code.google.com/android/reference/org/xml/sax/XMLReader.html)
you can create a REST Web Service that returns xml (or JSON), which is parsed by SAX.

A template for usuage could look like this:


try {
URL url = new URL(this.query + position);
SAXParserFactory spf = SAXParserFactory.newInstance();
SAXParser sp = spf.newSAXParser();
XMLReader xr = sp.getXMLReader();
ObjectHandler handler = new ObjectHandler();
xr.setContentHandler(handler);
xr.parse(new InputSource(url.openStream()));
// after parsed, get record
r = handler.getRecord();
} catch (Exception e) {
Log.e(Constants.LOGTAG, " " + CLASSTAG, e);
}

where your ObjectHandler is a class that extends DefaultHandler (http://code.google.com/android/reference/org/xml/sax/helpers/DefaultHandler.html) where you override methods like startDocument(), startElement(), characters() ... etc to handle the reading and parsing of your xml stream from your REST Web Service.

My HeadAche with SVN and Tortoise (At Least till I Upgraded)

This post first came to mind after a 4 hr wrestling match with SVN and Tortoise to check in my hrs of hard work. After almost losing my work numerous times, I thought there has to be a better way. Now don't get me wrong, SVN and Tortoise on the surface are great tools, and you can't beat the price, but there something to be said for lost productivity.

So recently, I decided to read the annoying message that pops up everytime I started Tortoise, and it said I could update Tortoise to 1.5 (I was currently running 1.4). Now I've always been hesitant to upgrade software because you are always worried something that was previously working will now don't work (look at Vista for example). But after my recent overnight session with SVN and Tortoise, I thought what do I have to lose. As it turns out, so far so good. I still wish I could force certain updates as opposed to being dependent on Tortoise telling me that these files are commitable, or that the one in SVN is newer than the one I have. I come from using Borlands StarTeam for the past 5 years, and there are just times when the user knows best, and I wish the option to exercise that existed. Also, I don't like the fact that I always have to "Clean" my project, only to get back some incomprehensible message if I can't.

But upgrading Tortoise to 1.5 seems to be working out ... so far. So what have I learned?

1. Maybe it was more Tortoise and not SVN that I was having issues with.
2. Upgrading software can be a good thing, a great thing, sometimes.
3. Maybe that message appearing everytime I started Tortoise wasn't so annoying after all :)

As far as free source control tools, Tortoise and SVN are by far the best products on the market, but if you are running into any problems, make sure you have the latest version.

Building Mobile Applications for the First Time

I know when I started down this path, having developed desktop and web applications for the last 10 years, I started to question whether what I was doing was right for mobile apps? I looked all over, looking for resources to help give me an overview of what someone has to design for when building mobile apps, when I came to realize that Google had their mobile application design philosophy on their home page! Recommend this as a good read for anyone starting out on mobile application development:

http://code.google.com/android/toolbox/philosophy.html

Programming Headache - The Emulator

Don't get me wrong, lacking a real device, the emulator is pretty sweet, when it finally comes up and works!!! But if you are programming on a laptop, may I suggest that unless it's the most powerful laptop on the market, your programming experience is probably best on a desktop. My laptop is no slouch, at 2GHz and 1 GB of Ram, it's pretty decent, but it just doesn't run as well on comparable desktops. I'm sure there are exceptions out there, but that has been my experience.
On the positive side, using Google Code as a home for this project is working out really well. I like all the features it provides, all in one place, and the fact that it's free isn't too bad either.

Mobile Device Programming Lesson 1 - It's a Mobile Device Stupid

Okay, so we started getting our hands a little dirty with this project of ours and I've come to realize 2 things (for now):

1. Phones don't have much real estate, both in terms of screen size, keyboard, ... etc. The entire user experience is different, and you have to really put yourself in the user's mindset. This means that you can't have complicated and overly busy user UIs. The layout should be simple and clean. Also, the UI should be transition based. What I mean here is that in order to do something (like build a fantasy league team), don't try to have everything on one screen, the process should be like a wizard, guiding you through the process and allowing each process to be only a few button presses or clicks. That way the user isn't forced to scroll or navigate around using only their touch pad or D-pad. Of course, this is easier said than done.
2. Your resources are limited. CPU, memory, battery life, and bandwidth. My first immediate realization of this, is the fact that the data I send to my mobile device is best handled if it's little pieces at a time, since network connectivity on a moving device is always subject to lost packets from losing connectivity. It also helps with suggestion 1, if I have a transition based UI/experience, then I don't have to send a lot of data for each request, just enough to satisfy the small step the user is currently undertaking.
3. If you come from programming on the web, certain controls like Spinner don't operate like select boxes. For example, Spinners (and most UI controls), have only one data value associated with it (i.e. the text is displays), and don't have ability to store secondary value components (i.e. name/value pairs like that in select/option boxes).

Motivation for SportsFlash

So how did I come to deciding that the first mobile application I would build would be for fantasy sports leagues? I came to this idea first by looking at what a mobile device essentially are, and I thought to myself that one thing that makes mobile devices unique is that its a device that you carry around with you, and it allows you to connect with your friends and family. So the social networking aspect is available to applications on mobile devices. Then the question was what online community can I make available on mobile devices, and sports came to mind. Sports fans are a passionate group, and being able to stay connected and participate in a sporting community from the convenience of your phone seemed like it would be appealing. Sports + social networking then lead to sports fantasy leagues, a community of sports fans communicating and competing with each other. SportsFlash was born.
The name "SportsFlash" came about accidentally. Desperate for a name to call this thing, I started to first think what I wanted to create, a mission statement so to speak. I wanted this thing to eventually be all encompassing with regards to sports, using the features mobile devices had to offer. Initially it would be for managing and/or monitoring your sports fantasy leagues, but eventually it could be used to connect and talk smack with other sports fans in your contact list, use location based services and GPS to find the closest sports bar, sports venue, and use the community aspect to allow sports fans to share sports trivia, suggestions on the best place to park at your teams sports areana... skies the limit. I wanted this application to be everything sports, at least as much as can be on a mobile device. But I still needed a name, then I thought of flash memory (don't ask me how that came to mind, I think I was watching something on the history channel at the time), and I thought of sports living on flash memory on your mobile device, hence ... SportsFlash. Then I thought about the relevancy to NewFlash, and the idea that people would receive alerts/SMS messages about their league, players, scores ... etc, and SportsFlash just seemed like a good fit.
As far as licensing, I choose GPL, because being that this is starting from an academic project, I believe my biggest interest in this project is learning from it, and using the open source community to learn and continue to learn from this project. So I want the ability to continue to learn, and not have anyone’s ingenuity in the future not be part of this project for everyone to learn and benefit from.
So here we are, building a sports application for mobile devices, using Google's Android platform. Should be an interesting ride!