I have an android app with one "home" or "main" activity that relies on fragments to accomplish several tasks. This data relies on information retrieved from a server (mine, and presumably a substantial amount by google maps).
I would like to structure my code such that several other activities (ie. preferences) can temporarily take focus before returning to the main activity.
Currently android destroys and recreates the main activity, which means bandwidth is wasted every time.
There are several notable intent flags which 'solve' this problem (Intent.FLAG_ACTIVITY_REORDER_TO_FRONT and Intent.FLAG_ACTIVITY_CLEAR_TOP), however they only appear to be useful when transitioning back to the main activity, which means I have to #override the system behaviour for both onKeyDown() and onBackPressed(). I would really prefer not to do this in case it causes other issues or eventually becomes deprecated.
Is this safe? Or is the better solution to force my application to create a serialization (savedInstanceState) of the main activity and all fragments anytime another activity temporarily takes the foreground?
Using saved instance state is the proper approach here. That will let you persist the information retrieved from the server when the activity gets re-created.
You only need to implement code to save / restore the instance state in the fragment or activity that holds the data. If you want to share that data across all your fragments, you can place it in the activity and add code to save the instance state of the activity. Then you can access the data that's stored in the activity from your fragments with ((MainActivity)getActivity()).getData().
For code to save and restore instance state, take a look at:
http://developer.android.com/training/basics/activity-lifecycle/recreating.html#SaveState
http://developer.android.com/training/basics/activity-lifecycle/recreating.html#RestoreState
If the data you need to persist is really large, you can use a retained fragment instead, as explained here:
http://developer.android.com/guide/topics/resources/runtime-changes.html#RetainingAnObject
Another trick for large data objects is to use a singleton class to store the data while the orientation change takes place.
Related
I'm trying to persist a list of objects across activities and fragments using the Singleton Design Pattern, but at certain times, I think when a process or activity gets destroyed by Android because of memory resources, the Singleton object is destroyed and my app crashes. I've come across this post:
How do I make Android's Singleton object persistent
and to quote:
I think a new top-level activity is made in a new process (reading
between the lines in
http://developer.android.com/reference/android/app/Activity.html#ProcessLifecycle).
Android is more likely to kill of the process of an Activity that
lives in the background, and that includes when a top-level activity
drops behind another.
I think a better solution might be to have your Singleton
transparently initialise itself if null, loading and saving any state
from disk if necessary (a pretty standard singleton paradigm). There's
no way to solve your problem with a single instance across the old and
new activities.
Is there no way to ensure data persistence across activities and fragments without having the potential of reinitializing the data from a database?
Shared Preferences is best for storing your application data. You can try and start here https://www.tutorialspoint.com/android/android_shared_preferences.htm
Option 1 : Shared Preferences
Option 2 : Using Global Constant
If you want data after application close you can go for Option 1
After application close no need data you can go for Option 2
I want to know how to fetch data from the local SQLite database in the background with a callback in the main thread. Say, the callback should be in a Fragment. And I want to avoid using the Room library. Currently I fetch the data in the UI thread using SQLiteHelper.
I have considered various options and understood that there is no silver bullet. For example:
I could have used AsyncTask, but it should be subclassed and in case the activity is destroyed before the task is finished the data is passed to the destroyed referenced activity. As a result - a memory leak. Although, I restrict the screen rotation that lowers the chances of the Activity destruction, should I keep neglecting using AsynkTask?
Another option is IntentService. In this way I can fetch data from SQLite in the background and use EventBus for a callback. However, seems like it is an overkill for such a task. The plus - easy implementation.
CursorLoader with ContentProvider is the third option. I believe this is what I need. However, I believe the code could be verbose. I havent used these classes and after reading miles of texts, still dont know how to implement them.
What option should I choose? Please, provide me with a guided code in case you have one.
Please correct me, if I am wrong in some statements.
I trying to make the app similar to Nissan Leaf Spy. This app receives data from bluetooth interface ELM 327. My goal is to collect data like:
Speed
Temperature
Power
Battery capacity
And some more data
And display them on real time chart using GraphView.
For one parameter is one chart in Activity. So there are at least as many Activities as parameters I need to display. My guess is to use
Android Services
to do work in background to co collect and save every data in different array via bluetooth. Of course when I change Activity to see another Activity the one that works will stop working and there will be no more real time.
The question is: is there any kind of 'superclass' that is always working or do I need to save this data using SQL? Or should I just use intent.putExtraString(key,value) and getIntent().getStringExtra(key). I will be grateful for your help!
About having different activities for different parameters, you need to have just one activity. You can have a graph and different ArrayLists with adapters for parameters and then use one of them to feed the graph according to the parameter selected say, from a Spinner.
To feed those ArrayLists is just as easy. You can have a Service running, for general data collection, with an AsyncTask inside it, which will keep the feed live for a selected parameter when the app is active and not in the background. The Service, by itself, can collect data in some sort of a buffer large enough to feed those graphs.
Remember, AsyncTasks are good for updating UI components without blocking the main thread.
EDIT: Look, if you have an activity (let's consider some other activity than main) where you're going to show the data or graph, you can have AsyncTask running as soon as you enter the activity(you can define a default parameter for a graph to be shown) or when you select from a drop down, giving you real-time data while you're on the activity.
The reason I am using AsyncTask for the live feed is that you can have different UI views and seamlessly integrate without any future problems and that it'd modularize Service into functionalities for serving Activity and would end when you close the app. The Service running in the background would primarily provide to a temp log file or be an InputStream source for AsyncTask when it runs after app launch or activity launch.
I'm confused regarding with some basic android development concepts, my question is not pointing at a particular code, thats why I dont include any.
Let's say that I have an activity inside of which I have a container in which I load a couple fragments (they are multiple instances of the same fragment), now the activity is populated, and inside one fragment I press a button that opens a new activity, it doesn't matter what may happen in that activity, the thing is that when I press a button it should take me back to the previos activity, I know that pressing the back button or using .finish(); will take me back to my already-populated activity, but I want to know, if that is the correct thing to do, or should I finish the activity as soon as i leave to the next one and when I want to go back create a new instance and repopulate it, if so, where should i store the variables?
Let's say that the fragments that I mentioned are "alarms" for an alarm application, and when I create it I call AlarmFragment newAlarm = new AlarmFragment(); and then I add that alarm to an arrayList in my alarms activity (java class) getListOfAlarms().add(getAlarmsAmount(), frag); which remains on the activity that has the fragment container, the question is, are these variables created in the right place? Because I am leaving them inside the activity itself right? What could happen if the activity is destroyed? I've been told that I should create an SQL database for storing those variables. I am not talking about long term saving but variables that I will be using at runtime
Can someone explain me these concepts a little bit? A link to a place where it is explained will be great too.
Your question seems like it has many parts.
In Part 1, this is what I think you are talking about:
1) how you decide to allow the user to get back to the first activity is really up to you. And 2) what you leave in the Back Stack is also up to you and what you want to define for the users' capabilities within your app. For example, if you want them to only be able to use a button that you define inside Activity 2 container, that is fine. However, you are not required to provide a button in Activity 2, and you are certainly allowed to use the Up Action in the App Bar for navigation. If I were you, I would read more about the Tasks and the Back Stack http://developer.android.com/guide/components/tasks-and-back-stack.html
You also mention this idea of having to "finish an Activity" with .finish(). I don't think that is usually necessary, but it is available to you if you want to use it based on what you decide for your app's logic (and what the user should and shouldn't be able to do).
With the Back button, Activity 1 will appear as if just initialized when you get back from Activity 2. Try it out. Also run some Log statements based on the simple diagram I provided and the Lifecycle "callbacks" (put these methods in your Activities and throw a Log statement in each to get a better sense of where you are in the Lifecycle) http://developer.android.com/guide/components/activities.html#Lifecycle
As for Part 2 of your question, I would try/set-up some of the above first, then start to experiment with a single variable to see what happens to it between Activities. There are a lot of "what ifs" to your question. You don't necessarily have to create a DB to store your variables, but that could certainly be an option. Take a look at the Developer Guide for most of the Data Storage options: http://developer.android.com/guide/topics/data/data-storage.html
If you are concerned about losing data when the Activity is destroyed, I might consider creating a database. Read the following for more info on recreating an Activity when you have gone elsewhere and are returning: http://developer.android.com/training/basics/activity-lifecycle/recreating.html In particular Saving Your Activity State: http://developer.android.com/training/basics/activity-lifecycle/recreating.html#SaveState
There's also an SO post on this: Saving Android Activity state using Save Instance State
I am mostly a beginner to android development, and I find myself using a lot of global variables to share data between functions within the same activity, Intra-activity communication . This is mostly because no one calls onCreate () from within the activity, so I can't return UI elements and data that might be edited latter in the activity.
In addition for inter-activity communication I find myself using Intent extras for small data and external classes with static variables to pass large data, image strings, around when an activity dies. I read here that the application context can also be used to maintain global variables,so this might be a solution, however this keeps the variable for Intra-activity communication alive even after it dies, which is unnecessary. In addition some of that data passed may not be needed all the time for all the activities.
That seems like poor practice, so my questions :
1)For inter-activity communication is a constant use of intent extras and static variables to pass data ok?
2) For Intra-activity communication what can I use instead of global variables to pass data between different functions that don't call each other but share some value and the value dies with the activity ? Is there a danger to such use of global variables ?
If this is too opinionated or abstract I'll close it.
1) Usage of intent is ok. As for global variables I do not think so. The values can be lost when your application would be recreated after android system decides to free some memory. Why not persist data in SharedPreferences or SQLite?
2) Fields (and classes) variable is a normal way to use (and pretty good practice for the cases like not using findViewById all the time). If you want to persist data between activity recreation why not to use provided by android framework (https://developer.android.com/training/basics/activity-lifecycle/recreating.html)?
Save the needed data (like item ids, values, etc) in bundle and restore them afterwards.
public void onSaveInstanceState(Bundle savedInstanceState) {
savedInstance.putInt(some_key,value);
}
and restore in onCreate or onRestoreInstanceState.