I recently upgraded Firebase in my Swift app because I wanted to add App Check and I decided to update all the pods. Was only 8 minor releases 8.8 => 8.16. Now I am receiving
Firebase Instance ID is not compatible with Firebase 8.x+. Please
remove the dependency from the app.
I have removed my pods, cleaned, rebuilt, reinstalled.
I have restarted, cleaned, built.
I have removed App Check.
I have removed Messaging (which I've never used except for an experiment once).
I have no reference to Firebase Instance Id except in the FIR files which are Firebase's. Tried to follow the get started in the Firebase docs and they say use the Swift Package Manager (not sure if that was instead of CocoaPods?).
Any insight into this? It's obviously a new version issue, but would love to have to newest version for security vulnerability and any performance updates they've done. But my last resort will be to downgrade back to 8.8.
Related
Today I see that many articles were released about Flutter 2.2 and its new functionality. One of them is background caching using service workers. Has anyone an idea of what does it mean and how to use it?
for web apps, we offer background caching using service workers
UPDATE:
Ok I've found some information in this article
Flutter’s newest stable platform, web, has been improved in this release.
To start, we’ve optimized caching behavior with a new service worker-loading mechanism, and fixed double-downloading of main.dart.js. In previous versions of Flutter web, the service worker downloaded updates to your app in the background while giving your user access to the stale version of your app. Once that update was downloaded, the user wouldn’t see those changes until they refreshed the browser page a couple times. As of Flutter 2.2, when the new service worker detects a change, the user will wait until the updates are downloaded to use the app, but then they’ll see the updates without requiring a second manual refresh of the page.
I can't tell you what exactly they changed in caching but for how to use it:
Just upgrade flutter
flutter upgrade
and recompile
flutter build web --release
It should automatically build with the new service worker
Two part question:
How does one get the currently installed version of Realm in code? Swift 3, macOS. I was unable to location any Realm.version property - perhaps I overlooked it.
In a related question
What is the solution to upgrade Realm to the latest version within a project? After updating CocoaPods to the latest, and refreshing, pod install doesn't appear to update Realm. I have 2.0.3 installed and 2.2.0 is available.
If you're embedding Realm Swift as a dynamic framework directly, the version number is contained in the framework's info.plist file. It should be possible to access the plist during runtime; there's a few answers on SO discussing this.
Since CocoaPods creates dynamic frameworks for Swift, the above approach of accessing the info plists should work, but if it doesn't there might be other ways to access versions of pods.
In any case, I would definitely recommend you review why you're wanting to check the version numbers of your libraries. It's better practice to check a framework's capabilities at runtime (eg, testing a class you need exists etc) than to directly use the version number.
For your second question, you need to run pod update RealmSwift to get CocoaPods to check for an updated version of Realm.
In experimenting with a sample SF app and playing with upgrades and versioning I am noticing that it keeps a rather long history of versions. Below is a screenshot of my app in SFExplorer. Is there any way to control how much history is retained, or can I cull out versions I'll never use again.
Or should I not even be concerned with this? (even though I am!)
What you're seeing here is application registration. Before you can create an application instance, you have to register the application type and a version. When you upgrade your application, you register a new version of the same application type. This is the PowerShell command that does it (Visual Studio uses this on your behalf when you upgrade through it):
Register-ServiceFabricApplicationType
Over time, you'll see a bunch of versions of your application registered. If you don't want them registered anymore, you can simply unregister them using the corollary command:
Unregister-ServiceFabricApplicationType -ApplicationTypeName SFDemoType -ApplicationTypeVersion 1.0.2
While we have that screenshot in front of us, here are a couple cool things about application registration:
You can create instances of any registered application type + version at any time with the new commands:
New-ServiceFabricApplication -ApplicationName fabric:/SFDemo2 -ApplicationTypeName SFDemoType -ApplicationTypeVersion 1.0.7
This means you can do cool things like create side-by-side instances of the same application type but of different versions. Say you want to test out a new version of an application without upgrading an existing instance yet. You can register the new version, but instead of upgrading an existing instance of that application type, you can simply create a new instances of the new version of the application type.
You can "upgrade" a running application instance from any version of an application type to any other version of an application type using the upgrade command:
Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/SFDemo -ApplicationTypeVersion 1.0.20 -FailureAction Rollback -Monitored
For example, say you just upgraded your application instance from 1.0.15 to 1.0.20. After a while, you find a bug in 1.0.20. You can use the same application upgrade command to "upgrade" back to 1.0.15. In fact, the version strings are just strings - they can be anything you want. You can upgrade from version "banana" to version "Tuesday" if you want!
So yeah, you can unregister old versions if you think you'll never need them again. But it's great to have a version history, because you can actually do interesting stuff with it!
I noticed this afternoon that my Bluemix IoT Application was in the 'Unknown' state. When I mined into the app to see what the problem could be, I got the following pop-up:
App staging failed in the buildpack compile phase
I haven't made any changes to my NodeRED flows in months, and if I spin up a new IOT Foundation app, it starts just fine.
Any ideas on what is going on here?
A recent update to the underlying application stack has caused an incompatibility with older versions of the IoTF boilerplate.
The fix is to edit your application's package.json file and remove the 'mqlight' entry under the dependencies section. New instances of the boilerplate already have this entry removed - hence why they work.
Perhaps check the bluemix server status at https://developer.ibm.com/bluemix/support/#status
There were some issues reported around scheduled maintenance. There are also buildpack updates scheduled.
I'm working with Google App Engine in Eclipse w/ JSP pages in Windows 7.
I already have an app deployed and working, but I am unable to make changes to it for some reason.
If I make changes and debug locally, my localhost page is showing the changes that I implement.
While I am not getting any errors in the deployment, the same changes that work on my local debug are no longer showing up, so I can't update my app.
I thought updating the version number might help, but I had no luck with this.
Any ideas? Thanks.
Are you deploying the same version (as specified in appengine-web.xml) as the default version that is running on your app? If not, you'll have to access your new deployment at http://newversion.appname.appspot.com, or change your default version in app engine to your newly deployed version.
I have had the same problems too, especially when the changes concerned the static pages. Some little things to check:
If you have set an expiration date in your app.yaml, your browser cache could be holding the file.
If it’s specific to the online contents, it could be an intermediary cache (such as a squid server) serving the outdated contents, in which case you’d have to flush the cache to get the new version.
You could start by checking the log on the GAE console to see if the request is received by the server, that would help you debug.
Another trick, if you’re being served an outdated version of http://yourapp.appspot.com/index, try and pass a dummy argument to force the browser to update the version, for instance : http://yourapp.appspot.com/index?p=1