Is there a way to implement an android widget without having to use any broadcast receiver?
I know that the class has to extend the AppWidgetProvider class (which extends broadcast receiver). But I am looking for a way around without having to extend the AppWidgetProvider and registering the class as the receiver in the xml file. Or is there a way I can make a UI that can know if an android application is running(Again, no broadcasting)?
But I am looking for a way around without having to extend the AppWidgetProvider and registering the class as the receiver in the xml file.
You definitely need the <receiver> and its associated app widget metadata in the manifest -- that's unavoidable. In theory, you are welcome to have the receiver be a no-op (i.e., drop all received broadcasts) and update the app widget yourself via AppWidgetManager elsewhere in your code. However, I suspect that your user experience may suck at the time the user adds the app widget to their home screen, as Android will be expecting your AppWidgetProvider to update the app widget UI, and if it doesn't, you might get unexpected results.
Related
We're building some integration tests with FlutterDriver, and would like to verify the state of the application.
It seems flutter drive runs in a totally different instance than the app, so they can not communicate indirectly by stashing data in some shared static class.
Are there any common strategies to passing data to the test layer, from the app?
Some ideas I thought of:
We could write json values to disk, but can the test side actually read it?
Have a hidden text widget, that shows a special ui view that renders state so we can then read it from the test layer
fwiw, we have solved this currently by json-encoding some of our app state into an invisible Text widget that we place on screen.
The test can then lookup that text, decode the json, and read the current app state.
Pretty hacky but it works!
test('Check flutter driver health', () async {
Health health = await driver.checkHealth();
print(health.status);
});
Well, I am sort of new to Flutter, My question is why we use providers in Flutter, I know it is used for state management. But I am looking to know the most common use case of providers.
You need to be able to move data between your Widgets. It's an easy way to do it.
You start your root Build method in the app with:
#override
Widget build(BuildContext context) {
return MultiProvider( // Multi means you can have more providers if you need
providers: [
ChangeNotifierProvider(builder: (context) => MyStateClass()),
],
child: MaterialApp(....
Now you can place all the data you need to share in the MyStateClass() and place underlying Widgets inside:
Consumer<MyStateClass>(builder: (context, state, child) {
// your code here - return(SomeOtherWidget());
})
or inside your Build methods:
#override
Widget build(BuildContext context) {
MyStateClass state = Provider.of<MyStateClass>(context);
// ... TODO ... return (Widget)
As you asked that why we use provider in flutter, so i will be providing only theoretical explanation which i think will surely help you to understand what
actually provider is and why it is used.
Suppose you are working on a large app with a lot of folders and files.
Now if the user have interacted with your app(say pressed a button or something like that) then the app have to build itself again to update to the changes that the user had made.But wait! this doesn't looks a good deal, to build the whole app again just to make changes in some particular section.
So, here comes the Provider to solve this problem.
A Provider is basically a container or a storage that stores and provides you with state or data.
Also, we know that widgets are arranged in an app like a tree like fashion.
so, if u assign Provider to any node in the tree then all the children of that node will have access to the data that is provided by the Provider.
Back the stage ,Provider comes with a listener and these listeners are assigned to the children of the widget to which Provider is attached.
So, If the user interferes with any widget that has a listener then the app will build only that particular (which the user interacted) widget again (not the whole app).
What is provider and how it's works ?
Provider is a simple way for state management, it works on the concept of PUB_SUB,
Which means there is one provider and multiple subscribers which is called consumers here. ex : youtube.
Whenever there is change, with NotifyChangeListener it will update all the consumers.
A wrapper around InheritedWidget to make them easier to use and more reusable.
By using provider instead of manually writing InheritedWidget, you get:
simplified allocation/disposal of resources lazy
loading a vastly reduced boilerplate over making a new class every
time devtools friendly
using Provider, the state of your application will be visible in the Flutter devtools a common way to consume these InheritedWidgets
Background
On Android, there are 2 possible ways to listen to system events via BroadcastReceivers :
statically, via the manifest
programmatically, via the code.
Since some projects contain a lot of activities, services, and "manager"-classes , it could be useful to have a single BroadcastReceiver that will notify all of its listeners on the app about what has happened, instead of having multiple BroadcastReceivers being used (and their code handling).
An example of such a BroadcastReceiver, is the one that listens to the connectivity changes:
#Override
public void onCreate() {
super.onCreate();
...
registerReceiver(new ConnectivityChangedBroadcastReceiver(), new IntentFilter(
ConnectivityManager.CONNECTIVITY_ACTION));
...
}
The question
The purpose is to listen to the events while the app is "alive" (by services and/or activities) .
Using the manifest would miss this purpose, as it will wake the app each time the event occurs, even if the app doesn't need it.
Thing is, unregistering doesn't occur, and maybe it causes the OS treat the app in a different way because of it.
Does having a call to "registerReceiver" on the class that extends from Application is a good known practice?
Does it have any side effects and things to know about when using it?
Is there any alternative to this?
I just want to be sure it's considered safe to use.
we can't really know what is good or better for you.
I advise you to learn more about the difference between the registration ways of the receiver:
1/ in the manifest :
the handler of the receiver will be triggered each time that the correspondent event comes. Example: the messenger of facebook is lunched every time that you have internet connection to show you your notifications... or other applications are lunched when you connect to propose updates ...
in other words, the receiver is always registered.
2/ in a service or an activity or an application :
the receiver will be unregistered when the context of where it is registered is killed.
in other words, it depends totally of the context where it is registred , and you are obliged to unregister it somewhere in the code. exemple : one activity is waiting that a service ( which is doing something in the background) sends an alert to update something , then you can register the receiver in your onResume() and unregester it in your onPause().
Conclusion : It depends only in the life-cycle requirement of the receiver.
see also Broadcast Receiver Register in Manifest vs. Activity
Main difference between Manifest and Programmatic registering of BroadcastReceiver
I've implemented the new IAB in my application, but when I tested it on two different device the result were different on galaxy S3 the flow was great but on galaxy S1 (gt-i9000), after purchasing onActivityResult method isn't called and the application restarts.
any suggestions?
I had the same problem, in my case the reason was that I had a flag set in the intent that called the activity which hosted the purchase process
i.addFlags(Intent.FLAG_ACTIVITY_NO_HISTORY);
after removing the flag it works, I guess it is because when the startIntentSenderForResult starts the purchase interface the activity is destroyed, not kept in history and somehow there is no point to handle the onActivityResult
Are you using TABActivity? If answrer is yes than procedure is somewhat different,As the
onActvityResult will be called for the parent class which is your activity that extends TABActivity,I dont know why but it seems that parent is cathcing the onActivityResult.So your code for startActvityForResult or startIntentSenderForResult should be in that actvity.
i used this link and made some changes according to my app and it works
onActivityResult is never called in TabActivity
My gremlin for this problem was using a negative requestCode. That breaks the result dispatching mechanism.
I write an Android application. I have a lot of Activities in my application with a large number of transitions between Activities. I decided to realize a state machine, which will switch my activities.
I hoped to realize a State Machine in my Application class or its subclass, but I can't start any Activity from it.
public class MainAppClass extends Application {}
the code like this is failing:
Intent intent = new Intent();
intent.setClass(this.MyActivity, Screen2Activity.class);
StartActivity(intent);
Maybe, is it unreal? Are there other methods for such tasks?
Thanks for your answers!
Here's another question: Why are you trying to start an activity from a subclass of Application?
Read this (from the documentation) and you'll see why what you are trying to do doesn't make any sense.
The Application class is the base class for those who need to maintain global application state. There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.
If you edit your original post, clarifying why you are trying to do this, perhaps I can point you to a more suitable means of launching your Screen2Activity.