EDIT: DEAR PEOPLE FROM THE FUTURE, trey-jones has fixed this issue by implementing setLoginBehavior, FBSDKLoginNative seems to have issues on FB's end not with the module.
Environment:
MacOS X 10.10.5
Ti SDK 5.1.1.GA - 5.1.2.GA
iOS 9.2
Ti.Facebook 5.0.0 - 5.0.1
My project settings (tiapp.xml) are fine (it works on every other case on both iOS and Android).
Code I'm using to invoke the login:
var fb = require('facebook');
fb.initialize();
fb.authorize();
If the Facebook app is installed to the device the fb.authorize() doesn't open up. I did not see any iOS system level messages when this happened either.
Has anyone else had luck using fb.authorize with the new sdk on iOS devices WITH the app installed. With no fb app on the system it correctly opens the browser based view.
EDIT: I have managed a workaround for this (it is not pretty) based on the fact that login works with AppC's KitchenSink.
The workaround is to add a Ti.FB loginButton to the code, doesn't matter if its not visible, initializing this will fix whatever is causing custom login's .authorize() to not work.
//Workaround button:
if(OS_IOS){
var fbHaxBtn = fb.createLoginButton({
readPermissions: ['email'],
visible: false
});
}
//It needs to be added to the window/doesn't need to be visible though
$.login_window.add(fbHaxBtn);
//Then in our custom button's code, we can fire as normal:
function doLoginClick{
fb.initialize(); //I was having unexpected issues dropping this line on Android, although the docs say its deprecated.
fb.authorize();
}
Will keep this ticket updated if/when this thing gets a formal fix.
This is my second answer on this question. I believe that my original answer offers some value to the conversation and that is why I am leaving it, but it still did not consistently solve the problem of the facebook authorization not working.
The consistent solution turned out to be modifying the official Ti.Facebook module. I will submit a pull request for this change (1 line), but for now, you can get the working module here:
Source
Pre-built
This consistently allows users to authorize by explicitly setting the login behavior to use the browser, rather than the native facebook app through fast app-switching. This is actually the intent of Facebook's developers.
I was unable to determine what is causing it to fizzle when trying to use the native app to login - it should try the next option, which is the browser - but this works, and doesn't require a TiFacebookButton either.
I hope it helps someone else!
EDIT: This answer does not solve the original question. I have left it here in case it helps with related difficulties using the Ti.Facebook module. See my other answer, to actually solve the problem. END EDIT
I commented above, but after doing so encountered some more strange behavior, with the result being that I could not reliably use the workaround given (fbHaxButton). I want to explain what was happening in my case, and show my own workaround (which is also not pretty). It's possible that the root cause is the same for both of us.
I have not bothered with Android yet, so this answer is specific to iOS.
When I started this process, I came to the conclusion that authorize was correctly opening the facebook website in safari to allow authorization, but was not firing the login event upon returning. To handle this I had already implemented the following:
facebook = require('facebook');
Ti.App.addEventListener('resumed', function (e) {
var launchOptions = Ti.App.getArguments();
if(!launchOptions.url) {
return console.warn('Ignoring resume event with no url argument.');
}
// this lib = https://github.com/garycourt/uri-js
var URI = require('vendor/uri'),
uriComponents = URI.parse(launchOptions.url),
expectedScheme = 'fb',
expectedHost = 'authorize';
// I would like to be more specific about the uri, but we are limited
// in Titanium, and this will allow us to pretty certain
// that FB is sending us back to our app
if(uriComponents.scheme.search(expectedScheme) < 0 || uriComponents.host !== expectedHost) {
return console.warn('Resume event received, but scheme is incorrect. Ignoring.');
}
// synthesize login event
facebook.fireEvent('myapp:login', {
success: 1,
token: facebook.getAccessToken(),
uid: result.id
});
});
facebook.addEventListener('myapp:login', function onFacebookAuth(e) {
facebook.removeEventListener('myapp:login', onFacebookAuth);
if(!e.success) {
// do fail action
}
// do success action
});
facebook.initialize();
facebook.authorize();
So, originally I was firing and listening for an event called 'login', which the facebook module supposedly (according to the docs) will fire after authorization is complete.
In my case, this event was being fired while my app was in the background, after authorize was called, but before the user actually clicked 'OK' in facebook. My listener would respond to this event (logging, etc), but seemed to occur in a separate thread, or somehow otherwise become disconnected from my app, as it never passed its result along to the UI. I am using Q.js (kriw-kowal) and I belive this is where the disconnect is occuring.
Ceasing to listen to 'login', and simply handling my own synthesized event has fixed my issue.
I felt that this was very difficult to explain. If you have feedback about that, and how I can be more clear about what I believe is happening, or if you believe that I have reached wrong or incomplete conclusion, let me know - I'll try to update this answer to be better.
Related
I'm watching a cloud firestore list for changes using query.onSnapshop in a react-native-firestore app, currently testing on iOS.
While my app is in the foreground, I can make data changes elsewhere (eg. in my companion web app) and the mobile app immediately updates as expected. Usually, if I make changes while the app is closed or offline, they get picked up no problem once it is re-opened or comes online again. Happy days.
However, sometimes, when the app is in the background (not closed, just some other apps have been used in the meantime), I'll make a change elsewhere (eg. add/delete a record which meets the query's criteria), then when I come back to the app, the list does not change - eg. it contains deleted records, or doesn't contain the new ones. Nothing I do on the app can change this - it remains out-of-sync, even if I make local changes, like editing one of the records (even a deleted one). Changing network conditions also does nothing (eg. switching airplane mode off/on again).
The only way the list will get back in sync is if I make another change elsewhere, while the app is still in the foreground, or if I force-close the app and re-open it again.
The issue seems to occur when connecting to both the emulator, and the actual firestore.
I don't think I'm doing anything fancy. Basically following the examples in the documentation:
import React, { useEffect, useState } from 'react';
import firestore from '#react-native-firebase/firestore';
const MyAssignments = (props) => {
const [records, setRecords] = useState([])
useEffect(() => {
const onSnapshot = (snapshot) => {
console.log(snapshot) // this IS triggered but data is stale
setRecords(snapshot)
}
return firestore()
.collection('assignments')
.where('assignedTo', 'array-contains', props.userId)
.onSnapshot(onSnapshot, console.error);
}, [props.userId]);
// render the list
return ...
}
I'm not sure if this is a general firestore issue, a react-native-firebase issue, an issue with the underlying firebase ios SDK, or just my own misunderstanding?
In either case, is there a way to force the local cache to re-sync programatically, ideally when the app regains focus? Or has anyone solved a similar issue or have any ideas what to try next?
Edit 1: Note the code example above is slightly simplified for readability, as parts are spread across a few files and typed with typescript. In reality, I'm using crashlytics.recordError(e) for error handling in production, but console logging, as above, in development.
Edit 2: To debug, I've tried the following:
Switch on debug logging:
import firebase from '#react-native-firebase/app';
firebase.firestore.setLogLevel('debug');
However, this gave no extra logs in my javascript console.
I found I could view native device logs by following this guide and then filtering for Firebase, like so: idevicesyslog --match Firebase
This still shows very few logs, so I don't think debug logging is switched on properly. However, it does log this error every time I foreground the app:
<Notice>: 8.9.1 - [Firebase/Firestore][I-FST000001] WatchStream (10c244d58) Stream error: 'Unavailable: Network connectivity changed'
This error happens every time though. Even when the onSnapshot successfully picks up changes
I tested:
UIControl().sendAction(#selector(URLSessionTask.suspend), to: UIApplication.shared, for: nil)
which is for putting app on background and it works.
How do I put app back on foreground?
I tried:
UIControl().sendAction(#selector(URLSessionTask.resume), to: UIApplication.shared, for: nil)
But eventually it crashes...
Thank you
Update:
Since you've indicated that you're looking for any technical solution, even those not compatible with the App Store or Apple's terms, this should be possible using the Private API LSApplicationWorkspace: openApplicationWithBundleID. Try something like this:
Create a .h file and set up an interface to the LSApplicationWorkspace class and list the required method. You will need to #import "PrivateHeaders.h" in your bridging header.
//
// PrivateHeaders.h
//
#ifndef PrivateHeaders_h
#define PrivateHeaders_h
#interface LSApplicationWorkspace : NSObject
- (bool)openApplicationWithBundleID:(id)arg1;
#end
#endif /* PrivateHeaders_h */
You should then be able to call this function and pass in the Bundle Identifier of your app as an string.
//
// SomeClass.swift
//
import MobileCoreServices
let workspace = LSApplicationWorkspace()
/**
Launch an App given its bundle identifier
- parameter bundleIdentifier: The bundle identifier of the app to launch
- returns: True if app is launched, otherwise false
*/
func openApp(withBundleIdentifier bundleIdentifier: String) -> Bool {
// Call the Private API LSApplicationWorkspace method
return workspace.openApplication(withBundleID: bundleIdentifier)
}
Original:
What you are doing is likely a violation of the iOS Human Interface Guidelines (although the "Don’t Quit Programmatically" is no longer specifically defined), so as the comments have said, it is not suited to the App Store. Regardless, once your app is suspended in this way, I don't expect that there is a way to resume it programmatically, unless you can hook into a Background Operation to run URLSessionTask.resume, but I have not tested it and am unsure whether it can work.
Apps can be launched (and hence brought into the foreground) programmatically from another app or today extension by using a Custom URL Scheme, or via a Push Notification. It isn't possible to launch the app from the Background Operation via a URL Scheme, since it is part of the UIKit framework, which must be run in the main thread.
In summary, I think your best option is to try to use a Notification. This just means that the user will need to click on the notification to bring your app back into the foreground.
Closing/opening the app should be done explicitly by the user. Any other way of closing or opening the app is not supported by Apple and will be rejected when uploaded to app store. iOS Human Interface Guideline states:
Don’t Quit Programmatically
Never quit an iOS application
programmatically because people tend to interpret this as a crash.
However, if external circumstances prevent your application from
functioning as intended, you need to tell your users about the
situation and explain what they can do about it. Depending on how
severe the application malfunction is, you have two choices.
*Display
an attractive screen that describes the problem and suggests a
correction. A screen provides feedback that reassures usersthat
there’s nothing wrong with your application. It puts usersin control,
letting them decide whether they want to take corrective action and
continue using your application or press the Home button and open a
different application
*If only some of your application's features are
not working, display either a screen or an alert when people activate
the feature. Display the alert only when people try to accessthe
feature that isn’t functioning
Just as a follow up to Jordan's excellent answer I want to give an explanation for why your code works in the first place and why that alone will get your app rejected, even without any functionality to make it active again and bring it to the foreground.
As maddy pointed out in a comment, you're basically calling a method from UIApplication's private API. This works due to the Objective-C runtime's dynamic linking. You might wonder "But I am using Swift, what does that have to do with Objective-C?" The answer lies in #selector mechanism. A Selector is basically just a symbol that the Objective-C runtime looks up in a table to get a method it invokes (for you). This is why it's technically not correct to say you "call a method" when you do something like myObjectInstance.someMethod(). The correct way to phrase that would be to "send a message" to the object, because that's what is happening in the runtime. The target-action mechanism is build around that. The sendAction(_: Selector?, to: Any?) method does the same thing. So in effect your code does the following:
Get the symbol that corresponds to URLSessionTask's suspend() method.
Tell the shared instance of UIApplication to invoke the method that it has for that symbol.
Now usually that would result in a crash with the typical "unknown selector sent to instance..." error message. But here, by sure coincidence UIApplication also has a method for that instance (or rather, the runtime also has one of its methods listed in its table for that symbol). You kind of "found" a method that is not declared in its public header. You successfully circumvented a compile-time check for this and invoke a method that is part of a private API. This is explicitly forbidden in the Apple Developer Program License Agreement
Besides all that, I would strongly advise against trying to design an app that way in the first place. As maddy pointed out it's also likely considered to violate the HIGs. Even if you're not trying to do anything malicious and properly explain the feature in your app's description, that won't make Apple let it slide (I assume). Personally, as a user, I'd also find it annoying if the app did something the system already has a specific mechanic for in a different manner, at least in terms of app's coming to background and foreground.
I don't think it can be done without user interaction
The option is you can generate a push notification to tell the user to bring the application to foreground
When the operating system delivers push notification and the target application is not running in the foreground, it presents the notification.
If there is a notification alert and the user taps or clicks the action button (or moves the action slider), the application launches and calls a method to pass in the local-notification object or remote-notification payload.
I tested:
UIControl().sendAction(#selector(URLSessionTask.suspend), to: UIApplication.shared, for: nil)
which is for putting app on background and it works.
How do I put app back on foreground?
I tried:
UIControl().sendAction(#selector(URLSessionTask.resume), to: UIApplication.shared, for: nil)
But eventually it crashes...
Thank you
Update:
Since you've indicated that you're looking for any technical solution, even those not compatible with the App Store or Apple's terms, this should be possible using the Private API LSApplicationWorkspace: openApplicationWithBundleID. Try something like this:
Create a .h file and set up an interface to the LSApplicationWorkspace class and list the required method. You will need to #import "PrivateHeaders.h" in your bridging header.
//
// PrivateHeaders.h
//
#ifndef PrivateHeaders_h
#define PrivateHeaders_h
#interface LSApplicationWorkspace : NSObject
- (bool)openApplicationWithBundleID:(id)arg1;
#end
#endif /* PrivateHeaders_h */
You should then be able to call this function and pass in the Bundle Identifier of your app as an string.
//
// SomeClass.swift
//
import MobileCoreServices
let workspace = LSApplicationWorkspace()
/**
Launch an App given its bundle identifier
- parameter bundleIdentifier: The bundle identifier of the app to launch
- returns: True if app is launched, otherwise false
*/
func openApp(withBundleIdentifier bundleIdentifier: String) -> Bool {
// Call the Private API LSApplicationWorkspace method
return workspace.openApplication(withBundleID: bundleIdentifier)
}
Original:
What you are doing is likely a violation of the iOS Human Interface Guidelines (although the "Don’t Quit Programmatically" is no longer specifically defined), so as the comments have said, it is not suited to the App Store. Regardless, once your app is suspended in this way, I don't expect that there is a way to resume it programmatically, unless you can hook into a Background Operation to run URLSessionTask.resume, but I have not tested it and am unsure whether it can work.
Apps can be launched (and hence brought into the foreground) programmatically from another app or today extension by using a Custom URL Scheme, or via a Push Notification. It isn't possible to launch the app from the Background Operation via a URL Scheme, since it is part of the UIKit framework, which must be run in the main thread.
In summary, I think your best option is to try to use a Notification. This just means that the user will need to click on the notification to bring your app back into the foreground.
Closing/opening the app should be done explicitly by the user. Any other way of closing or opening the app is not supported by Apple and will be rejected when uploaded to app store. iOS Human Interface Guideline states:
Don’t Quit Programmatically
Never quit an iOS application
programmatically because people tend to interpret this as a crash.
However, if external circumstances prevent your application from
functioning as intended, you need to tell your users about the
situation and explain what they can do about it. Depending on how
severe the application malfunction is, you have two choices.
*Display
an attractive screen that describes the problem and suggests a
correction. A screen provides feedback that reassures usersthat
there’s nothing wrong with your application. It puts usersin control,
letting them decide whether they want to take corrective action and
continue using your application or press the Home button and open a
different application
*If only some of your application's features are
not working, display either a screen or an alert when people activate
the feature. Display the alert only when people try to accessthe
feature that isn’t functioning
Just as a follow up to Jordan's excellent answer I want to give an explanation for why your code works in the first place and why that alone will get your app rejected, even without any functionality to make it active again and bring it to the foreground.
As maddy pointed out in a comment, you're basically calling a method from UIApplication's private API. This works due to the Objective-C runtime's dynamic linking. You might wonder "But I am using Swift, what does that have to do with Objective-C?" The answer lies in #selector mechanism. A Selector is basically just a symbol that the Objective-C runtime looks up in a table to get a method it invokes (for you). This is why it's technically not correct to say you "call a method" when you do something like myObjectInstance.someMethod(). The correct way to phrase that would be to "send a message" to the object, because that's what is happening in the runtime. The target-action mechanism is build around that. The sendAction(_: Selector?, to: Any?) method does the same thing. So in effect your code does the following:
Get the symbol that corresponds to URLSessionTask's suspend() method.
Tell the shared instance of UIApplication to invoke the method that it has for that symbol.
Now usually that would result in a crash with the typical "unknown selector sent to instance..." error message. But here, by sure coincidence UIApplication also has a method for that instance (or rather, the runtime also has one of its methods listed in its table for that symbol). You kind of "found" a method that is not declared in its public header. You successfully circumvented a compile-time check for this and invoke a method that is part of a private API. This is explicitly forbidden in the Apple Developer Program License Agreement
Besides all that, I would strongly advise against trying to design an app that way in the first place. As maddy pointed out it's also likely considered to violate the HIGs. Even if you're not trying to do anything malicious and properly explain the feature in your app's description, that won't make Apple let it slide (I assume). Personally, as a user, I'd also find it annoying if the app did something the system already has a specific mechanic for in a different manner, at least in terms of app's coming to background and foreground.
I don't think it can be done without user interaction
The option is you can generate a push notification to tell the user to bring the application to foreground
When the operating system delivers push notification and the target application is not running in the foreground, it presents the notification.
If there is a notification alert and the user taps or clicks the action button (or moves the action slider), the application launches and calls a method to pass in the local-notification object or remote-notification payload.
In a large app which uses Firebase extensively, I'm trying analytics,
-FIRDebugEnabled is set fine.
The date/time on the devices is set correctly.
I have tried all of simulator, tethered device, and even building through to TestFlight.
The needed stuff is in app startup ..
FirebaseConfiguration.shared.setLoggerLevel(.max)
FirebaseApp.configure()
// helps Analytics get going:
AnalyticsConfiguration.shared().setAnalyticsCollectionEnabled(true)
Again, Firebase realtime and database works perfectly throughout.
So using Analytics.logEvent# ...
Note that the items appear perfectly in Xcode console:
2018-07-24 08:27:23.868 Blah[7501] <Debug> [Firebase/Analytics][I-ACS023105] Event is
not subject to real-time event count daily limit. Marking an event as
real-time. Event name, parameters: select_content, {
firebase_event_origin (_o) = app;
firebase_realtime (_r) = 1;
item_name = tapMyProfile;
firebase_screen_class (_sc) = Blah.SomeScreen;
firebase_debug (_dbg) = 1;
firebase_screen_id (_si) = 8314738347840858914;
item_id = Blah-tapMyProfile;
content_type = tapMyProfile;
}
or ...
2018-07-24 08:56:12.393306-0500 Blah[7501:135963] [Firebase/Analytics][I-ACS023073] Debug
mode is enabled. Marking event as debug and real-time. Event name,
parameters: select_content, {
firebase_event_origin (_o) = app;
firebase_screen (_sn) = MyProfile;
item_name = tapCamera;
firebase_realtime (_r) = 1;
firebase_screen_class (_sc) = Blah.OldDevDotScreen;
firebase_debug (_dbg) = 1;
firebase_screen_id (_si) = 8314738347840858915;
item_id = Blah-tapCamera;
content_type = tapCamera;
}
Notice tapMyProfile or tapCamera, one of my custom events from Analytics.logEvent#
Analytics as such does seem to be working perfectly:
so, those numbers update every few hours etc.
Again every item appears perfectly in the Xcode console ..
But no matter what, nothing will show up on the Firebase debug console!
Nothing!
What the hell could the problem be?
(Additionally I have waited a day or more and they don't show up as events either.)
How can it be that just nothing is showing up in Debug???
TL:DR - Delete your app from your device / simulator, rebuild and launch from XCode.
I faced this exact same issue even though Firebase and Firebase Analytics in particular seemed to be set up perfectly.
I cannot give the exact logical explanation yet as to why this worked, however one hint came from this Firebase events tutorial at around 5 mins 30.
He mentions that the -FIRAnalyticsDebugEnabled settings get saved to disk.
So after configuring & integrating Firebase, I ran my app which was already installed to test everything works fine and it did but the Firebase Console did not show me any messages of app events.
It's good to double check that you are not using special characters when sending your events and also not going over the character threshold, however even if you make these errors, you should see default events of screen_open, app_open, user_engagement which were not showing up for me.
My only theory is that launching the app from an already installed state does not impact the new settings of -FIRAnalyticsDebugEnabled.
So when I deleted my app, re-build and run from XCode, the events start showing up.
Finally, while testing, you might use another device and you might wonder, I was seeing my events from the previous device but nothing happens for the next one which baffled me for a few moments, remember to switch the device
However, in conclusion, I can say this behavior is far from reliable and because after a period of time (2-3 hours) when I ran my app again, nothing showed up on the Firebase Console again as if -FIRAnalyticsDebugEnabled had been disabled.
Deleting and reinstalling worked again.
Update for 2022
The above steps still applies. Just 2 more additions of why you might not see events you seem to be logging successfully:
Do a clean + build + run
There are some keywords that seem to not get logged because they are probably already in use by the Analytics framework. For example when I was trying to track a search event and one of the keys in my parameters dictionary was keyword and this never seemed to get tracked so use something else and give it a go
Check your device's time setting. Time needs to be accurate.
Did you enable Debug View for your app?
As per the docs, there is a minor difference on enabling debug events on the real-time and debug view that is embedded into Firebase Console UI.
To enable Analytics Debug mode on your development device, specify the following command line argument in Xcode :
-FIRDebugEnabled
For real-time logs on XCode console for the Arguments Passed On Launch section, add:
-FIRAnalyticsDebugEnabled.
It is been a long time since this question has been post. I have been struggling with this problem for over a week.
Everything was ok in my side, I saw it worked, like yours, in the Xcode debug mode. My issue was I did not look to the Debug View which is under the Analytics -> DebbugView in Firebase Console
Here is Debug View at the end of the analytics: Debug View
Documents in Firebase is here: In the firebase documents but the image is old.
It is in Analytics -> Debug View
Hope this will help someone!
Simply select which device you want from this "DebugDevice" dropdown menu. It's on the top left corner.
(It was driving me crazy for couple of hours! I hope Google will improve the UI of Firebase)
Make sure that the logged event name is longer than 40 characters, there is a limit for the length of the event name and parameter name.
https://support.google.com/firebase/answer/9237506?hl=en
Maybe it's not related to the question above, but I think it could help someone. Here's my case:
I was misunderstanding about when the user engagement update, I was thinking that it would be updated immediately after I've sent the event!
But it's not. You must to wait.
If you're wondering that, have you been successful sent the event to the board or not. You should check on the Debug-View section.
What is the best practise for telling your application to close when hosting it with Trigger.IO?
I want a button on the front to exit the application... I heard that for Android navigator.app.exitApp(); works, but got an error saying exitApp() didnt exit, but am hoping there is a more cross browser solution.
You can use forge.event.backPressed to listen for back button presses, and optionally quit the app there. E.g.:
forge.event.backPressed.preventDefault(function () {
forge.event.backPressed.addListener(function (closeMe) {
closeMe(); // this closes the app
});
});
James posted the documented method of closing the app, but the internal method can also be called like this:
forge.internal.call('event.backPressed_closeApplication');
This method is confirmed to work on Android, unsure whether it will work on iOS.