Too bad you think this way about Eclipse. Eclise is a great development tool. Like any tool, however, there's learning curve to it. I am sure you would benefit from knowing your way around Eclipse as it has plugins for all the major languages and development environments.

JDE is on its way out by the way and while you can still use it and it is perfectly fine if that's what suits you. Just know that you are missing a lot.

Allow me to disagree with you that everything is so simple on BB. The scenario that you are describing could easily occur on BB as well I think.

- The user starts registration (sign up) process, the request is sent to the server and user looses connectivity and never gets a response from the server. Although on the server the request was processed and user was registered.
- Even with modal “Processing” dialog you can not prevent the user from restarting his phone via battery pull, or it can shut down since battery died, or it can shut down because the user dropped it etc, etc…

So to summarize, I think this problem is equally relevant to BB and most likely to any other client in this scenario (think of a web browser that looses connectivity just as BB did in my example).

So never mind on which platform you are working you will have this very problem.

Regarding Android and its life cycle management.
http://developer.android.com/guide/topics/funda...
Yes it is somewhat confusing since there are 7 notification methods any activity can receive, and with great power comes greater responsibility. Most of those methods however are to allow the developer to fail gracefully due to the system reclaiming resources or user interrupting the activity as you rightfully noted. The only overhead I see with it is that you are responsible to save the state of your application if the user leaves it for some reason because the system can kill the activity and then it will have to be started from scratch. I am with you on this, but to get a better system I guess you have to sacrifice something.

I hope I got what you were saying
The question that you raised is quite interesting and I will devote more thought to it… It would be probably interesting subject to do more research and write about.

Ok. Imagine such a case: a user is on some sort of “new user Activity”. User should input its login/pass and press “Register” button. On the button press we need to send a post request to a remote server that actually will create a new user in its DB. Based on the got responce from the server we need to inform the user about the result (success or failure (failure details)).

On BB the algorithm is pretty simple:
* push a non-cancellable by user progress popup screen “Processing…”;
* do the main job (send request/parse the response) under the popup;
* close the progress popup;
* display a cancellable by user popup with result message.

While doing this we are on the same Screen. It can not be killed by OS. Nothing can break the workflow. That's why it's simple.

On Android things change. Activity may be killed by OS (1) on configuration changes (that's how they call device orientation changes and hardware keyboard open/close actions) or (2) if Activity is not the one the user currenly works with (for instance, an incoming phone call puts your Activity in background, so it may be killed by OS (and life proves it really does)).

So, backing to the example, I still can not figure out what approach/algorithm should I use to produce bugless code. Android documentation says there's AsyncTask class that is a solution and there's a usage example of it – http://code.google.com/p/shelves/source/browse/... (note that UserTask class, it was then renamed to AsyncTask). They start the task, cancel on configuration changes and restore it again on Activity restore. But wait a minute, by the second rerun of the task the remote server could already have processed the request and created a user, so on task restore the user may get error message “username is already in use”! They cancel the task, because how to show a popup/dialog if there's no underlying Activity? So, on Android's Activity we should “syncronize” our actions (such as background task threads) with Activity lifecycle bearing in mind that users at any time may cause Activity to be destroyed. That's not easy. I would even say more – it's painful.

Probably there's some solution I'm just not aware of yet. If you could point me into the right direction I would be very happy.

Can you also please clarify what you mean when you say that it is much more complicated to deal with life cycle control.

Android ecosystem is very lively with a lot of web presence in a form of forums, tutorials, discussion boards etc…

The best place to start would be the http://developer.android.com good luck!

I have been developing for more than 2 decades, and I am experienced and fluent in more than 50 languages and platforms… but I have to admit, this sucker has me stumped. Is there a magic pill somewhere that will empower me to learn Android development? …or perhaps someone, somewhere, has a nice drag and drop RAD environment ready to go.

I will keep trying to muscle through it, but it just doesn't look too promising.
If any hot-shot developers care to teach this old dog new tricks, I would be eternally grateful… and I will definitely make it worth your time.