We want to create a Windows desktop version of our weather widget
There are 2 special things about the widget.
It consumes a lot of processor time
while active - it displays an
animated picture (Flash without GPU acceleration, unfortunately).
It updates the weather from our
server (frequent server requests from all widget users).
When the user does not look at the widget there is no need for animation and weather loading.
So I have an idea of putting my widget to sleep when it is not visible and hense not used.
Is it possible to detect whether the widget is used or not.
Speaking precisely I need to know whether the widget is covered by other windows?
I mostly interested in Vista/7 gadgets engine, however I also would like to know if this problem is solved in these widget engines
Yahoo widgets
Google desktop
Hope to find some desktop widget guru here.
Pasha
If you InvalidateRect and don't get a subsequent WM_PAINT message, than your window is hidden. You can call UpdateWindow after InvalidateRect to force the WM_PAINT message to happen (or not happen) right away.
So you could do something like this
request server data (and cancel request timer if any)
when data arrives InvalidateRect
when WM_PAINT message arrives, draw the data and set a timer for next request
when timer arrives, goto 1
When you stop getting WM_PAINT messages, you stop re-setting your timer, and you therefor stop requesting updates from the server. When the WM_PAINT message happens (because you are no longer covered). You start requesting data again.
Related
So I'm seeing some bizarre behavior in an appwidget that I wrote.
The widget itself is quite simple - it reads a few values from persistent storage and then displays them as text. Nothing fancy in the layout - just a FrameLayout root element with some Linear Layout and TextView children.
The widget has a simple configuration activity associated with it.
The bizarre behavior is that the widget will initially show "Problem Loading Widget" after the user closes the configuration activity, and then after a few seconds it shows a "Google Sound Search" button (and clicking on the button actually does launch Google Sound Search). Then, after a few more seconds, it finally shows the expected display.
I am away from my code right now, so I'll have to wait until tonight to post code snippets. However, in the meantime, can anyone provide some insight into how such a thing could happen? Has anyone else ever experienced this? How could another widget "hijack" mine?
Thanks,
-Ron
Here are some screenshots:
There are a couple of issues with your widget and there are answers to all of them (although you didn't post any code so some of my statements are based on assumptions):
"Problem loading widget": this is the default view Android uses before the widget is initialized and the layout updated. Simply add the following line to your widget xml configuration (to show a loading message instead of the problem message):
android:initialLayout="#layout/my_cool_widget_loading_message"
If the widget shows the wrong layout then you probably have an issue in the widget's onReceive method. onReceive is called for all the widgets no matter whether the broadcast is for that specific widget. Android's AppWidgetProvider filters the broadcasts by appwidget Id and dispatches to the other methods (like onUpdate).
See also: https://developer.android.com/reference/android/appwidget/AppWidgetProvider.html#onReceive(android.content.Context, android.content.Intent).
If you override onReceive (which I assume you do), you need to call through to super.onReceive(Context, Intent) to make sure your other methods don't get calls meant for other widgets.
Now for the configuration of the widget. If you follow the Google documentation then it will all work nicely. The only improvement I'd do is what my other answer that you reference suggests (https://stackoverflow.com/a/14991479/534471). This will NOT send out two broadcasts. The setResult()/finish() part does only terminate the config Activity and let Android know whether to actually add the widget or not (depending on whether the result is RESULT_CANCELED or RESULT_OK.
From your own answer I can see why your code wouldn't work. The code is:
Intent intent = new Intent();
intent.setAction(AppWidgetManager.ACTION_APPWIDGET_UPDATE);
intent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_IDS, new int[] {mAppWidgetId});
intent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_ID, mAppWidgetId);
setResult(RESULT_OK, intent);
sendBroadcast(intent);
finish();
First of all there's no need to add the appWidgetId twice, use the AppWidgetManager.EXTRA_APPWIDGET_IDS version and you're good. Second you're using the same Intent to return as a result for the Activity. AFAIK it's not documented what happens when you do set an action on that Intent but my experience with Android widgets is that you need to stick exactly to the documentation or you'll end up having strange issues (like the ones you encounter). So please use two different Intents.
Activity result:
Intent resultValue = new Intent();
resultValue.putExtra(AppWidgetManager.EXTRA_APPWIDGET_ID, mAppWidgetId);
setResult(RESULT_OK, resultValue);
finish();
Broadcast:
Intent intent = new Intent(AppWidgetManager.ACTION_APPWIDGET_UPDATE, null, this, MyWidget.class);
intent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_IDS, new int[] {mAppWidgetId});
sendBroadcast(intent);
ok, so I figured it out. Posting here in case anyone else runs into this. I think that the Android Developer docs are a little misleading here.
The problem was that in my configuration Activity, I had this code at the end:
Intent intent = new Intent();
intent.setAction(AppWidgetManager.ACTION_APPWIDGET_UPDATE);
intent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_IDS, new int[] {mAppWidgetId});
intent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_ID, mAppWidgetId);
setResult(RESULT_OK, intent);
sendBroadcast(intent);
finish();
Providing an intent with the extra EXTRA_APPWIDGET_ID is recommended by the documentation provided by google.
However, that same document says that you have to update the widget's view by creating a RemoteView and calling AppWidgetManager.updateAppWidget() like so:
RemoteViews views = new RemoteViews(context.getPackageName(),
R.layout.example_appwidget);
appWidgetManager.updateAppWidget(mAppWidgetId, views);
I didn't like the idea of placing the presentation logic in both the configuration activity and the widget class, so I instead decided to broadcast an intent at the end of the configuration activity to tell the widget to redraw itself. That's why I have setResult() AND sendBroadcast() at the end of the activity. The documentation further states that the onUpdate() callback will not be called when using a configuration activity. So this seemed neccessary. I added the ACTION_APPWIDGET_UPDATE and the EXTRA_APPWIDGET_IDS to the intent so that it would trigger the onUpdate() method. This practice was recommended by this SO answer (albeit without being included in the activity result intent - but I tried separating the two and it had no effect).
Now I'm not certain exactly how the "Google Sound Search" widget got in there, nor do I fully understand the mechanics of how the intents interacted to produce the observed results. However, as soon as I replaced my code above with the code stated in the docs, the widget was updated properly.
Intent resultIntent = new Intent();
resultIntent.putExtra(AppWidgetManager.EXTRA_APPWIDGET_ID, mAppWidgetId);
setResult(RESULT_OK, resultIntent);
finish();
This seems to contradict the documentation's statement that the configuration activity must update the widget's view. Simply providing the configuration activity result as below triggers the onUpdate() method in the widget, thus allowing the widget to redraw itself. I confirmed the behavior on an emulator running API 23 and also on a Samsung device running Samsung's android flavor.
I am quite new to windows 8 phone and I don't know all the life cycle methods and when what is called.
My problem is the following: I have a page that loads some data from the disk and when the user exits the program ( or suspends ) the data should be saved. As far as I can tell Page doesn't have an OnSuspending method only someOnNavigatingFrom, but those are not called when you just exit the program. So I read that I should use the OnSuspending in my App.xaml.cs, but this class doesn't have this data and also shouldn't have it, maybe only for OnSuspending. But I don't know how to get the data from my page in the OnSuspending method.
The OnSuspending event is quite fragile and you cannot expect it to run and save the state for a long time. But it depends on how long it would take for you to save. It doesn't even get triggered when you hit the home key while closing the app. If you really want an easy way. Just register a background task. While your app is in the background, the state can be saved and when you open the app again things are in place.
There are certain constraints With Background task as well, you cant do heavy lifting etc...here's a link you could use.
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh977056.aspx
Implement an observer pattern (i.e. pub/sub) for your view-models to subscribe to in the event that your app is being suspended.
Your app handles the suspended event. As a result, publish a message for your view-models to respond to within your app's method handler for the suspended event.
You can use an EventAggregator or MessageBus (that I wrote).
I currently use Azure Mobile Services with Offline Sync and I it has been working fine. However I now have come to a problem I can't seem to debug. On the PullAsync it never returns, never goes to the Web API, it never errors, it just seems to be stuck somewhere and I don't know where.
IMobileServiceSyncTable<ResponseType> responseTypeTable = MobileService.GetSyncTable<ResponseType>();
await responseTypeTable.PullAsync(responseTypeTable.Where(c => c.CompanyId == companyId));
I use identical code elsewhere with a different type and it works well.
The only thing that happens is the Windows Phone emulator UI locks up, I can press buttons on the keyboard but the input or buttons are all frozen.
I get this on the Debug Output
The thread 0xb80 has exited with code 259 (0x103).
After a 5 seconds and that's about it. Breakpoints everywhere, nothing happening.
The method was in a Command (I'm using MVVMLight). When I call the function on the class initialization and just hold the value it works fine. There is obviously some bug that occurs when calling PullAsync on an event, in an async RelayCommand but getting the call out of there solves the issue.
I'll leave it at that unless anyone comes back with why it is actually happening. This is just a workaround at the moment.
I'm looking to do some performance tuning based on what I am seeing in New Relic's RUM output, but I need to understand the following first.
I have a page that loads up a KendoUI grid. The grid is configured to load it's data asynchronously. So the page loads and the user gets to see the grid layout. In a few milliseconds the grid displays the "loading" graphic, while it then waits for the async request for the data, which comes back as Json, following which the "loading" graphic is replaced with actual data.
I need to understand if this async loading of the data for the grid (or any other $.ajax() request for that matter) in any way affects New Relic's RUM output?
Specifically, the RUM is reporting a certain time for DOM Processing, and a certain time for Page Rendering. In which one of those two numbers will the async request be reported (if at all)?
In general, if anything happens after the Load() event, then the New Relic RUM (Real User Monitoring) will not capture this activity.
For example, if you take a look at your network (or waterfall) view in a browser you can see exactly when this Load event fires and when your resources are loaded in the context of this event.
Most likely, your async assets will (and should) be gathered after this Load() event and will not be included in RUM metrics. This blog article has a nice breakdown of how to tune this type of metric (and how New Relic has in the past).
"The RUM timer stops when the browser has rendered and the user is able to interact with the page. ... It’s up to you to decide what that means, and adjust your ... code accordingly."
http://blog.newrelic.com/2012/05/10/how-we-tune-our-own-app-using-rum-data/
We are also investigating adding support for Ajax instrumentation so you can get additional visibility into this activity.
New Relic has recently updated their monitoring to add support for measuring AJAX requests. You can find the release blog here:
New Relic AJAX Support Release Blog
and the docs here:
Enabling New Relic Browser AJAX Monitoring
We are using a Cumulus server as our RTMFP server to implement a voice chat.
The voice streaming with NetStreams works perfectly fine almost no delay here, but we also want to transfer the activity level of the microphone of each member of the NetGroup.
So we tried transferring the data using NetGroup.post(data). That worked well, but had a delay of ~500ms even when testing with multiple clients on the same machine!
Obviously, half a second in microphone activity is just waaay to much delay to display it in any way.
Now we are trying to use direct routing with NetGroup.sendToAllNeighbors(, but it simply does nothing. I have read all the documentation on it and normally a NetGroup status event with "NetGroup.SendTo.Notify" should be triggered on the receiving clients. Instead, nothing happens.
Here is the code, which is called each frame:
var tsObject :TimestampedObject = new TimestampedObject();
tsObject.timestamp = (new Date()).getTime();
tsObject.sender = _netConnection.nearID;
tsObject.object = _mic.activityLevel;
_netGroup.sendToAllNeighbors(tsObject);
I know each frame is a bit much, but for now it is just a test case.
What are we doing wrong? As I said, voice communication itself works fine. As does Netgroup.post(data), which is just way too slow to use for this use case.