I've encountered a problem today when testing my Android app with different emulator settings.
Upon clicking a button a certain amount of data (~161kb) is fetched from an online XML-Document.
Up to now I tested the app with full internet speed and faced no problems when fetching the required data. Same for LTE. However when testing with HSDPA and lower mobile radio standards the data wont get loaded.
The data is fetched from an async background task and the fact that it works with LTE makes me believe the code is doing what it should. Furthemore the amount of data is marginal with ~160kb.
My question: Could this problem be caused by the emulator? If so, how could i resolve it?
Related
I am trying to price out various azure services and when I add them to the calculator and make changes the estimate does not update.
I have tried this in Edge, IE, Chrome, Firefox (normal browsing and Private) and I get the same results.
I also ran CCleaner and removed all of the files for each browser.
The calculator did work a few days ago.
Any ideas?
I had the same problem. A solution that works for me is to open a new InPrivate window from the Edge browser. (A new private window from Firefox did not solve the problem).
Perhaps the problem is related to cookies? I have not tested after deleting all cookies. #jake, when you used CCleaner, was it set to delete cookies or just cached data and files?
(For what it is worth, in the Firefox developer console I see several warnings related to failed loading of JS scripts. I can't say if such a failure is the cause of the problem, but it looks like Microsoft needs to do better testing of the calculator page.)
We recently migrated from a SQL Server 2008 SSRS server to a new SQL Server 2016. The entire report catalog was restored and upgraded to this new server. Everything is working, except the horrible performance of the web portal.
The performance while connecting to the web portal from a domain joined computer seems decent, but connecting to the web portal over the internet is seriously frustrating. Even simply trying to browse a directory of reports is a wait of several seconds, and running any given report is similarly slow. It's slow in IE11, Edge, Chrome, Safari, you name it. Like 25+ seconds to go from login to viewing the Home directory.
We are using NETWORK SERVICE as the service account, and NTLM authentication. We aren't getting any permission errors in the UI or the logs. HOWEVER in Edge browser, using the developer tools, I notice several 401 unauthorized HTTPS GET requests for things like reports/assets/css/app-x-x-x-bundle.min.css. So perhaps there is a permissions issue somewhere? Other interesting items in the developer tools is that things like reports/api/v1.0/CatalogItemByPath(path=#path)?#path= are taking like 10 seconds. These are JSON types.
Certain reports that do things like have a parameter depend on another parameter selection will sometimes not work. The waiting icon spins and when the report returns the selection will not be kept, nor the second parameter filled. Sometimes it works, however, which is part of what makes this so maddening.
There are no explicit error messages, but something is getting bogged down in a major way. There are no resource issues on this server that we can see- it's got plenty of headroom in terms of RAM and CPU.
This is not a report optimization problem; the entire UI is slow for everything.
I recently purchased a LG Music Flow H3 to test my Google Cast app with an 'audio-only' device. I've enabled audio-only device support within the Google Cast Dashboard and I've registered the device for development. My app works as expected when played to Google Chromecasts, however when attempting to load the receiver app on the LG device I get the following error:
{"reason":"NOT_FOUND","requestId":1,"type":"LAUNCH_ERROR"}
Thinking that perhaps 3rd-party devices can't be registered for development, I went ahead and published my app. Unfortunately this did not address the problem.
Upon further investigation, I'm noticing that other Google Cast apps (i.e. Songza, TuneIn, Pandora, etc. on both Android & iOS) aren't able to play to the LG Music Flow H3 either.
I discovered that the only way to get the H3 to play from Google Cast apps (both my app and others) is to first run the LG Music Flow multi-room audio app. Running the LG Music Flow app appears to effect the device's _googlecast._tcp zeroconf service discoverability. And sometimes the H3 shows up in zeroconf yet you still can't play to the speaker unless the LG Music Flow app is running.
This seams like very strange behavior. I called LG Tech Support, and they recommended I return the device and exchange it for a different one. I did this, and I still get the same result.
Is this how Google Cast on 3rd-Party devices is intended to work? Have I encountered a buggy 3rd-party implementation?
This is not the intended behavior for sure. You are supposed to be able to launch your 3rd party application on the speaker.
And it works for me.
The fact you are not able to use any other 3rd party apps (TuneIn, Pandora etc) indicate this is a some general problem and not specifically with your app.
Couple of steps I would try:
- Setup you H3 speaker on Wifi (vs Ethernet) and get the latest SW version using the Music Flow app.
Have you Factory reset the device? if you did, you will need to go through setup again. I have noticed Google Cast becomes enabled only after first complete setup.
Please try rebooting, and than try casting apps like TuneIn or Pandora and than see if this works (without using the MusicFlow app). I have noticed in the past that if some app is loaded and is behaving badly (for example uses tons of memory) it will put the speaker into a bad state that don't allow any app to work until reboot. So perhaps when you are casting your app, it gets into a bad state causing other apps to fail afterwards.
Have you made sure not to consume to much memory? avoid graphics or video?
I use the webbrowser control to display a webpage from an application, but it just displayed a white screen. I tried Internet Explorer and it did not display anything either.
Any ideas how to fix this problem.
Thanks a lot in advance.
Windows Phone Emulator requires a DirectX 10 or above capable graphics card with a WDDM 1.1 driver. I assume that you got an error message on first start of the emulator that your graphic adapter isn't capable for all functions the emulator is using and that this may impact XNA games and sometimes silverlight like this one:
If your graphic adapter does not fully support DirectX 10 or doesn't has a WDDM 1.1 driver you will only see a white screen instead of the rendered webpage. This also affects all controls using MultiScaleImage, including the webbrowser control. As far as I know there is no solution for this at the moment.
To check if the emulator is running the required GPU emulation take a look at the arrow to open the application list and if it points to the right or left. If it points to the left, NO GPU is available - if it points to the right (as on the hardware phone itself) the GPU is available and rendering should work as expected.
See also this page in the msdn.
You haven't said if you're testing a local/private page or one on the web.
Also test other pages on the web. Can you view anything or just your own page.
If you can't see pages on the public web then you have a networking issue
If you can see public pages but not locally hosted ones then you probably have a different networking issue. If you're on an actual device or the emulator will likely greatly affect this.
The other things it may are:
you're trying to view a page that is to compilcated to be displayed (if there is such a thing - test with a very simple static page first)
the page uses useragent detecction and doesn't recognise the user agent and so is serving nothing
the page has complex javascript which runs before the page is rendered and the javascript is failing and so the page is never displayed.
I have an app on the android market, which uses the mapview to display some locations. This works fine on all the devices i have tested it on. After having it on the market for a while, i see several people reporting a problem.
The mapview does not seam to display/load the tiles on the map, and only displays the gray grid. All the people reporting this, are using a HTC Desire/Desire Z/Desire HD.
I have searched for this problem, and seen many having problems with their mapview, and they often have a HTC desire, but i have not found any mention of it being caused by the Desire phone.
Does anyone have a clue to why people with Desire phones are having problems with the mapview, when it works fine for others?
I've downloaded your application and tested it on my HTC Desire with MIUI, and as you said the mapview is not loading the tiles on the map.
FYI the application gives the following error:
IOException processing: 26
java.io.IOException: Server returned: 3
at android_maps_conflict_avoidance.com.google.googlenav.map.BaseTileRequest.readResponseData(BaseTileRequest.java:115)
at android_maps_conflict_avoidance.com.google.googlenav.map.MapService$MapTileRequest.readResponseData(MapService.java:1473)
at android_maps_conflict_avoidance.com.google.googlenav.datarequest.DataRequestDispatcher.processDataRequest(DataRequestDispatcher.java:1117)
at android_maps_conflict_avoidance.com.google.googlenav.datarequest.DataRequestDispatcher.serviceRequests(DataRequestDispatcher.java:994)
at android_maps_conflict_avoidance.com.google.googlenav.datarequest.DataRequestDispatcher$DispatcherServer.run(DataRequestDispatcher.java:1702)
at java.lang.Thread.run(Thread.java:1019)
Here you can find a question with the same problem, which seems related to the maps key.
As I said my Desire uses MIUI v1.10.28, with gingerbread, so the problem shouldn't be related to HTC's sense ROM... as it has been some time since you posted your question, do you have more information of the devices in which your application doesn't work?
I have made an update to the application, where i created a new maps api key, and it is working now.
I am not sure what caused the problem before, but i think they may have changed the type of key you have to submit for the maps key.
I have an old file where i had written a SHA1 Certificate fingerprint of the application and i am quite sure that it is the one i used to get the old maps api key. Maybe they changed something along the way, that caused it to fail on most phones?
Anyway, creating a new maps key from an MD5 Certificate fingerprint fixed it on every phone i have tested with.