I've been reading the tutorials etc. and I'm now implementing Shared Preferences to save variables between screens. In my app the user moves to and from items in a ListView widget, and may return to a particular screen, I need to save their activity there in case of that.
In Java on Android you would save to sharePrefs when the user exits an activity (screen) because it's a slow operation and saving each time a variable changes is not performant.
Is there a best practice time to save in flutter? How do you know a user is exiting a screen, and descending back to an earlier dart file?
Apologies if this is a turbo ignorant question.
When you exit a page in Flutter, the dispose method is called so I think you could save the Shared Preferences in that method.
Here's a pretty good article on this area: https://medium.com/flutter-community/widget-state-buildcontext-inheritedwidget-898d671b7956
Related
I'm trying to make a Gym app. You can add a workout by pressing the + on the appbar, and this takes you to a new screen where you can add the information about all the exercises and the workout name. When you press the check button, it goes back to the main screen where it displays all the workout that you've created, so that if you tap on a list tile it displays all the exercises.
My problem is that I don't know how to pass all the information about the exercises back to the main page. The only thing that I pass back is the workout name. My idea was to pass a Map<String workoutName, List> so that in the main page I have everything that I need. What do you think about it?
P.S. Rn I'm not storing anything in LocalStorage yet, mainly because I don't know what to store I was thinking about storing the Map<String workoutName, List> But I'm a fresh dev on Flutter so there may be easier solutions.
There are many ways to do this. Because of the inevitable growth of your requirements, I suggest going with the most common way to both pass variables and control your state. Meaning: when your variables change, when you return to your original screen, the screen also rebuilds to show your new information. Riverpod has become the successor to the previously Flutter team recommended State Management solution.
I suggest finding a nice, popular tutorial on Riverpod, perhaps building an app entirely with the video to give yourself a good start.
I'm working towards designing an interactive menu. The main idea is a dashboard with some buttons within (see picture for example). After an user clicks on the picture, the app would render a similar dashboard, but with different buttons.
The flow of the dashboard would have depth 3 => Main categories => sub categories => sub sub categories.
My question here is, what is the best practice to avoid the user from generating a lot of screens within the app (by clicking a lot of buttons)? Does flutter automatically take care of this? I guess my main concern is, what could go wrong in terms of designing something like this in terms of cell phone using too much power to render the app?
Thanks!
My humble approach toward this is to create only one view (screen) and use a state management package to update the view. I'm familiar with flutter_bloc.
In your state you would define an int to keep track of the menu level:
menuLevel == 0: main memu
menuLevel == 1: sub menu
menuLevel == 2: sub sub menu
Then in your view's BlocBuilder you update the view based on the menuLevel state property.
This answer might sound a bit vag because it assumes that you are familiar with state management in Flutter. In particular with flutter_bloc. If not, I strongly recommend you learn a bit more about state management as it will save you time and help you better tackle this kind of situation in an efficient manner.
I'm having a very simple problem with my implemented 3D Touch dynamic quick action shortcuts.
I want the shortcuts to be cleared whenever the app is terminated (by double clicking the Home button and swiping up).
I am calling UIApplication.sharedApplication().shortcutItems.removeAll() as follows:
func applicationWillTerminate(application: UIApplication) {
// Called when the application is about to terminate. Save data if appropriate. See also applicationDidEnterBackground:.
// Saves changes in the application's managed object context before the application terminates.
UIApplication .sharedApplication().shortcutItems?.removeAll()
self.saveContext()
}
However it has no effect, and the quick actions still show when 3D touch is used.
If I place UIApplication.sharedApplication().shortcutItems?.removeAll() inside
func applicationDidEnterBackground(application: UIApplication), this works exactly as intended...
I read something about applicationDidEnterBackground being the function used in most cases due to background processing or something...but there has to be a way to achieve what I want when the user terminates the app using the app monitor swipe up.
Thanks
Didn't tried this. But this tweak should work.
Start a background task on applicationWillTerminate and end it after some small delay. In the mean time, you can call 'UIApplication .sharedApplication().shortcutItems?.removeAll()'.
This will hopefully clear the shortcut items.
There are dynamic and static quick actions. The first kind you define through the shortcutItems property of the UIApplication instance (like in your example). The second kind you register in the plist file.
From the documentation:
Your code creates dynamic quick actions, and registers them with your app object, at runtime.
The system registers your static quick actions when your app is installed.
If a user installs an update for your app but has not yet launched the update, pressing your Home screen icon shows the dynamic quick actions for the previously-installed version.
This means that even when the app is closed the system remembers about both kinds of quick actions. While your app is in memory, such as when going into background, the system can still query the UIApplication for the dynamic actions but it must keep some other sort of persistence of quick actions when the app is closed.
I think there is just no guarantee about the point at which the system synchronizes with the dynamic quick actions. My guess is that the system does not necessarily synchronize when closing the app, yours might be an unsupported use case.
It's taking too long time to show up an page from another. I kept only value bindings to the controls which are pre-dedigned.
Can any one please help me in increasing the performance of navigating between the pages.
Thanks in advance.
Loading images or design elemets(like map) takes a lots of time before loading page. I am trying to call empty page first and by timer start to load design elements it become not more fast but at least you don't wait until create the page . Also I use page.reset() method after i left the page it helps in some cases to reload the same pages performance. In all cases don't expect the performance of native app.
I tried the example which is showing how to get data from history to re-generate UI; The thing I see mostly in all "history usage" examples are related to UI re-generation only so it is none-static way...
But what about "each UI state may have its unique url something like JSF does with flows"? For example I have app url like a
http://localhost:8080/myapp/MyApp.html
the app default UI contains main menu which is helping to navigate through my test catalog; I tried to make possible keep the UI dynamics in history by building url in this way
http://localhost:8080/myapp/MyApp.html#menu_testcategory_page1
but when I click internet browser "refresh" button the url keeps the same as http://localhost:8080/myapp/MyApp.html#menu_testcategory_page1 but the UI comes back to its default state :(
So my question is
is there an optimal way in pure gwt to stay in the same UI state even after browser's refresh button is clicked (I mean the unload/load window events occur)?
thanks
P.S. gwt 2.3
You should implement Activities and Places pattern: http://www.gwtproject.org/doc/latest/DevGuideMvpActivitiesAndPlaces.html
I am using it for 3 years, and it works very well.
Note, however, that when you reload a page, you lose all of your state, data, etc. If you need to preserve some of it, you can use a combination of a Place (#page1) and a token that tells the corresponding Activity the state of the View representing this Place, i.e. (#page1:item=5).
You probably just forgot to call
History.fireCurrentHistoryState();
from your entry point.