My little Android warehouse

Random thoughts about my experience as moonlight android developer.

MyDearSanta

This time, while PastTimer has not been released yet, I started an experiment with an old friend. We wanted not just to release another standalone app, but interact in some way with a backend.

The result is www.mydearsanta.info , a web based Christmas list, which comes together with and Android app https://market.android.com/details?id=com.smokingbytes.santas and an Iphone app (currently under the approval process) .

The backend was written using the Django framework, and the apps interact with it using a json based rest api.

A New App - Android Kitchen Timer

Pastimer is my 4th app. It’s a simple (but nice) Android Kitchen Timer based on barcode scanning.

I learned some things during my journey of android development, but this time I wanted to focus on user interface and ease of use.

As always, it starts as a simple idea, the you start putting some code in it, it’s “almost” working, and the difference between almost working and finished, is something like two months or more. I let it alone for more than two months.

However, now it almost ready to be released, and it will very soon.

The idea behind it is very simple.

You point the barcode, the app looks in its internal database, and if it does know the time associated, starts a timer. If it does not recognize the barcode, it prompts the user asking to put the data.

Sounds easy, doesn’t it? You can give a look at a couple of screenshots here Android Kitchen Timer

What I Have Been Working on.. Android Kitchen Timer

Apart from some rest, and reading some good books (like excellent Kent Beck’s Test Driven development by example, and “growing object-oriented software guided by tests”), I have been working on a new app in the last month or so.

A week end locked at home because my gf was ill, was a good excuse to start a deep programming session. The app I am about to release (well, to be honest it still lacks all the nice ui parts, it just look like a bunch of grey buttons thrown on the screen) solves (or at least tries to simplify) a problem I have every time I need to cook pasta.

Basically, if you need to cook some pasta (but this applies to every other boxed product), you need to put it in the boiling water and then look for the boiling time on the box, and set the timer with minutes and seconds on your phone.

With my app you simply point the camera to the barcode of the box, and it automatically start a countdown for the right amount of time. Of course some data entry is needed, and if the barcode is not in the internal storage, the user will be asked to fill the name of the pasta and the correct boiling time.

So, it’s a simplified timer for android, which should make easier and faster the countdown setting process.

I really hope to release it soon, if you are interested and you want to be notified when I will release it, just throw me an email at fedepaol gmail.com

Behind Activities: Android, Services, Background Operations and Threads

This time I want to share something I learned about working in background on android.

One of the biggest advantages of android over ios (or, at least, some ios version ago) is that your app is not sandboxed and can continue to live in background.

To perform background (not visible) work, all you need to know is how to use android services.

A service is a piece of an application that is allowed to be active even if the application is not in foreground anymore. The most commonly used example for describing a service is the music player, which need to continue to play music when your app is hidden by something else.

First of all, I want to remark a concept I had some problems with: a service does not have any relationship with threads! The service shares the main (ui) thread with the rest of the components of the app. This means that, if your app is in foreground AND you have a service active AND your service performs some time consuming operations, it will affect the responsivness of the gui (and you don’t want to disappoint your user).
So, even if you are now able to perform some background work, if you expect it to be heavy, please move it inside a thread (or an asynctask) hosted by the service.

