Need help making architectural design decisions for an Android app

Question

Situation

I'm a newcomer to the Android world. I'm starting a new project to write an Android app that sends and receives SMS messages and is in sync with a web server. (I'll describe the app later)

I first tried to write the app with SL4A and python, but it had lot's of bugs (e.g sending long SMS messages resulted in a NullPointerException!)

Android's framework in really complicated (at least for me). You have Activities, Services, Receivers, AsyncTask, Intent and so on. I'm really confused right now and don't know the right way to tackle this problem.

Problem

There is a web server and a mobile phone.

Web server knows all the logic. It knows what SMS messages should be sent and what shall be done if the mobile phone receives a message. So the mobile phone communicates with the server through HTTP.

Sending messages

The phone should pull information about what messages it should send every 30 seconds.

• If there exists any unsent messages, the server will respond with a JSON object.
• The mobile will then send each message and tell the server if the message was successfully sent.
• It is also nice to have a log of what is going on, (what messages was sent, what responses did the phone get from the server) on a UI element on the phone.

Receiving messages

When the phone receives a SMS message:

• It should tell the server
• It should show log on screen

Question

Can you suggest a good architecture for this problem?

Should I create Services?

Should I create AsyncTasks?

...

• rciovati: I would suggest you to use C2DM, so your server pushes to the phones that there are unsent messages instead of letting the phone polling the server every 30secs.

Answer 1

Periodic requests to web server are best served with broacast receiver / periodic alarms ( 30 seconds is OK, in case you have power supply otherwise consider longer update interwals )

To receive SMS you can also use broadcast receiver ( as system will broadcast intent on incoming SMS message )

Overall state can be kept in some singleton java object, and consider persistent storage of state ( write through, as you application can be killed at any time by OS )

Log what going os is either done via standart logging facilities, and some activity to present user with current state )

Answer 2

Always hard to answer "what's the best architecture for", but here goes.

The SMS/server functionality sounds like a job for a service since it's long running.

You'll probably also end up coding an activity or a set of activities for configuration and/or monitoring the service.

• Yasser Souri: My question is "Can you suggest a good architecture for this problem?", anything that works it good for me. That's because I can't make anything that works now!
• Joachim Isaksson: Well, the above works and should be pretty straight forward to implement, I don't think the architecture needs to be more complicated than that, a service and an activity or two.
• Joachim Isaksson: If you have any questions regarding to how to implement it, I'd need more concrete questions, preferably summed up in a new stack overflow question :)