Exponea cant detect projectToken when using .plist init

jackjpark commented 5 years ago

Hi, I am initialising exponea with the below configuration

<dict>
    <key>authorization</key>
    <string>Token redacted token</string>
    <key>automaticPushNotificationTracking</key>
    <true/>
    <key>sessionTimeout</key>
    <integer>20</integer>
    <key>projectToken</key>
    <string>redacted project id</string>
    <key>projectMapping</key>
    <dict/>
    <key>lastSessionStarted</key>
    <integer>0</integer>
    <key>lastSessionEnded</key>
    <integer>0</integer>
    <key>autoSessionTracking</key>
    <false/>
    <key>baseURL</key>
    <string>https://api.exponea.com</string>
</dict>

I call: Exponea.shared.configure(plistName: configPath) with the above file

Then when I call Exponea.shared.identifyCustomer

I get a fatal crash on:

var request = URLRequest(url: URL(string: path)!) in the request factory

aswell as a print of 'ExponeaSDK ❗️ ERROR [Configuration.swift]:164 tokens(for:): No project token found.'

It would appear Exponea isnt reading the projectID from the config correctly? but it appears to be included in the request URL path just fine, so not sure if this is a bug?

Thanks

dominik-hadl commented 5 years ago

Hi @jackjpark,

can you please try removing the empty dictionary for projectMapping from your plist file?

<key>projectMapping</key> <dict/>

jackjpark commented 5 years ago

Hi @jackjpark,

can you please try removing the empty dictionary for projectMapping from your plist file?
<key>projectMapping</key> <dict/>

Thanks, tried this but it hasnt resolved the crash on that URL force unwrap line, the Exponea error line seems to have disappeared from the debugger though if thats of use.

Interestingly, the code will execute beyond the force upwrap if i breakpoint, but when it crashes it always shows that line as the error

dominik-hadl commented 5 years ago

@jackjpark thanks for a quick answer. Could you please tell me what device and iOS version are using?

jackjpark commented 5 years ago

@jackjpark thanks for a quick answer. Could you please tell me what device and iOS version are using?

This is on the xcode simulator, any device. iOS 12

dominik-hadl commented 5 years ago

@jackjpark Actually, now looking the config one more time - can you try changing the baseURL key to baseUrl instead?

        <key>baseUrl</key>
    <string>https://api.exponea.com</string>

jackjpark commented 5 years ago

@jackjpark Actually, now looking the config one more time - can you try changing the baseURL key to baseUrl instead?
        <key>baseUrl</key>
  <string>https://api.exponea.com</string>

no luck im afraid, same result as above

dominik-hadl commented 5 years ago

@jackjpark Hmm, strange, I was convinced this would do the trick. Ok, let me investigate a bit more.

jackjpark commented 5 years ago

@jackjpark Hmm, strange, I was convinced this would do the trick. Ok, let me investigate a bit more.

No problem, i believed i had it working when i used the Configuration object, but wanted the .plist method for simpler management and then ran into this issue

jackjpark commented 5 years ago

@nickskull Hi where there any further findings on this yet? as its holding up our integration, cheers

dominik-hadl commented 5 years ago

@jackjpark Hi, I apologise, this has been deprioritized as we thought you were able to use the code based integration. We will look into this today.

jackjpark commented 5 years ago

@nickskull no worries, we need to log our users into the customer feature, and we cant do so due to this issue (as we cant initialise the SDK)

dominik-hadl commented 5 years ago

@jackjpark Are you getting the same issue when initialising using code? Ie. by calling:

Exponea.shared.configure(projectToken: token, authorization: auth, baseUrl: baseUrl)

jackjpark commented 5 years ago

@jackjpark Are you getting the same issue when initialising using code? Ie. by calling:
Exponea.shared.configure(projectToken: token, authorization: auth, baseUrl: baseUrl)

Its held as a lazy var and inits when the identifyUser method is called, will it need separate initialisation before hand?

edit: after switching to init on startup and removing lazy, it will still crash when trying to log user, but not on its intial startup

dominik-hadl commented 5 years ago

You should ideally initialize before hand, but it shouldn't be necessary. The reason why it crashes is definitely because it either can't parse the base url properly or somehow the URL is getting malformed. I'm looking into it now.

dominik-hadl commented 5 years ago

@jackjpark I have just tried with the exact same setup you have and it does not crash. Could you try and reproduce the error in a new project? I am wondering if you could have somehow altered the SDK behaviour by some extensions or swizzling?

dominik-hadl commented 5 years ago

