I wanted to update the widgets information on the Application version update.
I know the onUpdate method of AppWidgetProvider gets called in App upgrade, however, the same method also gets called every time the widget is updated.
Question - is there a way by which we can differentiate whether AppWidgetProvider.onUpdate is called on App update or via the widget uddate?
Note - I know that we can do this by creating the broadcast MY_PACKAGE_REPLACED and have a logic there. However as per my experience this does not gets called on certain devices.
Thanks in advance!!!
Related
If the call Crashlytics.start(this) is on Application's onCreate() method, will it count an active user if something wakes up my application process?
For e.g. if I have a broadcast receiver or alarm, will it count as an active user if those wake up the app?
Thanks
I'd say that it does not count, but my answer is purely based on logic and common sense.
Crashlytics' recommended approach is to initialize the SDK in your Application class, so that crash logs (and every other type of info) can be collected as soon as possible in your app's lifecycle. When they introduced the Answers panel, my guess is that they figured out their way of determining what an active user is, based on a series of parameters and actions that indicates that the user is actually operating the app (which is, by the way, differs in every Analytics SDK provider, e.g. Google Analytics).
In short, I don't think that the Crashlytics.start() method immediately counts for an active user, because that would be just nonsense. But there's a quick way of determining that:
Create a testbed application that is fired up when you send a specific broadcast message
Initialize the SDK in the Application's onCreate() method
Using adb, send the broadcast message and meanwhile keep an eye on the Answers page of Crashlytics
Wait for some time (it may take some time to register the hit): is the user being tracked as active?
You can try to reach Crashlytics support for this, but I'm not sure they are going to give away this information.
EDIT
Adding some evidence I've found here:
A session begins when the app enters the foreground and ends once the app is backgrounded for 30 seconds or longer.
This leads to believe (as I wrote above) that their way of detecting an active user does not rely purely on the SDK initialization.
I guess that it should, unless it has a more complicated logic of some "actual activity" instead of just opening the app. Application.onCreate() is being called on the beginning of any Activity, Service or Broadcast of your app.
This is what is written in android documentation:
Called when the application is starting, before any activity, service,
or receiver objects (excluding content providers) have been created.
Implementations should be as quick as possible (for example using lazy
initialization of state) since the time spent in this function
directly impacts the performance of starting the first activity,
service, or receiver in a process. If you override this method, be
sure to call super.onCreate().
But keep in mind that if the app is already running the Application.onCreate will not re-run as it is already created.
I want to create Event Reminder App, I search and found that I need to use a service and broadcast receiver.
But it is not clear for me what is the role of each components ?
As I understand-but I am not sure- that the App needs an Activity that when starts, it runs the service ( which check the current time with times are stored persistently , for example in database !). when the two times match , the service create a broadcast, and our broadcast receiver receives it and create Alert.
My questions are:
Does this inception is correct ?
How to make the service running and always check the time ( do we need some infinite loop?!!)
thanks in advance,
Activities and Services can be killed off without notice anytime system decides it's low on resources. There is no guarantee that your Service would run all the time. Also, if phone is in sleep mode, your code stops executing.
So:
The premise is wrong, for the reasons stated above.
You cant guarantee that Service would be running all the time.
For your purpose you should be using AlarmManager. It is garanteed to call your code when alarm is triggered. Also important - AlarmManager survives device restarts.
When the device is restarted, my appWidgets are all broken. In my WidgetProvider class i have implemented only the onRecieve method, since i'm using a ConfigureActivity to create the widget. What method should I override on the WidgetProvider for my widget to be updted properly when the device is restarted?
When the device reboots, all the desktop widgets are rebuilt via the onUpdate method in the WidgetProvider class. Just implement this method to recreate your widget as shown here.
If I understand your problem correctly, register to receive the ACTION_BOOT_COMPLETED broadcast, and re-create your widget when you receive it.
Make sure you also hold the RECEIVE_BOOT_COMPLETED permission.
It's best practice to make sure you respond and exit from your BOOT_COMPLETED handler as quickly as possible - spending too long responding to BOOT_COMPLETED will give a poor user impression of the platform.
Widget Provider is a specialized BroadcastReceiver.
Assuming there exists an Application, 1-n android service,1-k activities, and potentially additional 0-n broadcast receivers that are not widgets, I would like to verify what belongs and does not belong logically inside the broadcast receiver. Here are some items ..
And assuming that generally what gets launched is the widget first.
Please comment on any of the items as to whether they belong inside or outside the widget and why. Thanks.
1) If the application needs to always listen for certain events whether they show up in the widget or not where should this go? In the Widget? If not what would keep the broadcast receiver available to listen to the events for the application?
2) Should the widget issue notification? or request a service to issue them? ie should the notification logic reside in the widget itself or in the service.
3) Should the widget issue broadcasts or ask a service to do this?
4) Should the widget ever access any system services like like Notification Manager, PowerManager etc Why, Why not?
5) Should the widget keep any of its own state? If it should not keep state how can it change what it displays? Like a different text or icon?
6) Should the widget start off activities or let a service handle this?
7) is it ok to user the context passed to update and receiver or should one use ctx.getApplicationContext() to do things like context.startService? ( Perhaps the one passed in is the application context ? )
Quoting myself from your cross-post to the android-developers Google Group:
Your entire question is phrased around "the Widget". There is no "the
Widget". From the opening sentence of your question, I am interpreting
"the Widget" to mean "a subclass of AppWidgetProvider that handles the
processing for an app widget or family of app widget instances".
1) If the Application needs to always listen for certain events
whether they show up in the widget or not where should this go? In the
Widget?
There is no reason for an AppWidgetProvider to respond to other
broadcasts, since anything can update the app widget's RemoteViews.
And an AppWidgetProvider cannot register listeners (e.g.,
PhoneStateListener).
Hence, I would say the answer here is "no".
2) Should the widget issue notification? or request a service to issue
them? ie should the notification logic reside in the widget itself or
in the service.
Technically, AFAIK, raising a notification is cheap and therefore safe
for an AppWidgetProvider to do.
Logically, an AppWidgetProvider should never have any reason to raise
a notification, IMHO.
3) Should the widget issue broadcasts or ask a service to do this?
Technically, AFAIK, sending a broadcast is cheap and therefore safe
for an AppWidgetProvider to do.
Logically, an AppWidgetProvider should never have any reason to send
broadcasts, IMHO.
4) Should the widget ever access any system services like like
Notification Manager, PowerManager etc Why, Why not?
This cannot be answered in the abstract.
5) Should the widget keep any of its own state? If it should not keep
state how can it change what it displays? Like a different text or
icon?
It may need to. For example, suppose you have an app widget that shows
the weather for a certain city. The configuration activity for that
app widget allows the user to choose the city. Somewhere, you need to
store that city, and distinct from the cities that any other instance
of that app widget may need (e.g., user adds two copies of the app
widget to track weather in two cities).
6) Should the widget start off activities or let a service handle
this?
An AppWidgetProvider should never have a reason to directly "start off
activities", nor should a service triggered from an AppWidgetProvider
have any reason to directly "start off activities", IMHO.
However, either are perfectly welcome to create PendingIntents that
"start off activities" and attach them as click handlers for widgets
in an app widget's RemoteViews.
7) is it ok to user the context passed to update and receiver or
should one use ctx.getApplicationContext() to do things like
context.startService? ( Perhaps the one passed in is the application
context ? )
Most things you can just use the passed-in Context. One thing that
will not work for is using registerReceiver() with a null receiver to
get the last value of a sticky broadcast, such as
ACTION_BATTERY_CHANGED -- for that, you will need to use
getApplicationContext().
Actually this question applies to any widget that requires data from a remote server.
The answer would be pure speculation, but how do you think the widget gets its data? For those that don't know, the widget shows a history of your friends' latest status updates.
Some answers that I can think of:
The widget polls the API directly
The widget grabs data from some
service that's running in the
background, which polls the server
Somehow Facebook implemented push on
Android which I don't think exists
The widget somehow detects that the
user is using the screen and grabs
the data on demand
I would say #1 or #2. Most likely #2 for the reasons jleedev gives in his answer.
Note that to implement an app widget you extend AppWidgetProvider, which is a BroadcastReceiver. This is simply a class that runs in the background and pushes updates to the widget on screen via RemoteViews. So what you are seeing on your home screen isn't an actual running Activity, it's just a fairly static view that is updated periodically via a special BroadcastReceiver. I say all this to show that there isn't much difference between your #1 and #2, as all homescreen app widget code you write runs in the background.
Also you can't really do #4. You can't detect when an app widget is on screen, unfortunately. The best you can do currently is schedule alarms to update your app widget, and use the flag that keeps those alarms from firing when the phone is asleep.
The Android SDK documentation refers to the sample Simple Wiktionary AppWidget. This runs a service that periodically pulls data from the Internet and pushes it back to the widget. Full source code is available.
The documentation says
If your App Widget setup process can
take several seconds (perhaps while
performing web requests) and you
require that your process continues,
consider starting a Service in the
onUpdated() method... If you don't
update more than once per hour, this
probably won't cause significant
problems for the battery life.
The widget that I wrote runs a service that periodically pulls data from the internet and pushes it to the widget. That seems to work well.
I would assume #2. The activity and the widget need to display the same content, so it makes sense to have a single service to download and cache the data. Widgets are defined to update on a certain interval, but that doesn’t necessarily have to be the same as how often the service downloads the data. Most apps I have that refresh periodically have a setting to control the refresh frequency, and I imagine that would be a setting on the service.