Twitter object IDs (Tweets, Direct Messages, Users, Collections, Lists etc.) are described as follows:
These IDs are unique 64-bit unsigned integers, which are based on time, instead of being sequential.
Are they guaranteed to be disjoint?
IOW, can the same ID denote both a user and a tweet?
Even if they are "disjoint" today, there's no guarantee that they would be tomorrow. You would be wise to develop your application as though they were NOT disjointed.
In other words, you should assume that it is possible for the same 64-bit integer to be used for users as well as tweets. This will make your code more resilient to future change.
Related
Sorry if this isn't the proper channel for this question; it's hard to tell where else to put it.
Primary Question
Given a phone number (in my case: US or +1), I want to know whether that phone number is designated for use with mobile or landline phones (exclusive or). (Optionally: can I determine whether they were ported?)
I know that the ability to port numbers implies that no data on this is 100% accurate. I'm only looking to be about as accurate as existing services like Vonage's Number Insight API, or PhoneValidator.com, without giving them my customer's phone numbers directly. I'd preferably like to know how they acquire their information so I can replicate it.
I do know that NANPA publishes Central Office Code Assignment Records, which is enough to get me the company who 'owns' a block of numbers, but that doesn't necessarily tell me whether they're mobile or landline blocks.
Reading the TYPE from Google's libphonenumber gives the rather unhelpful FIXED_LINE_OR_MOBILE response, whereas I'm looking for which device type specifically.
Secondary question:
Given that NANPA hands out phone numbers in blocks of 1000, am I safe to presume that a random number within that block is representative of the whole block? In other words: does 222-222-2000 being a mobile number imply that 2000 through 2999 is?
Thank you!
iOS 11 adds DeviceCheck, a mechanism to allow app developers to store a small amount of data (2 bits, along with a timestamp) that stays on the device, surviving deletion of the app. This is mean to identify for example, if a user has already participated in a free trial, or other similar purposes, while preventing a unique identification (fingerprinting) of the user. Documentation link
My question is couldn’t this theoretically be abused by developers to store much more data (potentially uniquely fingerprinting the user), by using a unique timestamp? Is there any mechanism keeping developers from doing this? If not this could be a significant privacy concern, defeating the point of this feature.
I could easily see malicious developers either storing the timestamp on their server to later uniquely identify the user, or simply waiting to store the data until a particular timestamp arrives, and encoding data in (the lower few bits of) the timestamp itself. Is this an actual risk?
According to the documentation it looks like the last_update_time timestamp that Apple gives you is in the YYYY-MM format. If you have more than a handful of users it's probably safe to assume that month-level granularity on the timestamp isn't enough to uniquely identify any user.
My app uploads contacts, and, in the future, will need to update them. Is using the ABRecordID a reliable way to identify people, or is it possible for a new record to obtain the ID of a deleted record?
To optimize uploads, I would like to upload only the records that have been modified or created since the last upload. I'm currently storing a copy of the person's contacts using core data. I'd like to slim down the footprint of my app and speed up the execution time of scanning through the person's address book looking for modified/new contacts and limit the amount that needs to be uploaded. After analyzing some people's address books, the number of contacts can range from 30 to around 30,000. Dealing with 30,000 contacts is a nightmare.
A new record will not obtain an id previously associated with a deleted record. ABRecordIDs are unique in that regard. But they are not necessarily consistent over time, a couple of things can cause the id to change. The user turning on or off iCloud may cause the id to change, as may restoring the device from itunes.
That said, ABRecordID is still your best bet for getting a unique id for a contact. You just need to double check that things line up when using it. Apple suggests the following in the address book programming guide:
The recommended way to keep a long-term reference to a particular
record is to store the first and last name, or a hash of the first and
last name, in addition to the identifier. When you look up a record by
ID, compare the record’s name to your stored name. If they don’t
match, use the stored name to find the record, and store the new ID
for the record.
thank you for taking the time and interest reading this and hopefully helping me out.
I need an unique user identifier for IOS, and what I mean with unique user identifier is a unique string that Apple provides that is unique for user not device, meaning that it will stay the same across devices. I thought about the Apple ID or something like that, but it´s not possible, because Apple does not provide it(at least not that I know of), but I want something similar to that.
It cannot be the UDID, because(besides being deprecated) it´s not persistent across devices. I want this in order to authenticate a user, without the user having to login, or signup. It is possible to do so, because some apps do so. I didn not log in or anything with another device, but it authenticated me. I had thought it was with the Apple ID, but that´s not possible to do.
I checked this answer: iOS unique user identifier. And it seems that it might be the solution, but I don't quite get it, as I don't see how it would be unique to every new user(being able to distinguish between multiple users, and the same user, but on different device).
I really appreciate people reading this and trying to help.
Thank you
PD: I use Titanium´s Appcelerator, not Apple´s IOS SDK or anything like that. But it´s not that important, I just want to get the process to be able to do it with Titanium's Appcelerator
PS: NOTE:
Thank you for answering and so fast!. I have read it many times and I just don't get it. Could you guys help me understand it a little bit better?
The way I understand it is this.
1.-Create an UUID(changes with every installation)
2.-Store it to the Keychain(As far as I know, the values saved on the keychain are local to the device) with a default service(I think Ill put it with the application's id-com.bla.bla-), and also a default account, I think Ill leave it as "users".
This will all be local, so every single installation will do this, with a different UUID for each installation(not necessary every user)
3.-Save the UUID to the NSUserDefaults.
4.-Save the UUID to the Cloud's public data store.(The UUID in the Cloud´s Data Store, Keychain and NSUserDefaults should be the same)
So, if 5 installations are run, the Cloud´s Public Data Store should be like this
An Array of 5 values:
[
XXXX-EEEEE-FFFFF,
SFSDFFWE-WERW-SDFS,
XXXX-XXXXX-XXXXX,
ZZZZZ-ZZZZ-ZZZZX,
XZXZZX-ZXZXZXS-ADADS
]
5.-All this will be executed every time you run the application, checking first if there is a value stored on the public cloud store. Here´s where I am confused, how will a different device know which UUID is yours? I mean, there are 5 different UUIDS to chose. Maybe it´s not supposed to be saved on the public data store, but on the private data store, but for that you would need to also identify each user. This is where I get so confused.
If there is no UUID set, execute the last 4 steps.
So, I get confused on the 5th step, most people understand that solution, without any more explanation, so I must be ignorant in the way something works, maybe the cloud services? I think the problem is that maybe I'm not understanding how the iCloud works, and how it stores it´s values. I just don't get how the 5th(random number, it might be the 2nd or 2000th) device of X running the app, will know that the UUID XXX... is the UUID of user X, and not the UUID of user Z.
Thank you again for answering so fast, I thought maybe I would have to wait a couple of days, not a couple of minutes. Forgive me for my ignorance, I'm kind of a noob on this matter, but I would like to learn. Been stuck on this problem for days
The answer you referred to is the correct way to identify your users. The solution is to save the value of that identification called a UUID (Unique User ID) - as opposed to a UDID (Unique Device ID).
The only down side to this of course for you as a developer is that the user could delete and install the app again and have a different ID.
As Daniel said, the UUID is the correct way to identify your users. I just want to add on this; you said that
I dont see how it would be unique to every new user
Well, accordint to this Wikipedia article:
Randomly generated UUIDs have 122 random bits...only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. The probability of one duplicate would be about 50% if every person on earth owns 600 million UUIDs.
So you can be pretty sure that the UUID will be unique to each user.
Additionally, the MAC address is based off of the MAC address of your ethernet card, the timestamp, and some other miscellaneous information. This adds to the uniqueness of the UUID as according to this question on Superuser:
[MAC addresses] are reasonably unique.
The first 3 octets define the manufacturer.
The last 3 octets are usually generated at the time of PROM burning. It's up to the manufacturer how they do this.
That obviously gives 16,777,215 possible unique MAC addresses per manufacturer. That's quite alot, so the manufacturer shouldn't re-use one.
So basically, the UUID adds an additional degree of uniqueness to the MAC address.
In summation, for your intents and purposes, the UUID would be perfect.
Hope this helps!
Any idea what is the best way to store Twitter's tweet ID (and other Twitter data item IDs in general) in a Core Data field? This is to locally cache tweets (and other Twitter data) and will be used as the primary unique ID to link the local data with the one in the server side. That is, any new ID value returned by the API will create a record locally whereas if there is an existing ID in the local data store, the rest of the data will be updated from whatever the Twitter API return. So there will be many fetches done on this field.
This is for the Core Data library for Mac OS X / iOS and the underlying persistent store used is SQLite.
As you might have known, currently Twitter defines message IDs as 64-bit unsigned integers. Based on this, I can think of these options store Twitter IDs locally:
As a 64-bit signed integer (Core Data doesn't have an unsigned integer type)
As a String
As a Decimal
Option (1) has two dangers that I can foresee:
Integer overflows (sign overflow), primarily when parsing the string representation of the ID.
What if Twitter overflows 64 bit and enlarge their range of ID values?
Option (2) may be less efficient since this field is frequently used in fetches.
Option (3) may not be more efficient than option (2) since SQLite 3 does not have a native variable-length number type.
The ideal option is probably to store it as 128-bit unsigned integer, which makes them as unique as UUIDs and won't be as large as strings. But unfortunately there is no 128-bit unsigned integer type in SQLite, and anything that's not natively supported in the underlying persistent store can cause problems when using the field as a fetch key.
Thanks in advance.
There won't be a switch from 64 bit to 128 bit (at least not for any good reason like address space), even though it's signed it still leaves you with 63 bits which spans around 9,000,000,000,000,000,000 tweets. Twitter gets 200 million tweets a day. Even if they had a trillion tweets a day it would take 9 million days to overflow. So using 64 bit is certainly safe in that respect.