Also, when the crash happens, could you try and e print(path) in the debugger or copy the value from the property inspector?

jackjpark commented 5 years ago

Also, when the crash happens, could you try and e print(path) in the debugger or copy the value from the property inspector?

I wont have time to create a new project any time soon, but the print out of the crash is

"https://api.exponea.com/track/v2/projects/<d47ab19e-2af0-.....REDACTED...>/customers"

ive removed the last few digits as to not publicly leak out project ID!

dominik-hadl commented 5 years ago

Ok, so the issue here are the < and > signs around the project token. Are you sure that in your .plist file the token is written without these signs?

jackjpark commented 5 years ago

Ok, so the issue here are the < and > signs around the project token. Are you sure that in your .plist file the token is written without these signs?

yeah i thought that was a likely issue, but no, in the source code of the plist it reads as so

<string>d47ab19e-2af0-.....</string>

dominik-hadl commented 5 years ago

@jackjpark Do you have any custom PropertyListDecoders or somehow alter the Codable behaviour in your application? Are there any extensions on Strings or similar that could alter the behaviour of the parsing in ExponeaSDK?

jackjpark commented 5 years ago

@jackjpark Do you have any custom PropertyListDecoders or somehow alter the Codable behaviour in your application? Are there any extensions on Strings or similar that could alter the behaviour of the parsing in ExponeaSDK?

we use sourcery to generate with AutoCodable from other plist files, but this shouldnt touch the SDK or its plist in any way, there are no references to the plist or its properties anywhere else but when its parsed into Exponea.config

dominik-hadl commented 5 years ago

@jackjpark Could you upload the actual plist file you use without the tokens/auth for me?

dominik-hadl commented 5 years ago

That's why I wrote without the project ids/tokens :) But you can also email it to me at doha (at) nodesagency.com.

jackjpark commented 5 years ago

sent you the file via email

dominik-hadl commented 5 years ago

@jackjpark I have just tested by using that exact file without any modifications and it worked flawlessly. I believe it must be some of your app's code interfering with the default PropertyListDecoder or Codable default implementation. Could you please double check that some of the tools or dependencies you're using are no interfering or overriding this. I'm afraid that the only solution I can recommend to you at this point is to configure Exponea from the code and not use a plist as that should work without any issues and shouldn't holdup your integration.

jackjpark commented 5 years ago

@jackjpark I have just tested by using that exact file without any modifications and it worked flawlessly. I believe it must be some of your app's code interfering with the default PropertyListDecoder or Codable default implementation. Could you please double check that some of the tools or dependencies you're using are no interfering or overriding this. I'm afraid that the only solution I can recommend to you at this point is to configure Exponea from the code and not use a plist as that should work without any issues and shouldn't holdup your integration.

i will investigate further and come back to you with the findings, thanks for your time

jackjpark commented 5 years ago

Hi @nickskull I have revisited this today and decided to remove the plist from the equation and init the instance with the following, however the issue with the <> in the path when trying to identify users persist despite no longer using the plist, using the below results in the same issue:

Exponea.shared.configure(projectToken: "d47ab19e-2af0-11e9-81cd-xxxxxxxx", authorization: .token("nnakfpujobb07fzre8kp6mlcuv0khsa77wwzr6d22xxxxxxxxxxx"))

dominik-hadl commented 5 years ago

Hi @jackjpark, this is very interesting and strange at the same time. Could you please try downloading the SDK and running the example project and see if the same issue is happening there?

jackjpark commented 5 years ago

@nickskull Ok, ive resolved the issue. So the SDK caches the .plist values, i noticed this when i deleted the projectID and it was still present in the path string. So it looks like it had cached an old version of my plist when i had the <> tags in it. Clearing the app from the devices and reinstalling from scratch picked up the new value and worked. Seems unnecessary to cache? as it caused quite a long issue to resolve here

dominik-hadl commented 5 years ago

@jackjpark That is the iOS caching the file, not the SDK (there is 0 code for caching plist files). :) It's common if you add a file and then remove it/change it that it doesn't reflect that, so almost always it's better to remove the app from the device and install again, somehow the copy files phase is broken sometimes. It is strange it was using the plist file when you switch to initialising using code though, could it be that you left the configure(plistName:) somewhere in the project after the code initialiser?

Anyway, glad that you resolved it and closing the issue.

jackjpark commented 5 years ago

@nickskull ah fair enough, a good learning point regardless then. No i totally changed the initialiser so that is an odd behaviour, but all is working now regardless. thanks for your time and assistance

exponea / exponea-ios-sdk

Exponea cant detect projectToken when using .plist init #3