I am having an issue in ViewPagerwith Tabshaving Fragments. I have my Home Activity that has a ViewPager with Tabs. For each Tab there is a Fragment. There are 3 sets of data coming from service when we start the application. The requirement is when I do changes for these sets of data in some other activities, I should be able to see the changes in the Home Activity, that means the service calls are to be done again in each of these Fragments, which is why I am doing all this part in onResume().
Required Output is :
When coming back to HomeActivity(that has the tabs) from another child activity, the service calls should be done.
When hitting on Load More button in any of the tab, the service call associated with that fragment or Tab should be done.
When moving between the Tabs, service calls should not be done, instead the data has to be loaded from Database.
Current Output is :
Since I kept all the service calls for those Tabs in onResume() of the associated Fragment, the first and second requirement is met.
When it comes to third requirement, the output is same as the first one i.e., its making service calls which should not happen.
Problem : How to identify if user is moving between the Tabs or if he is coming from child activity. This service calls happening while moving between Tabs is causing performance issues. Please help me with this, I have no idea about how to proceed to overcome this performance issue. Thanks.
Related
I'm pretty new to android development and was reading about fragments and their profits, but reading about fragment's lifecycle, I understood that "All fragments will be created when the host activity is created, All goes to start state when the host activity goes to start state and ..." , in return when working with multiple activities, each start independently.
now the question I came with is that :
Due to fragment's lifecycle behavioral, would it cause a big delay at the starting of an app when too many fragments (let's say more that 20) exist in the activity?
Is it suggested to use single activity app when the app has a complex structure which leads to creation of multiple fragments?
After some test and logging I realized that in special case of using Navigation, not all the fragments are loaded at the same time but only those are required, for example in my case I do only have one fragment which is handled by a navigation, then when the activity runs only the Home Fragment is created, started and resumed not any other fragments, so not only this doesn't cause delay but it increase overall app performance as fragments are much less heavier than activities . So I suggest using Single Activity App along with navigation
I'm developing an android app that is going to be used on a information screen. This app contains 5 (weather, next run, opening hours, etc...) activities, the plan is to loop through these activities with a timeinterval. So it starts with first activity, sleeps for like 5 seconds and then jump to next activity, and when it comes to the last activity, it should start in the front again.
What is the best solution to create a navigation system like this? Have Android some special features for things like this, or is the default startActivity() the only way?
And there is a little twist with this, some of the activities needs to retrive data from external sources by HTTP. So the activities must be done with data-query before it starts the activity.
You use startActivity to swap between activities. After you are finished with an activity, remember to call finish() - otherwise there will be a lot of instances of the same activity.
But if you want something like an information screen, you could use a single activity but use Fragments. That way you simply inflate a single fragment, and keep a timer to swap between them. You can still show the same content, but there are some differences between activity and fragment in inflating and finding the views by id.
I have an App with 2 activities A -> B. From B the user can update data being displayed by A, so I want A to show fresh data when the user navigates back (actually not so simple, some network involved so data can be updated at any time).
The activities are listening to ddbb changes so the views can be updated when data changes. Problem is data can change while activities are in background, so I am not sure when and how i should listen for changes. I can think of two approaches:
Listen for changes during the whole Activity lifecycle (onCreate - onDestroy) and just update the views when the data changes. This will update views from background activities.
Listen for changes only when the Activity is being active or displayed (between onStart/onStop or onResume/onPause) and force a view update every time the activity comes to the foreground (since changes might have happened while activity wasn't listening).
Mixed approaches; keep the listeners the whole lifecycle but only update views when activity comes to foreground.
Im not sure which is the correct way to handle data observing while in background.
Option 2 sounds more reasonable, but having to update the views when the activity comes to foreground may lead to UI lag right when the user starts interacting with the activity.
Option 1 will cause a lot of updates every time data is updated.
Thoughts on this?
You can choose any of the three options that suits your particular use case. Though I will say that the conventional use is with start/stop. onStart says that the activity is visible to the user in some way (either fully or partially) and onStop says that the activity is definitely not visible. So if you don't care to update the UI while the activity is not showing at all, use these lifecycle states.
You just may need to be prepared to capture data that you may have missed while the activity was stopped before it gets started again (for example, if the user pressed the home button, then came back to the activity via the task switcher. So performing your query again and rebuilding the contents of views from scratch may be necessary.
I am having an app which is retrieving data in the main activity and sending an event to all fragments as soon as it is available. So for the first start it looks like this:
App starts (fragments are initialising in the background) -> feed download -> notification sent to fragments -> fragments initialise UI
Everything's fine so far. BUT, what if I am resuming the app. The data will be still cached, so i will send the event immediately on app resume, and therefore it can happen that my fragments are not even ready for receiving the event -> no fragment UI update!
Or the event is triggered and received in the fragment, but the fragment is not ready for the UI update, cause it still hasn't inflated the layout -> NullpointerException
Or the fragment receives the event, but is not attached to the activity anymore -> another Exception.
There are ways to deal with single issues, but overall it is complicating the architecture a lot.
Somehow I tried a lot of things (playing around with Otto bus) but somehow I can't find any architecture which is working for making a central datasource available to all activities and fragments in the app.
How do you supply your fragments with data if you don't want to use bundles?
First of all a Fragment should be independent from other parts of an app. Moreover it shouldn't know parent activity: getActivity method should return just an Activity which could be casted to some interface.
an Activity shouldn't be a "data downloader". Basically activity is a View which receives various system and user events and displays particular state. For instance when the system creates activity it calls method 'onCreate' where activity should create/arrange fragments and views.
there is should be some manager or controller(call it as you wish) which knows where and how to get data for views. For instance if there is no internet connection it loads data from local database otherwise it makes network request.
So roughly speaking flow should look like this:
fragment(or activity) has reference to the DataManager. The fragment subscribes on FeedDataEvent in the onResume method. When fragment wants(onResume method for example) to show some data to the user it calls DataManager.loadFeed() and displays to the user "loading..."
DataManager checks if there is Task which is loading data from network. If there is no such fast it starts it.
When data is downloaded DataManager emits FeedDataEvent.
If the fragment is still visible it receives that event and shows data. If the user left the app fragment unsubscribed(in the onStop method) from FeedEventData and will not receive that event.
There is subtle thing with requests caching(making network request on every onResume is not very good idea) but it depends on particular app.
PS Almost all this things are implemented in RoboSpice and some other libraries.
I have a reservation wizard in android, when i say wizard i mean i have multiple activities (meaning screens) that are passed from one to another until booking is complete. in each step of the way my info may be invalid and so ill have to back track 2-3 activities and start all over, all the activities i back tracked should be destroyed, they may need to invalidate a singleton data container that they filled with their data.
I thought of 2 ways to do this:
start all activities related to the wizard with startActivityForResult() so i get notification when an activity is finished and with which error code (finished OK or error occurred) and act accordingly (for instance: if in the middle an activity fails it will return failed and the previous one will return failed as well until i get to the wizard's first activity where i either declare the error with a dialog or show the 'thank you' screen.)
I can send an react on intents with certain parameters so i have a 'close and clean' intent message that close down the previous activity etc...
which way is better, any other interesting\efficient way to do this ?
I Got a hint that got me thinking in a different direction:
use an invisible Activity, or alternatively , a local service,that is the 'brains' that known on each turn of the way what action is to be taken. to remove a complete stack of unneeded activities i should use the FLAG_ACTIVITY_CLEAR_TOP on the bottom most activity i want to use next.
Another options is to enclose all
the activities i want to play with
their pposition on the stack inside
an ActivityGroup Object which keeps
all activities alive (like in Tab)
and on the stack, but you control
which one is displayed and which is
not. the activity group will contain
the state machine logic regarding
which Actvity should not be
displayed and which should be
disposed.