Like the titel saying, I want to control my „flutter“ app when I lock the screen (maybe also Show some part, like one widget).
Like google-maps, when you Kick the screen when navigation is running. Or controling music when I lock the screen. (Or maybe control over the earphones)
I searched the whole google results (to page 2-3).
All I can find is, how include an individual lock screen in my app.
You need something like this: https://pub.dev/packages/awesome_notifications
because you can not do it by yourself, the only way is using notifications...
I'm totally new to flutter app but have strong concept in android/kotlin. I'm trying to understand the basic structure of the flutter app. I read that every widget need a build function to override to draw the children that was fine for me because in android/kotlin there is onCreate(); or similar others. Then I saw this code on the official document page.
void main() {
runApp(
Center(
child: Text(
'Hello, world!',
textDirection: TextDirection.ltr,
),
),
);
}
It is working fine without build() function so what is the real purpose of the build function? And when we need it? What can be without it or what can't?
While you could have everything passed directly to runApp, it has a pretty big drawback:
Your app would be static. Without a build function (or a builder like with FutureBuilder), then your app will have no way of having dynamic content.
It is also pretty bad for reusability. You may want to extract some part of this widget tree into custom widgets, to reuse them in different locations – which implies a build method for that custom widget.
Flutter functions rather differently from many other platforms, and the name build() only adds to the confusion. :-)) To understand it, try to forget your previous experiences with other platforms temporarily.
Build() is really more like display()
Flutter uses the build() system to display the current frame. If the app has rapidly changing content, like an animation or a game, build() will be called 60 or more times per second, that is, for every single frame. Yes, that's the intention: no matter what its name is, think about it as a function to displayCurrentFrame(), not what the name might imply, to build a widget and then use it for the rest of the life of your app.
The system is perfectly optimized to know when it has to call build(). For content that doesn't change that often, it will not call it 60 times per second, it's smart enough not to do that. But every time it's really needed, it will be called (and for really complicated cases, you also have mechanisms to help Flutter decide when to call and what to call, to make sure that only parts that really change get redrawn, making it possible to avoid jerkyness in apps that really need rapidly changing content, mostly games).
The task of your build() is to take whatever data you currently have (that's called the state of your widget) and build up the widget (or widgets) just with that data, just for that single display frame. Next time around, with possibly different data, you will build it again and again.
So, a Flutter app works differently from many other platforms. You don't write code that waits for interaction from the user, then, for instance, calls a display function to show a new selection, a new text entry, a new image, anything directly. All your widgets function like this: whenever there is a change, the user does something, a response arrives from a call you made over the internet, a timer has elapsed, so basically, anything happens, your widget stores whatever new data you just received into its own state and tells Flutter that "hey, there are changes, please, call me so that I can draw a current version of myself." And Flutter will call its build() all right, and your widget will display itself according to this current new data. Again and again, as long as your app is alive and kicking.
At first, all this might seem like a waste of resources. Why rebuild everything on potentially every frame, instead of building a widget, keeping it alive and using it while the app lasts? The only realistic answer is: don't worry. The system was conceived explicitely with that structure in mind, it gets compiled into optimized code that works just fine, it's fast and responsive. Those widgets are lightweight enough so that this doesn't mean the slightest problem in real life (and, as already mentioned, in really complex programs where it starts to matter, you can have your say in how it should work, but you don't have to worry about that, either, until you reach that stage when it really counts). Just get used to it and accept that this is the way Flutter works. :-)
Other implications
All this has other implications as well. You should never do anything in build() that you're not comfortable doing on every display cycle: both because it shouldn't take too much time and because it will be called over and over again. Especially not anything that's a longish operation. You may start an async operation (actually, you probably do so quite often when acting on some user input), but that's async, it goes away to do its job and simply returns later. When it does return, you store the new data in the state, as described above, and use that in build() the next time around. But you never wait for anything there, or do any real complex programming logic and perform tasks there. It's nothing more than a display(), really.
I have a code whereby it runs a for loop upon pressing a button, which will in turn update Firestore for every time the loop repeats.
On my iOS simulator, when I lock the simulator or minimise the app, Firestore still updates. However, on my physical device, whenever I minimise the app Firestore stops updating and only resumes when I re enter the app.
I am afraid that users might not have their data fully updated to Firestore before they navigate away from the app or page, and also do not want to hold users to the page with a progress bar forcing them to wait on the page.
Is there a solution to this? Or is the only way to implement a spinner that spins until the for loop is finished?
If so, how do I ensure that the method is complete before I end the spinner? As my method containing the for loop is Async, it doesnt wait for Firestore to finish updating before it toggles my spinner off.
In my app I navigation to a page with a fullscreen map. Currently I've implemented a FutureBuilder to render the map or else a progressindicator is displayed. From initState I request UserLocation (lastknown or current) and the maps navigates to the location. The issue is that the page navigation is not smooth after I added the map. I'm looking for a way to make the page complete its navigation before the map is rendered. I've searched but haven't found a working solution yet. Any good ideas on how to make this?
Happy Flutter day :)
Use Isolates to do any intensive work. An Isolate is essentially a new thread so that the main thread is freed up to continue doing UI work.
from https://flutter.io/docs/resources/faq#how-do-i-write-parallel-andor-concurrent-apps-for-flutter
How do I write parallel and/or concurrent apps for Flutter? Flutter
supports isolates. Isolates are separate heaps in Flutter’s VM, and
they are able to run in parallel (usually implemented as separate
threads). Isolates communicate by sending and receiving asynchronous
messages. Flutter does not currently have a shared-memory parallelism
solution, although we are evaluating solutions for this.
Check out an example of using isolates with Flutter.
I'm dealing with a strange situation I want to debug in my Windows Phone 8.1 app, and I'm not sure in which moments OnNavigatedTo is called.
Obviously, it gets called (and I've checked tracing it with the debugger) when you navigate to the view normally.
My doubt arises in other point I want to check, let's call it "You wake up your application and the screen was shut off".
My question is: When you turn on the screen, and you swype the screen protector away, is "OnNavigatedTo" function called or not?
According to some manuals I've read somewhere else, it should.
According to my Debug.Writeline traces, it seems it doesn't.
I need to check some condition and execute some code before/when the view appears, and I'm unable to do it properly.
PS: Does it exist some other alternative event I should use to deal with "This view is becoming visible/focused after you turn the screen on" situation instead of "OnNavigatedTo" ?
Thanks in advance.
In Windows Phone 8.1 Runtime (Store apps) OnNavigatedTo is called only during navigation. It's not called after resuming from suspension - you can read a reference here at MSDN:
before Suspending event, the OnNavigatedFrom event is being called, but when you Resume, the OnNavigatedTo is not called
In your case when you lock the screen, the app is suspended, after you resume OnNavigatedTo is not called. If you look for some events which may be called - take a look at Window.Activated and Window.VisibilityChanged events.
The other case is that when you debug your app, your app won't be suspended, you will need to test it via Lifecycle events tab.