I am building a game in Cocos2d-iPhone, and while I was updating to iOS 6, I noticed that Apple changed the way Game Center authentication is done, using authenticateHandler instead of authenticateWithCompletionHandler.
I added the new authentication method, but the game now crashes if a player is not already logged in to Game Center. There is no problem authenticating if a user is already logged in.
Here is my code:
if(SYSTEM_VERSION_GREATER_THAN_OR_EQUAL_TO(#"6.0"))
{
GKLocalPlayer *localPlayer = [GKLocalPlayer localPlayer];
localPlayer.authenticateHandler = ^(UIViewController *viewController, NSError *error)
{
if (viewController != nil)
{
AppController *appDelegate = (AppController*)[UIApplication sharedApplication].delegate;
[delegate.viewController presentViewController:viewController animated:YES completion:nil];
}
else if (localPlayer.isAuthenticated)
{
NSLog(#"Player authenticated");
}
else
{
NSLog(#"Player authentication failed");
}
};
}
It seems like it's crashing when trying to present the Game Center viewController, even though I use the exact same code to present the GKTurnBasedMatchmakerViewController with no issues.
Any help would be much appreciated.
EDIT:
Here is the exception getting thrown on crash:
Uncaught Exception UIApplicationInvalidInterfaceOrientation: Supported orientations has no common orientation with the application, and shouldAutorotate is returning YES
Here you can find useful information about your crash, I think it is the underlying reason.
https://developer.apple.com/library/ios/#releasenotes/General/RN-iOSSDK-6_0/_index.html
Apps should provide the delegate method application:supportedIntefaceOrientationsForWindow and ensure that portrait is one of the returned mask values.
I added below code to fix this crash.
- (NSUInteger)application:(UIApplication*)application supportedInterfaceOrientationsForWindow:(UIWindow*)window
{
return UIInterfaceOrientationMaskAllButUpsideDown;
}
Had similar issue, I was testing the isAuthenticated and authenticateHandler from within viewDidLoad, kept crashing when trying to present the Game Center View whilst in the middle loading the current view. I moved this test into viewDidAppear
(void)viewDidAppear:(BOOL)animated{
it works fine now...
Also for ios 6, Game Center will only prompt a non authenticated user once, if they decline to sign-in, it will disable Game Center for that app, the user will then have go into Game Center to log in.
Related
I'm new to Jetpack Compose, so I'm struggling to implement a feature which is dynamic colors (and font, size,... but I think they are the same so I'll just focus on color) at run time from backend. I'll let the app the some default colors, and a whole default splash screen just to load the colors setting from the backend. In case the API request failed, it would use the last succeeded requested colors or just the default color.
Tutorials I found round the internet was just about changing the dark/light theme at run time, not changing a specific color in the color pack. In those tutorials, the color is defined in Colors.kt file which is not a composable or class or object, ...
I imagine the color within lightColors or darkColors would be something like this.
return lightColors(
primary = Color(android.graphics.Color.parseColor("#" + dynamicColorMap["One"])),
...
}
And when dynamicColorMap changes in the splashscreen, all screen later will have reference to the new value, but I don't know how to update its variable outside of a composable.
I thought of using DB to store the colors, but getting the data from DB is async, so it cannot be query in the default Colors.kt like var colorOne = DBManager.getColor("One"), I can run the async task in my splash screen before changing to the next screen but then the problem again is how to have a global state that my theme composable wrapper can have access to on every screen?
I just don't know where to start for these case.
Thank you for your time
EDIT:
I currently having the project structured in MVVM. For now, only one activity (MainActivity) is present, and inside that activity, the splash screen component or home screen or login screen,... are being navigated. So is it a good practice to create a viewmodel for the mainactivity screen, that can holds the color state for the theme?
Thanks #Maciej Ciemiega for the suggestion. I ended up structure my code like that.
In my MainActivity.kt I create a viewmodel for it.
val mainActivityViewModel by viewModels<MainActivityViewModel>()
MyTheme(mainActivityViewModel = mainActivityViewModel) {
initNavigationController(navController)
Surface(color = MaterialTheme.colors.background) {
if (mainActivityViewModel.appSettingsState.value.appSettings.colorsMapLight.size != 0
&& mainActivityViewModel.appSettingsState.value.appSettings.colorsMapDark.size != 0) {
navController.navigate(NavigationDestinations.homeScreen)
}
}
}
my initNavigationController function shows the splashscreen first. But it doesn't do anything. The getting app settings configuration is called in MyTheme composable via the mainActivityViewModel, and MyTheme will use the state from the viewmodel to define the theme, and the navController.navigate is based on the state as you guys can see in the if above.
I don't know if this is a good practice or not, or when my app grows it would be a mess or not, but at least it works for me. I tried with font styles too and it works like a charm.
I'm trying to get GPG C++'s invitation system to work correctly for an iOS game.
I tried to call RealtimeMultiplayerManager::ShowPlayerSelectUI() to open a dialog to select friends to be invited. However, the dialog doesn't show any friend, only "Auto-Pick" option. I have several Google test accounts in the same circle, and they are already listed as testers in Google Play Console. The game is still in development.
Does anyone know what wrong?
Thanks,
Here is the code:
m_gameServices->RealTimeMultiplayer().ShowPlayerSelectUI(1, 1, true,
[this](gpg::RealTimeMultiplayerManager::PlayerSelectUIResponse const &
response){
HQRemote::Log("inviting friends %d", response.status);
if (gpg::IsError(response.status))
{
handleError((BaseStatus::StatusCode)response.status);
}
else{
auto config = gpg::RealTimeRoomConfig::Builder()
.PopulateFromPlayerSelectUIResponse(response)
.Create();
createRoom(config);
}
});
Update 21/3/2016:
Friends finally appear on the dialog's UI after 3 days of development. Why there is a delay like this?
Try to check your RealTimeMultiplayerManager::ShowPlayerSelectUI method if you misconfigured something. Here is a sample snippet.
void Engine::InviteFriend() {
service_->RealTimeMultiplayer().ShowPlayerSelectUI(
MIN_PLAYERS, MAX_PLAYERS, true,
[this](gpg::RealTimeMultiplayerManager::PlayerSelectUIResponse const &
response) {
LOGI("inviting friends %d", response.status);
// Your code to handle the users's selection goes here.
});
}
You can also look into this Adding Real-time Multiplayer Support to Your Game documentation to check your configuration.
I'm migrating a Qt for iOS project to Qt 5.5. In iOS 5.1.1 at least, the app fails to start if you launch it with the device face up. An assertion displays an error in qiosscreen.mm at line 344. Here's the Qt source code function that is failing:
Qt::ScreenOrientation QIOSScreen::orientation() const
{
// Auxiliary screens are always the same orientation as their primary orientation
if (m_uiScreen != [UIScreen mainScreen])
return Qt::PrimaryOrientation;
UIDeviceOrientation deviceOrientation = [UIDevice currentDevice].orientation;
// At startup, iOS will report an unknown orientation for the device, even
// if we've asked it to begin generating device orientation notifications.
// In this case we fall back to the status bar orientation, which reflects
// the orientation the application was started up in (which may not match
// the physical orientation of the device, but typically does unless the
// application has been locked to a subset of the available orientations).
if (deviceOrientation == UIDeviceOrientationUnknown)
deviceOrientation = UIDeviceOrientation([UIApplication sharedApplication].statusBarOrientation);
// If the device reports face up or face down orientations, we can't map
// them to Qt orientations, so we pretend we're in the same orientation
// as before.
if (deviceOrientation == UIDeviceOrientationFaceUp || deviceOrientation == UIDeviceOrientationFaceDown) {
Q_ASSERT(screen());
return screen()->orientation();
}
return toQtScreenOrientation(deviceOrientation);
}
It displays an assertion at
Q_ASSERT(screen());
screen() must be returning 0, so screen()->orientation() is attempting to deference a null pointer. That screen() function is defined in the parent class, QPlatformScreen:
QScreen *QPlatformScreen::screen() const
{
Q_D(const QPlatformScreen);
return d->screen;
}
The constructor for that class initializes d->screen to 0:
QPlatformScreen::QPlatformScreen()
: d_ptr(new QPlatformScreenPrivate)
{
Q_D(QPlatformScreen);
d->screen = 0;
}
From the comments, I infer that d->screen is set at some point when the orientation is portrait or landscape, and then they fall back to that when it becomes face up / down. Since it is starting as face up, there is no prior good value to fall back to.
Has anyone else encountered this, or have a solution? Btw, I am not building from qt source and do not want to, so changing their code is not a solution for me if I can possibly avoid that.
I found that this only seems to be occurring when I launch the app from XCode or QtCreator. If I launch the app on the device the way it normally runs, this bug seems to be averted.
I have made a button so that when it's pressed by the user and a particular row(s) are selected it does something.
So far I have this:
if (pickerView selectedRowInComponent:0) {
[mailComposerTwo setToRecipients:[NSArray arrayWithObjects:#"email#blah.com",nil]];
}
It works on its own. But when I do the if statement multiple times it crashes.
An ways of making it work?
Any help appreciated, thanx.
The problem probably lies with your mail composer, not the picker view. When you show the composer, make sure that you only create it if it hasn't already created.
Also, make sure you release it after you show it:
MFMailComposeViewController *picker = [[MFMailComposeViewController alloc] init];
picker.mailComposeDelegate = self;
...[configure the picker]
[rootContainer presentModalViewController:picker animated:YES];
[picker release];
NSArray *finalList = [[NSArray alloc]init];
//put all your if statements
if (pickerView selectedRowInComponent:0)
{
[finalList arrayByAddingObjectsFromArray:#[#"email#address.com",#"second#address.com",...];
}
if (pickerView selectedRowInComponent:1)
{
[finalList arrayByAddingObjectsFromArray:#[#"another#address.com",#"fourth#address.com",...];
}
//end of if statements
[mailComposerTwo setToRecipients:finalList];
[self presentViewController:yourInitializedMessageController animated:YES completion:^{NSLog(#"message controller is presented");}];
This will do a single method call rather than continually reassigning which for some odd reason is causing your exception. presentModalViewController:animated: has been deprecated as of iOS 6.0? if not 7.0 I believe.
NOTE! Make the message controller a property of the main view controller. It is good practice so that it is not auto-released by iOS if you need to bring it back up. However if you use MFMessageComposer iOS will keep messenger allocated or running in a thread somewhere so initializing a view controller for it is quick.
I am trying to load a Nib from a C++ constructor with Objective C++. I have searched and found enough examples to get some code together but it doesn't display the window. Or any windows for that matter.
Here is an example of the contructor:
JokeSystem::JokeSystem() : fileSystem("/Library/Application Support/Jokes/")
{
try
{
randSystem = new RandSelect<std::string>
(fileSystem.getAllFileContents("%\n"));
}
catch (std::ifstream::failure)
{
NSWindowController * errorWindowControl = [[NSWindowController alloc]
initWithWindowNibName:#"ErrorWindow"];
[errorWindowControl showWindow: nil];
}
}
The purpose of the contructor is to load the contents of a directory into a string. What I am try to do is display the error window when the files fail to open.
ErrorWindow.nib has a single window with an OK button and a NSTextView for the error, I set up a NSWindowController in the nib and connected it to the window.
My only link has been that most examples show this [errorWindowControl showWindow: self];
rather than showWindow: nil but because this is a C++ constructor I it doesn't have self and this doesn't work.
If it matters this contructor is called from the awakeFromNib method of the MainMenu.nib's primary NSObject.
Thanks
A bit of an odd way to approach Cocoa. I would encourage you to step back, learn Objective-C and then write your application with an Objective-C based Cocoa UI layer on top of whatever backing store or model layer you have.
In any case, there isn't anything particularly wrong with that code (save for the odd design).
The first thing to check is the return value of -initWithWindowNibName:. Is errorWindowControl actually non-nil? If it is nil, then the NIB failed to load.
How are you writing the Cocoa application itself? Standard app bundle using Xcode, I hope?
Also, you shouldn't be hardcoding the path to /Library/Application Support/. Actually, your application shouldn't use that directory as the only storage location; many users won't have write access to that directory and won't be able to install your app without administrator access.