Another advantage of bringing a service on board is that your application will gain priority over the other apps. Android prefers to kill processes that do not have active services. On the other hand, this means that you should use services carefully if you don’t want to drain your user’s battery. If you don’t need a service anymore, please kill it and restart it later (as pointed out from mark murphy in this old but interesting article: http://www.androidguys.com/2009/09/09/diamonds-are-forever-services-are-not/)

Said that, I am now going to list some typical service usage patterns

  • Listen and react to events from outside which need to be handled even if the application is not active (and maybe when the device is idle), such as location variation, accelerometer, incoming calls and so on
  • Tasks that need to be performed periodically, like polling a mail server every 15 minutes
  • Continuous tasks (like playing a song, or sampling the location with a very narrow interval) that need to be performed in background


I would say the first two are similar, and the third needs to be handled in a different way.


One shot tasks
If you need one shot tasks (like downloading your email), you could:

  1. start a service with an intent
  2. return START_NOT_STICKY in its onCommand callback
  3. start an AsyncTask to perform the heavy operations

    OR

you can use an IntentService. 

IntentServices are useful as much as they are little advertised.
If your service is an intentservice, it will be automatically hosted in its own thread. You can send it as many actions to be performed you want bundled in intents. They will be queued and handled one at a time.
You don’t even have to bother if you need to shut the service down. It will automatically shut down when you return from the onHandleIntent call. Much simple, isn’t it?

Here are some simple scenarios for using intent services:

  • Background operation triggered from user (such as a button): Just pack the command in an intent, and launch the service with the intent.
  • React to some broadcast event (such as some system broadcast event): Register a broadcast receiver in your manifest and then launch the intent service from its onReceive. You can’t handle long running operations in the broadcast receiver, there is a strict time limit in broadcast handling.
  • Perform periodic tasks: Use an alarm manager and make it launch your intent service. I also remind you that using setInexactRepeating in this case will help your app to save more resources.


Long running tasks

If you need to need to perform long, continuous background operations, you have no options, and you need a classic service, returning START_STICKY in its onCommand() method.
Again, remember that in this case you need to perform time consuming operations inside a thread or an asynctask, because the service shares the same thread with the gui.






The next time I will try to write down some more practical stuff on how to implement activities and services communication.


If I wasn’t clear enough, if you broke your phone trying to implement this advices, or if you think I’d better shoot in my foot than writing this ugly stuff in a very poor engRish, drop me an email fedepaol gmail.com .
If you liked this post, you can consider following me on twitter @fedepaol .


UPDATE: I am currently (23/01/2012) working on a library to be used to interact with a service using an intent service. In case you may be interested, you can find it here PostmanLib - Android webservice interaction


First 18 Days of Pegdroid

It’s already been 18 days, and it’s time to make some considerations.

For those who don’t know what pegdroid is, it’s a simple peg solitaire for android. I released it 18 days ago, it’s free and it’s basically ad-supported (but I don’t get much from that).

I integrated google analytics in my app, so I can get some help from the statistics I get every day. In the meanwhile, the market dashboard got updated and I also can see which kind of device are the most popular.

At the moment, it was downloaded 1022 times (android developer console), and something like 7000 boards were played. Don’t know why, but it looks like it’s quite popular in minneapolis :-) .

First, there was a huge (or so) number of accesses and downloads the first day (like 350 downloads), and then the number of downloads dropped considerably, as well as the number of accesses, that went from a considerable 1800, to an average of 300 accesses per day. I tried to tweet some news about the game, but I didn’t experience any noticeable effect.

I then released the first update, because some users said it would have been better to have the score expressed in terms of remaing pegs, than in terms of pegs already eaten.

With the second update I implemented the undo of the last move, which was a widely requested feature, and I fixed a sporadic crash some anonymous guy reported me. With this update (and not with the previous update) I had a spike in the download and access number, as you can see in the picture.



I am really curious on what drives the download number, at the moment I can only say that updates have a positive effect. The next move is to integrate some kind of social gaming platform (I am still evaluating)..

In any case, if you haven’t downloaded pegdroid yet, here you can find the link to the market:

Comments

Pharaviel
Ti lascio un piccolo commento per ringraziarti del fantastico lavoro che hai fatto con GeoTagger per android, sono un fotoamatore e apprezzo molto di poter usare le funzioni di iphoto senza dover comprare un costosissimo gps per la mia fotocamera!
DarĂ² volentieri uno sguardo a pegdroid visto che ogni tanto giochicchio con il telefono.

Ok basta sproloqui, grazie ancora!

PegDroid - Android Simple Game

I just released a new game. It’s (yet another) version of the popular solitaire game. I thought its name was “Chinese checkers”, but it looks like it’s most common name is “Peg”. Anyway, it didn’t take (too) much to develop it, I really enjoyed learning something about the powerful andengine framework, but I am still proceeding at a slow pace since I can work on android only after my daytime job.

I am releasing it with ads, but in any case I think I will update the sources on github very soon. Now it’s quite late and I’m afraid to make some mistake.

Good points: the framework and the assets. I think my favourite designer (yes, still my gf) has done a good job in drawing all the assets. Very far from what I would have been done alone.

