I have noticed that firestore iOS SDK (and possibly many other platforms too) don't have access to the createTime property of a document.
With node.js I can access the createTime property of the DocumentSnapshot (which is not mentioned in their official document for node.js either).
My question is, why firebase don't let us use this property (or silently let us use it) even if it is pretty useful for many cases and it is there already?
Also is there any way I could use this property for iOS? Right now I have to manually keep extra field associated with each document (which sounds dumb knowing that there is already a property that firestore keeps).
from the code comment:
/**
* The time the document was created. Not set for documents that don't
* exist.
*/
readonly createTime?: Timestamp;
As with most details that are not exposed through public APIs, you should think of that hidden value as an implementation detail that could change in the future. If you depend on it or try to use it in any way, your app could break in the future. As for why it's hidden, only the designers of the system could know that for sure. But you can be sure that, if it's not exposed in the API, they did not intend for you to use it at all.
What you can do instead is simply create your own timestamp field and give it the value you want at the time the document is created. This is very common.
Related
I'm not sure if the method I'm currently using when I just want a Firebase auto-generated ID in my Swift app is correct. It feels a bit clunky, and I was hoping there was a better method.
These IDs are just for UUID consistency in my application and a few other use cases, so I don't want to perform a read/write operation in Firestore.
Please note, I'm not looking at any UUID generation method (e.g. UUID().uuidString) nor do I want to use a 3rd party lib which claims to use the same mechanism to generate UUIDs. I'm trying to specifically and explicitly generate the same IDs as Firebase, using Firebase, without incurring a read/write cost.
func generateId() -> String {
return Firestore.firestore().collection("unused").document().documentID
}
Ignoring the namespacing of calling Firestore.firestore() (only doing that because of where the code is called from), this feels very strange, to create a document ref to a collection that doesn't exist (and will never exist), just to extract the document ID from the document it creates.
I would have thought/hoped there was some sort of Firestore.generateId() static method or utility somewhere, and maybe there is which just isn't showing up on my auto-complete...
What you're doing now is your easiest option. There is no public API for generating those random document ID strings.
If you want to make your own function, you can simply copy what Firestore does, since the client libraries are open source.
I'm currently building a mutation that deletes a node.
I looked into the NODE_DELETE mutator configuration, but it specifies it needs a parentName, parentID and connectionName.
Why does deleting a node needs theses fields ? As Relay uses global IDs, it should be fairly easy to delete a node from all connections and/or all fields it is being referenced in.
See the documentation :
Relay NODE_DELETE documentation
Your intuition is correct. Those fields are redundant for the purpose of deleting node from data store, only config.deletedIDFieldName is used during such operation (details in writeRelayUpdatePayload module).
However you can't leave other fields unfilled, because they are still required during validation of your mutation that extends RelayMutation class. I have no idea where this inconsistency comes from, but it's worth noting that Relay team changed the direction of development and RelayMutation will get deprecated.
RelayMutation and fat/tracked queries. Future releases will deprecate
this API in favor of a static mutation API. We recommend using
RelayGraphQLMutation to ease the transition to new mutations.
source: Related issue on github
After quick look in Relay's source it seems this transitional API does not use the old method of configs validation, but I haven't got a chance to experiment with it yet, so you can confirm it yourself.
I am storing secure data in the keychain that should be maintained only within my app. During app running this data is retrieved to some variable. It seems like it is possible to crack my app in order to read that value or even dump the whole keychain, but my question is it possible to the "hacker" modify that data i.e. modify at runtime area of RAM that holds this variable and make my app to update keychain with new value? And I also have setter method for that property, which saves it to keychain, is it possible to investigate the address of that function and force call my method with custom value?
I already looked here and here for best practices, read answer at Quora, that and that articles, looked for ios-keychain-analyzer project at GitHub but there is no mention about changing data, only about reading
I am wanting to add URL schemes to my iOS app, however the URL needs to be able to point towards a certain NSManagedObject from Core Data. I'm quite happy for my app to have to generate the URL for the user to use, but it just doesn't seem right to use the whole NSManagedObject URI in the URL.
When I retrieve the URI of the managed object, it is like this:
x-coredata://633EAF37-A03D-4954-976D-B3B0C32F8033/MyObject/p7
I'm guessing I can drop the x-coredata:// part which I can put back in my application:openURL method, but this still leaves me with a URL like this:
myurlscheme://event_to_perform?object=633EAF37-A03D-4954-976D-B3B0C32F8033/MyObject/p7
Is there more I can do to shorten this?
What about the has part 633EAF37-A03D-4954-976D-B3B0C32F8033? Will this be the same across every device the app is installed on, or is it unique?
If it was the same across devices then i'd only really need to use the final p7 as everything else I could add back in a string.
Any advice appreciated.
Thanks
Perhaps have a look at Permanent NSManagedObjectID not so permanent? first about the fragility of passing a NSManagedObjectID around. Marcus S. Zarra claims that the objectID can change during the life of a object.
That being said, the URI for a permanent managed object id seems always to be built like this:
x-coredata://<UUID>/<EntityName>/p<Key>
where
<UUID> is the NSStoreUUIDKey value of the metadata dictionary of NSPersistentStore,
<EntityName> is the entity name :-)
<Key> is the primary key that SQLite uses internally for the table (but which is invisible
to the Core Data API).
But note that this is only what I observed. The format is not documented and can probably
change at any time.
The <UUID> is generated when a store file is created, so it is not the same across every device the app is installed on.
So if the above analysis is correct and the URI scheme does not change in the future,
then you could indeed reconstruct the managed object URI from the final component p<Key>
alone.
That feels like exposing your implementation too much. I would highly recommend you maintain your own unique id property in the entity and use it to fetch the right entity from CoreData when you get a URL lookup.
This future proofs you should you ever, say, start syncing to a web-based version of your app or some other data store that is not CoreData.
I've been using a UIManagedDocument inside of a Singleton class. I create, open and perform with etc and everything was going fine until I needed to have two separate Data stores with an identical Schema. I've made sure everything was done in the same way through the same class (simply storing the second Database in a second static variable and using a BOOL to ensure the correct document gets used.
The problem is that while my original document works fine and the second document gets created fine, I can never seem to get the second document to open when I call 'openWithCompletionHandler' and pass in the block I need it to perform.
So my question is: Are there any special considerations I need to take into account when using multiple UIManagedDocuments in the one project?
Thanks in advance.
Yes there are. The big one is to make sure they both have unique NSPersistentStoreUbiquitousContentNameKey values set in the document's persistentStoreOptions.
See Rich Warren's well documented example:
Syncing Multiple Core Data Documents Using iCloud
And also my GitHub repo that makes multiple documents easier to set up and maintain in some cases:
APManagedDocument