in iOS7 I was able to set the MPNowPlayingInfoCenter.nowPlayingInfo with the standard stuff (making sure I had an AVAudioSession, with the category AVAudioSessionCategoryPlayback). Everything worked fine. Now with the update to iOS8, the information gets flashed on the screen and then resets to nothing. (The exception is when I first start playing the audio file, and set the data, then lock. If I don't touch anything, then the information stays on screen). I store a dictionary with all the key/values that the info center requires, and see that they contain the correct values when any changes need to be applied (eg if the user taps play/pause, skip buttons).
edit: if I take out my code that updates the info center after play or pause are tapped, the info center is cleared regardless (and I don't have any code that does that). I've gotten around this by dispatch_after with a 200ms delay to adjust the playback rate in the info center. This adds back in everything, however the fact that it's clearing it seems to be a new ios8 bug that I am not properly handling. This is on an iPad 2. :#
Related
The issue.
The mouse keeps escaping the full-screen whenever I either jump, move, rotate the camera or keep spinning to the left. But only on the left side of the screen, not the right, not the middle, not beneath, only on the left side.
This has happened in other unreal engine 5 games as well, but not in every single one of them.
What I've tried so far is:
Disabled Set bSHowMouseCursor nodes. [No effect.]
Set an Event BeginPlay > Set Input Mode Game only > Get Player Controller > Set SHow Mouse Cursor (Unchecked) [No effect.]
Created a new template (A blank one), then packaged it for testing. [Mixed effects. It slightly reduced the rate the mouse showed on the left side of the screen.]
Set an Event BeginPlay > Set Input Mode Game and UI > Get Player Controller > Set SHow Mouse Cursor (Unchecked) [Mixed results - I had to hold right click in order to move the camera, in which case, the mouse stopped showing, but as soon as I released it, the left mouse not only did appear as well, but the camera could not be moved and the cursor appeared permanently on the left side of the screen.]
Changed both the software and hardware cursors. But the cursor is unchanged. So it's not the game's cursor that appears in-game. It's the actual windows cursor.
I tested every option in the Default Viewport Mouse Lock Mode.
Deleted both Saved and the Intermediate folders.
Someone told me it has something to do with how the mouse is locked (or not) on viewport. And that, that might be the reason behind the cursor leaving escaping full-screen.
I don't have two monitors. The game is in full-screen. The issue persists in windowed mode as well. No widgets.
Tested it in packaging and in a Standalone game. (Issue persisted.)
The issue happens only if I click the left mouse button. If I play the game without clicking it, the cursor does not appear in-game.
Update:
It appears like going to the game's exe's compatibility and changing the high DPI settings' scaling behavior to application fixes the problem but reduces the fps. This is a temporary fix but I need a permanent one.
This is a weird issue.
What is on your left side desktop?
Do you use any apps that have an overlay?
If you have any apps try to disable them temporarily at startup from task manager, restart and check again.
In UE5, have you tried setting the mousecapture to true, especially in fullscreen.
Sometimes the mouse can escape...
Are you using a standard resolution/aspect ratio?
Some non standard resolutions and aspect ratios can change the way the base OS responds to captured/non captured input.
There are some controls on windows phone that behave different on the first interaction with them than on subsequent ones. e.g. a button control takes about 3-5 seconds to initialize the required action the first time the button is pressed, however on subsequent clicks it works immediately.
Another usercontrol that adjusts its height based on the key press doesn't adjust properly the first time, however the second time it works.
Is there a way to either prepare the controls, i.e. set them in a ready state so that all the clicks behave the same, or can first click can be faked to bypass this annoying behaviour?
Also what is causing this problem?
NB:- I am testing on a Lumia 520 device.
Unfortunately There is no way to prepare the controls. Nokia Lumia 520 comes in Lower Memory Device So Its behaviour seems slow at loading first time in memory and there are so many Background tasks also runnig at a same point of time. You should try it in Higher Memory Device and see the Behaviour.
I found out from this app performance document why it was happening , http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff967560(v=vs.105).aspx#BKMK_Applicationstartup.
I have a loading panel that is set to collapsed by default and only set visible once the button is clicked. According to the document, elements in collapsed state arent added to memory, so this means the first time it needs to initialize the panel and it doesnt need to in subsequent tries.
The other UI control behaving weirdly was also due to its parent's height not being adjusted after its own height is adjusted the first time, so adjusting the parent height as well fixed it.
I need to change the Background Image of my Application if user changes theme from "Light" to "Dark" or vice-vesa in code behind. I hope these should be done in Page Loded event
#TimDams pointed you to one of the nice ways to detect what-theme-is-now-set, but I didn't notice there any information how to detect a change to the theme during the application runtime. The user could start your app, then bump forward to the menu, change the theme, and get back to your app. While you may think that your app will be tombstoned and then restarted and renavigated to your page with full cycle with all pageloads -- it is not 100% true.
Firstly, the PageLoaded is NOT a good place to do the initial check-and-set-styles, because, if you get that event called, then the page, probably, has already rendered once. If I remember well, the PageLoaded is invoked just after the first render. If this is true, then you will have to detect the colors earlier, for example in the LayoutUpdated (warning: this event is a great spammer. I mean, it gets called gazillions times. Attach a single-shot handler, you know, such that will instantly unattach-self on first invocation). Maybe you will be able to do it in the Page's .ctor, just after InitializeComponent. Or in the OnApplyTemplate or MeasureOverride, or at least ArrangeOverride -- the visuals should be mostly/fully available there.
Buuuut. I've intentionally 'bolded-out' the word "initial". With Mango, there's some multitasking getting more and more common, but even the pre-Mango 7.0 version does not guarantee that your app will be tombstoned. From my observations in early 7.0, for example, starting the MediaPlayer from WebBrowser component does not tombstone your app:) If you have some time to read, check WP7 recover from Tombstone and return to page for details on the "pause" vs "tombstone".
Anyways, if your app gets "paused" and the user switches themes in the meantime, I think (I've NOT checked) that your page will (in most of the cases) be just temporarily hidden and upon returning to the screen, it will probably not be re-created and will not be re-(Page)Loaded. If it is true, then you will have not so easy problem to solve, because your app may be paused, the OS rethemed, and your app unpased virtually in any moment of time and the only events you will get in the mean time are .... global events of App.Deactivated and App.Activated. It is possible that completely none of per-page events will fire [but I've not checked - before you do anything I suggest below, CHECK IT].
If this pessimistic view is really true, than in those events, you will have to detect the current theme (->Tim's post), then somehow inform your current Page that themes changed - or not. If you have your ViewModel at least a bit separated from the rest of the app (as it should be:) ) you have an easy option to do it: create in that ViewModel a set of properties (dp or inotif) like Brush Background, Brush Foreground, Brush Hightlight, and other that you need, and instead of harcoding colours in your XAML - bind to those properties. You may event want to create a separate class for all those many Brushes and other Styles, let's say "pub class MyCurrentAppTheme" and keep that props there, and expose such object from ViewModel - whatever. Just Bind your colors to whatever -- but whatever that will be "logically global" and that will be easily accessible from the App.Acticated event handler. Having that done, in the App.Activated, detect the current theme and if changed, so through all the colors kept in VM and set them appropriatelly. Voil'a, whole your App gets recoloured properly.
But mind that still - there might be some transient blinks and flashes between the rendering of cached old theme, refreshing databound objects, and redrawing fresh theme. I hope not, but I sense it may occur, especially when returning from fast-switch tool (long back press): I think that the device captures the 'last screenshot' of your app in the backbuffer and uses that throughout all the time the app is 'minimalized' to do transitions animations, to show the fast-app-switch overview and so on.. again, I've not checked, but I doubt that during such animations the pagecontents are 'live', it could be very demaning on CPU/GPU resources. Any one knows anything on that? It could be a nice test to have some looping animation on the page and then to switch out and check in the fast-switch overview, whether the animation moves or is halted!:)
If your application is tombstoned, all your controls will be recreated and the new theme will be applied. If you'd like to manage your light/dark specific styles in a similar vein to normal themes, you might want to take a look at a custom ResourceDictionary I blogged about a while back.
Unfortunately, as of Mango there, is a bug (?) related to fast application switching that causes the theme to remain unchanged in your application. The bug is outlined in this question and its linked posts:
Is there a bug when changing themes when app is deactivated and reactivated in Windows Phone Mango
My ResourceDictionary is still useful for the initial startup but it appears, unfortunately, that nothing can be done to workaround the Mango bug.
For this no event exists. You need to figure this out manually by comparing the PhoneBackgroundBrush color to see if the user has the dark or light theme and compare it with your last stored value.
Were you able to do some test on the App.Activate - Deactivate?
I decided to use a different path to solve the issue of dynamic theme change.
I've assigned to all text and buttons only system resource colors.
For the icons inside the buttons in the window instead of using PNG images-icons I used the in XAML and assing it a Foreground color from system resource.
For the buttons in the SystemMenuBar there is no issue as they are always on a dark gray background so the black PNG images work just fine.
Hoping this helps.
You can check if the dark theme is in use with this simple check:
public static bool CurrentThemeIsDark
{
get
{
return (Visibility)Application.Current.Resources["PhoneDarkThemeVisibility"] == Visibility.Visible;
}
}
I have a ContentPresenter that switches between 2 states ("editor" and "viewer"). The states have different heights and different values of Content and ContentTemplate properties.
In one state change I resize the control by playing a Storyboard and in reaction to Storyboard.Completed event I change Content/Template properties.
It works basically ok, except I observed occasional flickering. When playing in debugger I observed that modifying above properties in Completed handler may cause strange screen effects (portions of the screen empty, extra shading, lines etc.) that the user observes as flickering.
However, whenever I postponed the ContentPresenter changes by using Dispatcher.BeginInvoke(), the problems seem to disappear. (More testing needed.)
Anyone has an explanation? On the web you'll find numerous code examples that perform UI changes in Storyboard.Completed handler, hence I find it a bit strange.
I suspect it may be more due to timing than needing to be on the UI thread. Try doing a Sleep for a second or so before changing the Content/Template properties instead of using Dispatcher.BeginInvoke(). If the flicker is gone then perhaps trying to change those properties while the Content was busy resizing itself during the storyboard was the culprit - perhaps assigning a fixed size or otherwise disabling the constant resizing during the storyboard would help. That's just a guess though, I'd have to see a sample to really figure it out. If you can make a small sample to reproduce it I'd gladly look at it.
I really enjoy using RBSplitView, an open source replacement for NSSplitView, but I have a problem in my shipping app and am experiencing it again in a new project.
The problem is I'm telling the RBSplitView to autosave its position state by giving it an autosave name. When my app launches the RBSplitView doesn't seem to honor the saved state till a second after the window is drawn.
I've spent the night trying to debug the behavior but have had little success. Anyone out there use this lib and have some advice?
You can scrub this quicktime movie to the issue at work:
http://media.clickablebliss.com/billable/interface_experiments/rbsplitview_delayed_autosave_reload2.mov
I've still been unable to figure out why this is happening but I do have a workaround.
First, make sure your main window is not visible at launch and then at the end of applicationDidFinishLaunching in your app delegate add something like:
[mainWindow performSelector:#selector(makeKeyAndOrderFront:) withObject:self afterDelay: 0.1];
The delay is the key. If you just tell the window to makeKeyAndOrderFront: I still see the issue. However as long as it has a beat of time it looks good.
This likely is happening because the RBSplitView instance needs to wait until it's first moment to get to set its frame to the autosaved value, which happens to be after the user can see it. This 0.0-delay trick simply delays showing the window until the very next runloop, which gives the split view a chance to do its magic (and other views) so that when the user sees the window, it's already nice and sexy. So just do the delay at 0.0 and you'll be fine.
I have a similar, but slightly different workaround in my app that uses RBSplitView. In applicationDidFinishLaunching:, I call adjustSubviews on the split view before calling makeKeyAndOrderFront: on the window that contains it. This seems to knock the split view in to order before it gets displayed on the screen.