Another thing I tried to include in this app is google analytics. I can see which are the most played boards, and who downloads my app. I must say I am pretty curious.

Next time I promise to post some technical stuff, for example how I handled andengine stuff in a more structured way in my new app.

I will end including the demo video of PegDroid down here:


Mobile Game Development

Another thing I always wanted to do was game programming. Moving objects and interacting with the game, as well as having fun with them, gives great satisfaction.
I think the fun part is that you have immediate feedback of what is happening, it’s just not like filling an edit text and pressing a button (or server side programming).

Given that I am spending much of my spare time in (trying to) learning mobile development, I tried to merge the two things, and I came across to andengine framework.

Andengine is an opensource framework for android game development, and it comes with a lot of nice features like physics and automatic scaling. I started developing my first game in January, and it’s a simple peg solitaire. It’s almost done but it still need to have some gui polishment (I mean I still need to have all the assets done :-) ), in any case it was a nice start. If anybody is interested, the sources are available under apache license on my github repo, which is http://github.com/fedepaol

Andengine is quite powerful, but it’s main weakness is its lack of documentation. However, if you are brave enough you can look at the sources, and there is a nice forum where the author and other people give a lot of support.

Next steps:

One thing I still need to learn very fast, is how to perform unit tests in a game development environment, I already found a couple of links but still need to read them.

Once I feel comfortable with TDD on games, the next step (but I am moving very slow) will be to try to implement some kind of multiplayer game (or at least a one vs one game) using all the appengine stuff I learned during my experiments.

I will be posting again when I officially release the peg solitaire game.

Why I Do Like Developing Mobile

Well, I stopped and started thinking what’s so cool about mobile development and mobile apps, and I would like to share my thoughts.

Before modern smartphones, most software was written to be consumed in desktop environment, where the user was sitting in front of his computer interacting with it.

Smartphones make now easy doing something new: interacting with the environment the user belongs to. That is what I think is the most exciting thing of mobile dev. You have a bunch of information from all different sensors like gps, camera, accelerometers (and now nfc with android), and then you can mix them all and build whatever comes into your mind.
If this is not enough, you can even implement some service and put it somewhere in the internet, make your app a client of it and interact with other client applications.

It now takes a reasonable amount of time to implement something that before was seen as science fiction or 007 gadgets, like video calls or augmented reality or location based service.

I don’t mean it couldn’t be done before, but it’s not an embedded stuff nieche with custom hardware and sensors anymore. With a 200$ smartphone and a 900$ laptop, you don’t need anything else to implement a location based service with photosharing, istant messaging and all the stuff you want. And the new model of distribution makes easy to reach the users as well.

This just from a mere technical point of view, you obviously need a good recepit to mix all the ingredients and come out with a successful product.

DroidAlone - Opensourced

I released DroidAlone on the market in the early summer. You can find a description at the following url DroidAlone - Missed call for Android
It is a paid app, and it costs something like 0.99 euros. It has been downloaded something like 150 times since then.

I also had some issues in choosing its name: at first it was homealone, but I was afraid to Mr Culkin knokin’ to my door for royalties, then it was phonealone but there was already one, and then it moved to DroidAlone. So what I suggest you is to look for your name after you choose it: you won’t have to change everything just only because you discover too late that somebody else chose the name before.

However, today I decided to release its source files on https://github.com/fedepaol/DroidAlone/

Why did I choose to do that? After all I spent some time working on it, and I think it’s a quite nice application.

Well, first of all, I must be honest. The money I am getting from it is not that much, and I don’t think releasing the sources will affect my sells in a negative way. Even if it gets more popular, it would be quite hard to stop piracy. Finally, this is not my primary job, so I don’t depend on it for living.


Apart from this, there are other reasons. One of them is that the only code I wrote and made public is the one from geotagger. It was my first experiment on android and with java as well. I think I got slightly better with droidalone, and I wanted to show it.

My android and java skills are still improving, but since I am now working with other people it will be hard to opensource the stuff I am working on now (and please remember I do android only outside my daytime job).

So, I really hope it may help somebody, it has some nice stuff in it, like sms and call handling, and mail sending.

So, enjoy. I’d really love to hear feedback..

Federico