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.
Related
Currently I'am developing app which having a bad API. I have a situation where I have to use data received from network call in a activity, which is 2 steps away from the activity where I made the network call. In other word all the data necessary fill 3 activities comes on this one network call.
So I pass necessary data between activities using Intent Extra. It is not easy to maintain and It takes noticeable time to switch between activities.
I know one possible solution is to store data in database. and access those data from different activities. It feels like a bad practice because no use of those data after user pass 3rd screen.
Is there any better technique to handle this?
You can put all your network logic in the separate class, cache data in some variable and use it in your activities (you can use singleton class or injecting by dagger).
Also you can read about Clean Architecture and get some good practices from it.
If you don't want use anything from above, you can remove data from database after using and not store it forever. Or you can use SharedPreferences if your data is not complex.
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.
I have a MainActivity that fetches a large-ish amount of data from a web server using Retrofit. This data is shown in a recycler view.
Now, I want to have another activity which works on the exact same data set. What's the most efficient way to do this? Earlier I have done this using a static Controller that keeps track of the data, but I keep hearing a lot of critique about static containers like that. Passing the data in the intents is not optimal, since the data is rather complicated and there's so much of it.
Optimally, I'd like to be able to modify the data set in either of the activities so that the changes are reflected to the other activity as well.
I think you should consider 2 options (depending on the amount of data you would like to share, and the type of devices your app is suppose to run on)
You can extended the application class to include global data between your activities. You can read more about it here: http://www.helloandroid.com/tutorials/maintaining-global-application-state
You can use persistence storage (i.e. sqlite/file).
There are trade-offs for each approach. And which one will suit you best depends on your specific setup.
Just wondering what is a better practice to pass information between activites, adding it to a bundle or using a singleton class to store and access this data. I have used both in the past for various android side projects, but I am now working on an android project that is of much larger scale, so would prefer to do things right towards the beginning.
My application authenticates users and then will have to do various queries based on it's id. To minimize coupling between activities, I would think just adding the id to the bundle, and then letting each activity query for the information that it needs, would be the best bet; however to increase responsiveness, I was leaning towards using a singleton class to store persistent information, preventing more queries than need be.
Personally, I would create an extension of Application to store the state of your app and share data between the different activities. The Application acts as the context for your whole app and Android guarantees there will always only be one instance across your app. Hence it works similar to defining your own Singleton, but using Application will allow Android to take control of the life cycle of your shared data and basically do the memory management for you.
Here are some more details. If you go down this path, you can simply add any getter/setter (or other) method to your application extension to store/retrieve data and do operations on it. Especially the latter can become quite a pain to manage (and keep consistent) when using Bundles passed back and forth between activities. If would only use a Bundle if the data is needed in just one or two places that are neighbours in the activity flow and does not need any (complex) operations to be run on it.
The better way to go for you is to use SharedPreferences to keep userId you need to keep and reuse. Of course you can use singleton approach or even Application class, but the data will be lost after application is killed.
The only time I pass data between Activities via bunlde is if it's something that I won't need to access for a while(i.e the the resID of a resource I want to use only once in the calling activity, etc). I would also think the difference in responsiveness would be very minimal, so that shouldn't be of concern. I suggest the singleton approach
Passing bundles is a tedious job. You'll have to pass a bundle for every change in activity to make sure that the value is not lost, even if you're not using the value in the called activity.
Singleton pattern have some bad results. For example:From Main activity you call secondary activity. Phone call interrupted your work.After ending phone call Android is trying to bring secondary activity to screen. Here is my nightmare - many users complaint about exceptions - Google reported to me NULL pointers in my singleton. So you have to provide not only singleton, but all data inside singleton have to be as singleton too. This maked come very complicated :(
I have a Weather app with four Activities. The main/launcher activity is 'invisible' using...
android:theme="#android:style/Theme.Translucent.NoTitleBar"`
...and is simply used to do a few checks (whether this is a new install, whether a network connection is available etc) before firing off one of the other Activities. The other Activities are UI-oriented - two simply display weather data pulled from a website and the third to provide a location 'picker' so the user can choose which area to show the weather for.
However, all four activities make use of a WeatherHelper object which basically does everything from checking for available SD card storage to maintaining preferences and pulling/formatting website pages.
So, my question(s)...what is the best way to have one instance of WeatherHelper which can be used by multiple activities and where/how are best to create it in my case?
I've been an OO programmer for a lot of years but I'm very new to Android and the design concepts - I've read a lot on the Android Developers site over the past weeks but I've stalled trying to decide on this.
Any ideas gratefully received.
I would store shared information in you Application object. Subclass this and add any extra initialization and data there. You can get your application using getApplication() from your activity, which you can cast to your specialized version and access the shared data.
I would also avoid launching the special startup activity if possible and do the work in your Application's onCreate() override.
Well, your question has been answered, but it seems like it would be much simpler to instantiate your WeatherHelper object in the onCreate() of the Activity that has the launcher intent, and make the WeatherHelper static.