ERROR: Default initialization in UANotificationAction.h

After updating from 8.1.4 to 8.3.3 (iOS), I'm receiving this error at compile:

UANotificationAction.h:30:42: Default initialization of an object of const type 'const UANotificationActionOptions' (aka 'const unsigned long')

The line in question:
static const UANotificationActionOptions UANotificationActionOptionNone NS_SWIFT_UNAVAILABLE("Use [] instead.");

The latest version of the SDK I'm able to get working is 8.2.2. From the distribution, we only update with the files in the Airship folder, completely replacing:

  • AirshipResources.bundle
  • The `Headers` folder
  • libUAirship*.a

The migration guide for 8.x to 8.3.0, doesn't appear to address this specific issue on our end.

Didn't find what you were looking for?

New post

Comments

20 comments

  • Hi engineframework,

    I think the UANotificationAction error might be a red herring.

    That class is nearly identical between 8.1.4 and 8.3.3, aside from a few added comments.

    This is most likely due to how your Xcode project is set up.

    Would you be able to let us know how you've set up your Xcode environment? Are you using Cocoapods, if so, would we be able to see your Podfile?

    1
  • Thanks for looking into our situation Michael,

    The overall project is quite big and includes many different third party SDKs. As a result we use a customized build system and don't follow any of the suggested methods for installing Urban Airship. We use libUAirhsip*.a and its headers directly.

    I did a bit more investigating and found that the problematic header is actually UAPush.h. I came to this conclusion by updating headers from 8.1.4 to 8.3.3 one by one until the project would no longer compile, then confirmed the culprit by reverting back to 8.1.4 and updating just UAPush.h by itself.

    1
  • Ah, gotcha. Sounds like you're good to go then?

    0
  • Unfortunately no, we still don't know why the problem emerges.

    1
  • Hmm...

    Would you be able to let me know how you're including the different headers in your app currently?

    It sounds like you're just using the static library, which should work under most normal circumstances, however there are some steps to be done to to include all the necessary headers. I'd be curious to know how you're doing it currently.

    0
  • We are also exhibiting this issue on first integration. We're trying to install via the Cocoapod into a mixed ObjC & Swift project.

    I believe the glitch is around the `static const` being declared in a .h file, without actually setting a value for it. 

    1
  • Would you be able to let us know how you've implemented the SDK into your app? And also your Pods file as well.

    0
  • We integrated our UA into our Podfile, setup AppDelegate (objc) with @import AirshipKit, and integrated the necessary code there.

    Podfile & NotificationDelegate: https://gist.github.com/charlesTR/d74c1f1b59e05d1c3fe3bb2875bbe039 

    To get delegate to work we tried two tactics, but got the referenced error both times.

    1. First we tried adding AirshipKit to our prefix header

    2. Then we tried adding AirshipKit to our bridging header via @import
    @import AirshipKit; 

    3. Then we tried adding AirshipKit using classic imports
    #import <AirshipKit/AirshipKit.h>

    4. Then we tried only importing the referenced headers from the integration guide
    #import <AirshipKit/[[headers referenced in the integration guide]]

    None of the above changes fixed anything, and the project still fails to build with the above referenced error.

    We also tried disabling any warnings relating to "constants" in Xcode. No luck there either.

    1
  • Do you also perhaps happen to have your Pods.xcconfig as well?

    0
  • Sorry for the absence from this thread! I'm not the original author of the code responsible for integrating UA, but from what I can tell the only headers we use (directly) are:

    • #import "UAirship.h"
    • #import "UAConfig.h"
    • #import "UAPush.h"
    • #import "UAInbox.h"
    • #import "UAAppIntegration.h"

    In that order.

    I viewed the diff between 8.1.4 and 8.3.3 for UAPush.h and in the newer version, UAPush now also imports UANotificationAction. I tried to trace the dependencies for 8.1.4 and as far as I can tell, our project previously did not depend on UANotificationAction, which would explain why we're only running into the problem now.

    1
  • @Michael I've added the Pods xcconfig in use to the Gist!
    https://gist.github.com/charlesTR/d74c1f1b59e05d1c3fe3bb2875bbe039#file-pods-xcconfig
     

    @engineframework nice insight, hopefully that will help.

    1
  • If I #import UANotificationAction into the project under 8.1.4, then I also get the same error as above. So it does seem that UANotificationAction is the problem.

    1
  • We have reimplemented our Swift delegate as Objective-C, and that solves the problem.

    This suggests that the problem is only when using AirshipKit from Swift projects. Hopes this helps!

    - Frederic Barthelemy

    0
  • Glad to hear you were able to solve your issue! However, our codebase only uses Objective-C so we can't apply the same solution :(

    0
  • Actually, we do use C++ so it could be a similar problem. We cannot however, transfer the C++ over to Objective-C.

    0
  • I've confirmed that this is an issue with mixing languages.

    Please see the linked Xcode project to see a reproduction of the issue. The project is just the standard iOS Single View Application Xcode-template, modified to include the Urban Airship SDK. AppDelegate.m was edited to #import UAPush.h, then renamed to have the .mm extension to switch the compiler to objective-c++.

    https://drive.google.com/file/d/0Bx3ISqcJJRGPRXRtM2xsenBueHc/view?usp=sharing

    Attempting to build will fail with the "default initialization" error. However, if you revert the extension of AppDelegate back to .m instead of .mm, or switch the file type to "Objective-C Source" in the file inspector, the compile will succeed.

    0
  • Hey engineframework,

    Looks like we'll be releasing a new update for the iOS SDK (8.4) sometime next week to address this particular error. Be on the look-out when this drops and let us know if that ends up resolving the error!

    0
  • Thanks for the heads up Michael!

    0
  • The error disappeared with the 8.4 update. Thanks for the support Michael!

    0
  • No problem!

    0

Please sign in to leave a comment.