Closed kbshl closed 4 years ago
@kbshl The log messages look fine, do you have a stack trace on whats crashing?
We are actively updating our plugin to use latest titanium and airship SDK versions. Now that ti is supporting gradle and maybe cocaopods it should be easier for us to keep this plugin up to date.
Instead of a brand new plugin, once we get the SDK updated to latest you could submit PRs to this plugin for missing functionality? With the update, we are planning on adding:
You can track our progress in this branch next. So far we only have Android updated but iOS PR should be coming soon. If you could tell us which features you are trying to use we can prioritize them.
@rlepinski, sadly there is no crash log nor an error. It just sticks after app launch with the provided logs. Even if I launch the Titanium app via the generated Xcode project, there is no crash or warning logged.
Cocoapods is also supported by Titanium, Carthage just feels easier for me. But both should be fine to use. I've seen multiple other Titanium Modules using Cocoapods.
I've created a brand new plugin to ensure a clean state regarding the Xcode project setup and the possibility to build it on Github Actions, not to provide my module as an alternative. So you're right PRs should be the way to go to contribute my adjustments.
The main features I needed are
Event listeners for
UAChannelRegistrationFailedEvent
): https://github.com/kbshl/titanium-airship/blob/2c488599f08669f73535f428ac370bca059dc58a/ios/Classes/TiAirshipModule.m#L79notificationRegistrationFinishedWithAuthorizedSettings:(UAAuthorizedNotificationSettings)authorizedSettings categories:(NSSet *)categories status:(UAAuthorizationStatus)status
): https://github.com/kbshl/titanium-airship/blob/2c488599f08669f73535f428ac370bca059dc58a/ios/Classes/TiAirshipModule.m#L188notificationAuthorizedSettingsDidChange:(UAAuthorizedNotificationSettings)authorizedSettings
): https://github.com/kbshl/titanium-airship/blob/2c488599f08669f73535f428ac370bca059dc58a/ios/Classes/TiAirshipModule.m#L201A method to trigger a registration update ([[UAirship push] updateRegistration];
)
Some tag related methods like
Some auto badge related methods
Thank you for the quick reply!
Could you give me more info on how you are using the Channel Registration Failed
event and updateRegistration
?
I'm using the Channel Registration Failed
event just to determine if initialization finished and was successful or failed. Otherwise, I do not have any event/callback that gives me the insight of a failed registration.
I use updateRegistration()
after multiple updates via addTags
/removeTags
and on network change. I could of course handle this using the supplied tags
property, but then I would implement the logic to remove/add tags in the Javascript Layer, which is basically not necessary since the Airship SDK already includes/provides this functionality.
I would like to avoid the updateRegistration if possible so for grouping tag updates I created a proxy for tag edits:
var editor = Airship.createChannelTagsEditor()
editor.addTags("foo")
editor.addTags("rad", "neat", "woot")
editor.removeTags("rad")
editor.applyTags()
When applyTags is called it will set tags and update registration.
@rlepinski, I've seen your last changes, looks great 💪
Updating the tags via the tags editor looks good and can be translated to the native SDK docs.
Thank you for your recent effort!!
Just two last questions/requests:
Would you mind exposing the deviceToken
and registrationToken
as props of the module? We are using them in our backend services.
Android related: Currently I'm using UAirship.shared().getAnalytics().isAppInForeground();
exposed as a property on the module to determine if a push is received in back/foreground. Reason: The push received event was triggered in fore- and background. Would it be an option to expose it as a property on the event object? Or do you have a recommendation for another solution?
@kbshl Thanks for the feedback.
I can expose a pushToken
but I don't have a callback for when it's available on Android, so you will have to piggy back off channelUpdated
if it initially comes back null. I will consider adding it to the underlying SDK so we could expose an event in the future.
I can add a receivedInForeground
or whatever better named property on the push received object. How are you responding differently in those cases?
Finally, I wont be able to do a channel update failed. We moved away from exposing that info in Android since it confused devs thinking they needed to do something when they didn't since the SDK handles all retries. Could you explain more what you are doing in that event so I can suggest an alternative?
Going to close this issue. Next release will hopefully go out next week. Here is the updated interface: https://github.com/urbanairship/titanium-module/blob/master/documentation/index.md
If you want to test on your machine, run make build
or make install
Ok, I understand, thanks for the explanation.
Great! Currently, if the notification is received in background I do nothing, in foreground or on notification click I display a custom in-app message view.
Ah ok, definitely the right decision.
In the app I'm doing the user notification enablement/tag subscribing in one step. I've built a wrapper, that does user notification enabled, waits for the registration success/fail event, then setting the tags. This process is the "user subscription".
What does the native SDK do if the registration fails but I'm setting the tags anyways? On which event the native SDK runs the registration retry?
I had a look at the updated interface, looks great. At this point, I want to thank you for the regular updates, your ongoing feedback and the great support!
Setting tags on the user is fine, we track tags and notification opt-in status differently. You can set tags on an opted out channel and its fine, you still wont be able to notify them. If the channel fails, it automatically retries for you. It is supposed to be a set and forget type of model.
I added this method - https://github.com/urbanairship/titanium-module/blob/master/documentation/index.md#enableusernotificationscallback that will tell you if user notifications where enabled with a callback. Sounds like its a better option than checking channel registration failures.
Ok, I understand, good to know, thanks for the details.
You're right, I will go this way and change our implementation to use enableUserNotifactions()
.
Thanks!
Hi @rlepinski,
first I apologize for not getting back to you in #31. I've got deadlines and forgot to answer your question 😞 But I've tested your build and it works like expected.
I would like to ask if you can help me with an updated version of the iOS Module that I made with Airship iOS SDK 13.3.1 and Titanium SDK 9.0.2.GA.
I have made a completely new module with Carthage, Titanium SDK 9.0.2.GA and Airship iOS SDK 13.3.1. Additionally, I've added more Public APIs, most in sync with the React Native Airship module.
You can find it here: https://github.com/kbshl/titanium-airship
Sadly I've got the same issues like in #31. I can build the module successfully on my Machine and on Github Actions. But if I run a sample app with one of the builds the app sticks on Splash Screen / App launch.
I've tried everything like completely removing Xcode and reinstall it, but nothing helps nor an error message is thrown on the app run.
Also I've built the current iOS version of this repo on my machine with the same result as in #31. It's really strange and feels like something is missing in code/configuration.
I would really appreciate it if you could have a look and maybe build the module from https://github.com/kbshl/titanium-airship on your machine. Maybe I'm missing something in the Xcode configuration or other things.
A sample app can be found in the
sample
dir. You just need to replace the Airship Keys intiapp.xml
.I've seen you are working on an update of the Android version of the module. If you like you can use the whole code of my repo for your iOS update, feel free.
Thank you for your time in advance!
Simulator Logs
My environment