Until today I was really happy with the Android Market. But until now I just was a user of the Android Market. But what happened?
Today I opened a developer account for the Android Market. My plan was to offer a small little app in two versions: Free and paid. It's quite common in the Android Market and I have seen something like this many times in the Market.
I really wished that the Market had something similar to Handango where you can upload a free "demo" version and the "full version" that a paying customer gets together. Unfortunately this isn't possible!
And even worse: You even cannot have two apps that use the same name space. (the package attribute of the Manifest file). That means you cannot easily create a free and a paid version from the same code base.
There are already some ideas how to work around this but all of them are less than ideal.
See http://stackoverflow.com/questions/1222302/android-multiple-custom-versions-of-the-same-app and http://droidin.net/2009/05/13/android-multiapp/ for more about that.
2010-07-19
Design Pattern Oriented Design is a Bad Thing!
Recently I stumbled upon a post on dzone.com: When Design Patterns are Evil and I couldn't agree more.
We all know design patterns and we love them. They make it easier to talk about the design of our code and that's what I think they are good for.
But occasionally I had the joy of maintaining code that seemed to be build around design patterns completely. At first I was impressed (when reading the design documents). But when digging deeper into the code it became more and more obvious that thinking in patterns is a bad idea.
A pattern in my eyes is just a name for something that a good programmer should come up with when solving a particular problem even if he didn't knew about that pattern before. I often had this situation: Solving a problem by writing code and later recognizing that I used a specific pattern.
But trying to throw patterns on every problem you encounter will result in over complicated, bloated and over engineered code.
We all know design patterns and we love them. They make it easier to talk about the design of our code and that's what I think they are good for.
But occasionally I had the joy of maintaining code that seemed to be build around design patterns completely. At first I was impressed (when reading the design documents). But when digging deeper into the code it became more and more obvious that thinking in patterns is a bad idea.
A pattern in my eyes is just a name for something that a good programmer should come up with when solving a particular problem even if he didn't knew about that pattern before. I often had this situation: Solving a problem by writing code and later recognizing that I used a specific pattern.
But trying to throw patterns on every problem you encounter will result in over complicated, bloated and over engineered code.
Maybe it's some sort of uncertainty that leads developers to over use design patterns. They think: If I can refer to a pattern it can't be wrong.
Don't get me wrong: Design patterns are not a bad thing but over using them can be dangerous. As everything in life it's all about balance.
2010-05-29
Are Code Reviews just a waste of Time?
During the last 15 years I worked for a few different organisations of different sizes.
Some of them had more or less formal code reviews as part of their software development process. In my current job for example we have a very rigid code review process that says that every bit of code should get reviewed. But why?
I guess code reviews are considered as a way to improve code quality. It's believed to have a learning effect for less experienced developers as they have to review other's code and their code is reviewed and they should get valuable feedback on their code.
That's all nice in theory but my experience is different.
In a real world project it's unlikely that you have enough understanding of other parts of the code to do really useful code reviews. (I know collective code ownership is something that we should try to aspire for but again - I have still to see that.)
So most code reviews end up with advises like: add some JavaDoc there, don't forget to cleanup imports and format the code (Yes. I know what save actions are for. Thank you!)
All of this stuff (and much more) can be done easily by PMD, FindBugs and CheckStyle. Done properly by an continuous integration server it's automatic and easy. Additionally it's much easier to accept feedback like this from an automatic system than it's to accept from the JavaDoc Nazi next door.
The saved time can be invested into stuff that really improves the code. You could start to do pair programming for at least the important modules. That's really something that creates collective code ownership and makes it possible to have more than one person that really know what's going on inside these core parts. Additionally less experienced developer can learn from the other's and the experienced developers learn how the other's think and code.
But I'm still trying to get this into the heads of my coworkers and managers.
Some of them had more or less formal code reviews as part of their software development process. In my current job for example we have a very rigid code review process that says that every bit of code should get reviewed. But why?
I guess code reviews are considered as a way to improve code quality. It's believed to have a learning effect for less experienced developers as they have to review other's code and their code is reviewed and they should get valuable feedback on their code.
That's all nice in theory but my experience is different.
In a real world project it's unlikely that you have enough understanding of other parts of the code to do really useful code reviews. (I know collective code ownership is something that we should try to aspire for but again - I have still to see that.)
So most code reviews end up with advises like: add some JavaDoc there, don't forget to cleanup imports and format the code (Yes. I know what save actions are for. Thank you!)
All of this stuff (and much more) can be done easily by PMD, FindBugs and CheckStyle. Done properly by an continuous integration server it's automatic and easy. Additionally it's much easier to accept feedback like this from an automatic system than it's to accept from the JavaDoc Nazi next door.
The saved time can be invested into stuff that really improves the code. You could start to do pair programming for at least the important modules. That's really something that creates collective code ownership and makes it possible to have more than one person that really know what's going on inside these core parts. Additionally less experienced developer can learn from the other's and the experienced developers learn how the other's think and code.
But I'm still trying to get this into the heads of my coworkers and managers.
2010-05-08
My two favorite programming related books
There are a lot of programming related books available. Some are good, some are - well - not so good.
But there are two books that I really, really like.
The first one (my number one) is "Clean Code: A Handbook of Agile Software Craftsmanship".
There was nothing totally new in there for me but I personally agree with 99% of everything the author says. It's not a book that teaches you how to write code but it tells you how to write good code. My favorite statement is that software development is a craft, not a science and that's what I ever believed. The only problem was that it seemed that nobody else was thinking the same. But fortunately the craftsmanship thing is now quite popular and we all know by now that we should be proud of being a good craftsman. There clearly is a demand for computer science but software development is something totally different. So in my opinion: "software development != computer science". And this book helps you to become a good craftsman.
The other book is "Code Complete: A Practical Handbook of Software Construction".
I think it's much more low level than the other book. If "Clean Code" is about writing good code this book is just about writing code that actually works. It's a lot of stuff that everyone should already know but I think it's good to have a book like this. While you are reading the book you always think "Hey, I recall this one".
2010-04-26
Experiencing an API bug the hard way
We (my wife, my daughter and I) enjoy Geocaching a lot. It's no surprise that I am using my own (Android) application for that. It's far from complete and it's just for my personal use but last weekend we wanted to show our neighbors how much fun geocaching is and I started to enter the first coordinate into my app and .... got an error.
I entered a valid coordinate like "7:59,149" and the app told me it's invalid.
What happened?
The class android.location.Location#convert(String) is buggy. It's not a big thing but it's really annoying. In the end I just copied the method from the Android sources into my own class and changed the validation condition. So my app is working again.
But learning about this bug this way I will always remember it. (It was so embarrassing!)
I entered a valid coordinate like "7:59,149" and the app told me it's invalid.
What happened?
The class android.location.Location#convert(String) is buggy. It's not a big thing but it's really annoying. In the end I just copied the method from the Android sources into my own class and changed the validation condition. So my app is working again.
But learning about this bug this way I will always remember it. (It was so embarrassing!)
2010-01-31
Viewing DZone on the Android Browser
I really like my new job I started in January 2010 but the way to work takes a lot of time. I travel by train so I can use my G1 to surf the web and do stuff like that so the time isn't completly wasted.
One of the websites I really want to read is DZone.com. Unfortunately it doesn't look good on mobile browsers.
So I hacked a simple iframe to make it work (at least a little bit better) on my Android phone.
To access DZone from the mobile browser just open this link in your mobile browser:
http://www.mobile-j.de/dzone.html
It's not perfect but better than nothing. It might also work on other mobile browser but I haven't tested this.
One of the websites I really want to read is DZone.com. Unfortunately it doesn't look good on mobile browsers.
So I hacked a simple iframe to make it work (at least a little bit better) on my Android phone.
To access DZone from the mobile browser just open this link in your mobile browser:
http://www.mobile-j.de/dzone.html
It's not perfect but better than nothing. It might also work on other mobile browser but I haven't tested this.
2010-01-25
AlarmManager vs Task Killer
For my current private coding@home project I was looking at how to schedule alarms on Android.
I quickly realized that the AlamManager was what I was looking for. I followed one of the many resources found on the net and started to implement a simple test application. One of those pages explaining how to deal with AlarmManager and WakeLocks is http://www.androidguys.com/2009/04/02/wake-up-with-the-alarm/.
Everything was fine and it instantly worked. BUT! I wanted to see if it will also work when my app is stopped (e.g. when Android runs out of memory it will stop apps that are still running in the background). To make it easy I took one of those task killer apps you can find in the Android market. I killed my app after the alarm was set and ..... the alarm never got off.
I was really disappointed and was looking for a solution. I also had a look or two at the built-in Alarm Clock app. I did everything like it was done there. And still it wasn't working.
Then I tried what happens to the Alarm Clock when I create an alarm and kill the app. And what happened? Exactly the same. I couldn't believe what I had seen.
After some googling I found that the real problem wasn't the alarm stuff but the task killer itself. ( see http://groups.google.com/group/android-developers/browse_thread/thread/3f87972d1f99ee81?pli=1 )
I really wasn't aware that using a task killer on Android is so aggressive. By definition it means killing also the alarms registered by the app (and everything else).
Now I know better and don't use that task killer app so much as I did before because now I can imagine how much can go wrong when using those kind of apps. (And now I know why there is no such app preinstalled on the device.)
I quickly realized that the AlamManager was what I was looking for. I followed one of the many resources found on the net and started to implement a simple test application. One of those pages explaining how to deal with AlarmManager and WakeLocks is http://www.androidguys.com/2009/04/02/wake-up-with-the-alarm/.
Everything was fine and it instantly worked. BUT! I wanted to see if it will also work when my app is stopped (e.g. when Android runs out of memory it will stop apps that are still running in the background). To make it easy I took one of those task killer apps you can find in the Android market. I killed my app after the alarm was set and ..... the alarm never got off.
I was really disappointed and was looking for a solution. I also had a look or two at the built-in Alarm Clock app. I did everything like it was done there. And still it wasn't working.
Then I tried what happens to the Alarm Clock when I create an alarm and kill the app. And what happened? Exactly the same. I couldn't believe what I had seen.
After some googling I found that the real problem wasn't the alarm stuff but the task killer itself. ( see http://groups.google.com/group/android-developers/browse_thread/thread/3f87972d1f99ee81?pli=1 )
I really wasn't aware that using a task killer on Android is so aggressive. By definition it means killing also the alarms registered by the app (and everything else).
Now I know better and don't use that task killer app so much as I did before because now I can imagine how much can go wrong when using those kind of apps. (And now I know why there is no such app preinstalled on the device.)
Subscribe to:
Posts (Atom)
Posts
