More Android apps

Now that I'm a sleep away from handing in my Mobile Applications Development assignment, I'm looking for more project ideas. I want to try doing apps that haven't been done yet or, if there are similar ones out there, haven't been done well. Previously, I was looking through the Android Market app reviews and picking out those that were rated 3 stars or less and seeing what the users thought could be done better.
I found a couple of things that I wanted to try in an Android Community forum post. In the past I've just put together a series of controls and not really done anything to make them look prettier. This time around, I need to try and put as much effort into the aesthetics as the back-end code.

Run the program and see if it crashes

I don't have a lot of patience for constructing test cases when it comes to testing my code's functionality. When it comes to GUI-oriented applications, my preference is to run the program and see if it crashes (or behaves in some way contrary to what I had intended). At which point, I would go to whichever section of code is most likely the offending code and get trigger-happy with the logging statements.
This may not be the most effective debugging method for some people, but it has largely worked for debugging my Android apps. "Largely worked" because every now and then I'd have a bit of code that looks like it would  work in the way I wanted it to, but doesn't.

Improvements in debugging?

Is it a sign that you're becoming a better programmer when you notice that you're relying more on error logging to tell you what's wrong with your code, instead of trying to brute force a solution and raging about it when you can't figure it out?

I've only ever encountered one error logging framework before: log4net. I started using it at work when the team wanted to convert the their old error logging framework over. To be fair, log4net was a bit too complex for my liking.

I only started to take error logging a little more seriously when I started learning Android development. I started doing databases a few weeks into Mobile Applications Development - we weren't scheduled to learn it until week 5. It only when I hit a snag in incorporating a database into the class exercise for that week, that I finally began to see the value in using error logging.

Android Dev Update

So I finally fixed the problem I had with my Buttons interferring with the ContextMenu, thanks to a useful tip from one of my classmates. This is what my finished tally counter looks like. It may to be the prettiest thing, but it does what I want it to do.

At the moment I'm trying to make a tape calculator. I had a spot of trouble settling on a keypad layout. Should I just have the basic arithmetic keys or should I include keys for getting percentages, parentheses (for grouped operations) and square roots? In the end, I settled for the basic arithmetic format.

Error logging

It was only recently that I started to take the whole debugging process a little more seriously.
Before that, I used to brute force solutions to my programming woes. This wasn't exactly the best approach, in hindsight.
Maybe it had something to do with the Mobile Apps Development tutor nagging us about using logging to check that our code works.
That leads to the question of: what is the most effective approach to error logging?
Getting trigger-happy with the logging statements? Or just putting them where the code looks like it needs to be monitored?
My personal approach was to only put the statements where I thought the code looked like it needed to be watched.
For me, logging statements tell me more about a piece of code than setting breakpoints and stepping through the dodgy code.

Programming Problem: Android ListView's ContextMenu isn't being registered

My pet programming project of the moment is a tally counter. Not the sort where you can only count one type of thing at a time and can't remember what you were counting and when you last updated it. But one where you can have multiple counters on the go at the same time, each with a meaningful description and, eventually, a timestamp indicating when it was last updated.
Ok. So you're probably asking why I didn't download one from the Android Market... right?
The answer to that is that making a tally counter was one of my original choices for my final assignment for Mobile Applications Development. But it got vetoed in favour of another slightly more complex one. And I wasn't going to start serious work on the tally counter now if I was going to make it for said assignment...
So I got to the point where I was able to add items dynamically to the ListView and each individual counter was incrementing and decrementing perfectly (verified through copious amounts of logging statements). The only thing that I wanted it to do, but it wasn't doing, was to show the ContextMenu when I long-pressed an item in the list.
My first port of call, as with previous programming problems, was 'all-knowing' Google. After trying several approaches to registering the ContextMenu for the ListView and then inflating the ContextMenu, I was stumped. For anyone who is interested, below is a compilation of the approaches that I tried.

Registering the context menu
registerForContextMenu(getListView());
---------------------------------------
ListView list = (ListView)findViewById(android.R.id.list);
registerForContextMenu(list);


Creating the ContextMenu
menu.add(groupId,itemId,order,title);
---------------------------------------
MenuInflater inflater = getMenuInflater();
inflater.inflate(menuId,menu);

Mobile Applications Development Week 4: ListViews and ViewFlippers

Ok. So in this week's class exercise, we had to continue working on the task manager. The new features we were supposed to have added by the end of the class included the ability to confirm deleting all of the tasks in the task list, send any given task in a text message and redesign the GUI so that it made use of the ViewFlipper widget.
The confirm dialog was reasonably easy. For this particular dialog, we only needed two buttons - one to delete all of the tasks and another to cancel the deletion process.
The SMS part worked at the beginning, when I sent all of the tasks in the text message. I had to run 2 emulators at the same time to do this. I also had to add the "android.permission.SEND_SMS" uses permission to the manifest file. Not to do so caused the compiler to throw a very lovely error.
The last part, switching to the ViewFlipper, was an interesting experience. After digging around online, I tried nesting the ListView inside the ViewFlipper inside my main.xml. The thinking being, I could use the ViewFlipper to navigate through the ListView items (my tasks) by using the "Next" and "Previous" buttons. So I ran my app and added a few dummy items. Lo and behold, the items were being displayed as normal ListView items. This isn't what I wanted! Next I tried moving the ViewFlipper to my task item xml file and wiring things up via the task item's java class. This only made my app crash. So it was back to the main.xml file for the ViewFlipper.
Sigh. With luck this baby will be in the bag by the time I head to bed tomorrow night.
But to owe the truth, I would much rather being working on my pet projects right now.

Musings of a novice Android developer

On the train to uni at the moment. I realised yesterday that I'd have to juggle 3 group-work assignments on top of work and everything else. *sigh* Today I have a 3 hour Mobile Applications Development class. I'm not entirely sure of what I should do for my assignment: a simple tool or a more elaborate database-based app? The problem is that when it comes to big systems, I get overwhelmed quite easily and everything goes messy. But if I could pull it off, it would be quite awesome. If I go with the tool, I'd have to add some features to it that would make it 'shinier'.