Develop Reference

What is the best way to pass data across multiple activities

I have an application requiring the user to fill a form in order to create a Route. This Route requires the user to create at least one Step, and a Riddle linked to the step. The user can create a Route with many Steps and Riddles.
So I have 3 activities (CreateCustomRouteActivity,CreateCustomStepActivity,CreateCustomRiddleActivity), each one composed of a form with differents fields corresponding to the object's properties.
I don't want the user to be able to create a Step without creating a Riddle, and I don't want him to create a Step and a Riddle without linking it to a Route
In the last activity, there's a button to validate and create the objects.
What is the best way to pass these data across the 3 activities? Should I use Parcelable interface? Should I use a bundle of extras in intents? Should i change the way i'm approaching it?

It looks like a wizard pattern to me. I'd consider the following:
If your data is small, using Parcelable sounds like a good idea. It will be executed on the main thread so if you have a lot of data to parcel, that will block the UI.
I'd also consider implementing those 3 screens as fragments, you can have that data saved in the activity. You will still have to parcel it for configuration changes (rotation of the device for example)
You can store the data in a singleton object that won't get removed across configuration changes.

Two API's inter connection is possible in android?

if save button clicked the selected values should be saved in first api.then back to product add to cart page, before selected values available in that page.is it possible in e-Commerce android mobile apps.

Okay. I think you mean "how to pass data between two activities".
Activities are java classes, but you usually don't use them via constructor. Instead of that, we use what we call an intent: a generic builder which allows us to send zero or many arguments to the activity class, using what we call a Bundle, a datatype very similar to a Map. So, to communicate the first activity with the second, you can add the desired data to a Bundle, add that to the intent, and then, in the second activity, take the data.
Now, for this kind of fluxes, you perfectly can, and should, have a separate data storage layer which all activities can consult. And you can use compound views or fragments to avoid loading different activities for trivial tasks.
The data storage layer advice also works if you wish to combine several remote responses into one. Just make all the network communication in a separate layer, then store the results and provide the answers to the views (activities). Remember, apps are not webpages, and people expect them to work even if the internet connection fails.

Android efficient way to handle multiple lists

My application allows users to chat with friends (like skype or whatsapp), so I have an Activity for displaying a "conversation" (a list).
The user can change from one conversation to another.
So, the problem is changing from one list to another, or "updating" the whole list of messages.
What is the best way to do that? (performance and memory)
- Remove all elements from the list and add the new messages?
- Use multiple ListViews and Adapters?
...
Thanks!

I'd say it all depends on how you're storing the messages, and a lot of other parameters revolving around that.
However, I would probably cache the messages locally so that when the user selects a new conversation, they first get the to see the old messages while loading the new ones. One ListView, one ListAdapter of some sort and a List that I clear out when switching between conversations.
That might not be the most optimal approach, but that's how I'd do it in the given scenario.

How to implement multiple screens within an App

I am currently working on an Android App which has different service dimensions, such as " service order", "route planning", "photo gallery" and a central login.
so far i implemented each "screen" (and by screen i mean actually the layout of a screen) as a seperate class, which loads a specific layout and handles all listeners and core functionalities such as calling webservices in a thread, receiving answers etc.
I am not quite sure if this is the best way to implemnt mulitiple layout-screens.
The Android dev guideline proposes to use single activities for each "screen layout". However I doubt that this is the most effective way of doing things. Since i need information for each "layout" which are retrieved by the central login (here: a user object). Since an activity (as far as i understand) is a seperate thread, the passing and retrieving of information seems not very practical.
I would like to get your oppinions/feedback on that and thanks for any hint or tip.
So far my structure looks like :
Activity
loads login layout (res/layout/login.xml with setlContentView)
depending on buttonclick other resources are loaded and initialized (means listeners are added etc.)
Greets
Peter

The dev guidelines recommend that for a reason. It IS the most effective way of doing things. You may complain about having to store your data so it can be passed along from activity to activity, but guess what? You're developing an app for a phone! At any point in time, the phone could ring, forcing the user to switch away from your app. Or the user could just choose to temporarily look at a different app. If your app goes back to square one after switching back and lost all data, the user will be understandably angry.

Don't know if this would be suitable for your app, but another option could be to split off the core data handling into a Service, and have your app be just a UI frontend which communicates with that service.

Android App with multiple views - Best Practices?

I am new to developing for android. I have a question regarding some best practices. My app is like a dashboard from which multiple different "sub-activities" can be started and done.
I am wondering what is the best way to structure the app. One way is to have different layouts and load and unload them appropriately. The other is to start new activities using intents. At least this is what i have gathered from what i have read.
What in your opinion is the best way to go.
Thanks

I've found in my applications that each Activity is generally responsible for a single UI view.
So rather than loading and unloading different layouts, which can potentially get quite messy, it is better to separate each sub-activity into its own Activity class and use explicit intents (intents that name the target activity explicitly rather than relying on an intent filter) to move between them.

The decision you have to make is whether or not your activities should be tightly or loosely coupled. Loading and unloading the activity is typically appropriate from within your own app. Using intents is appropriate when you need to open an activity that you may or may not know the specifics of. For example, you would open another activity from your main menu (assuming you have one) directly. Then later, let's say you need to open up an address with a map, you would use an intent, because you don't really know the SPECIFIC activity to open. Secondly, using intents are best for when there are multiple activities that could do the same function, such as opening a URL in a browser.
So in summary:
Open Directly (Loading a new view or using Intent specifying the Component Name)
Tightly coupled
Know specifics of the Activity to load
Open Indirectly (Intent specifying the category of Activities that can handle it)
Don't necessarily know the specifics of the Activity beyond that it can perform some action that has been advertised.
There are multiple Activities that can perform the desired action, and you want the user to be able to choose for themselves which Activity to use.

While Intents may be a little extra work, I'd recommend using them, if you don't directly need to pass large blocks of data back and forth between the two.
If you just need to pass information TO each of the sub-programs, then you can easily do that with putExtra(String key, Bundle values);
By using intents, you spend a little time now in order to have a lot of flexibility later. You can start intents from different points, so you'd not need to write new code if one of your sub-applications wanted to start a different one, or you wanted a certain filetype opened with a file manager to open one of your sub-programs.