Tuesday, May 1st, 2012

An Issue for iOS Developers


Today Box reached an exciting (but in some ways too exciting) milestone. There comes a time in the growth of a company, when ID’s as numbers grow beyond the boundaries of signed integers (2^31) or integers (2^32). Today, Box went past the 2^31 boundary. Growth like this can cause problems in applications that were only built to handle signed integers.

It has affected the older versions of Box’s own iOS clients. We are working through Apple’s approval process to get our iOS client fix published, and will let you know when that is available in the app store.

If you are still using an old version of the Box iOS SDK, many of the operations will no longer work. In order to fix this problem, there are a couple of options available.

1) Upgrade to the new SDK

We highly recommend that you upgrade to the most recent version of the SDK (https://github.com/box/box-ios-sdk). It includes numerous bug fixes, asynchronous support, fixed memory leaks, cleaner login screens, less client code required, a file browser, and operation completion callbacks. It has been tested with new files and no change was necessary to the code in order to keep functionality. If you are currently using this version of the SDK, no change should be necessary, but we recommend you test your code with newly created files and ask that you contact us if you have any problems.

However, the new SDK has a different client interaction, so it cannot be simply downloaded and replace to old SDK. It will probably require changes in other parts of your code. Though we recommend upgrading as soon as you can, there is also a quicker fix available.

2) Fix your current code

If upgrading is not an option, it is possible to make a few small changes to the old code to ensure functionality. Mostly, the problem occurs any time an int is used to store a fileID. The following changes need to be made:

In BoxRESTApiFactory:

In both the .h and .m change any (int) to (long long) [example: parentId:(int)parentID -> parentId:(long long)parentID:]

In all stringWithFormat: methods, change any reference to a changed variable from %d to %qi [example:

return [NSString stringWithFormat:

@"<a href="https://www.box.net/api/1.0/rest?action=delete&api_key=%25@&auth_token=%25@&target=%25@&target_id=%25d" target="_blank">https://www.box.net/api/1.0/<wbr>rest?action=delete&api_key=%@&<wbr>auth_token=%@&target=%@&<wbr>target_id=%d</wbr></wbr></wbr></a>",





changes to

return [NSString stringWithFormat:

@"<a href="https://www.box.net/api/1.0/rest?action=delete&api_key=%25@&auth_token=%25@&target=%25@&target_id=%25qi" target="_blank">https://www.box.net/api/1.0/<wbr>rest?action=delete&api_key=%@&<wbr>auth_token=%@&target=%@&<wbr>target_id=%qi</wbr></wbr></wbr></a>",





In all operations:

Change the type of any properties and instance variables that refer to fileIDs from int to long long [example: int _targetId; -> long long _targetId;]

Change the init methods to take in long long as a parameter instead of an int

In the rest of your code:

Make sure to check that you are not dealing with fileIDs as int. For instance, you may have some code which looks like:

int fileID = [file.objectId intValue];

This code should be changed to long long and longlongValue.

Though these changes should fix any problems, we highly recommend thoroughly testing these changes on newly created files.

We apologize for the late notice about this issue. We always strive to make sure that our developers have a great experience with our platform, and we’ll be working even harder to ensure that you’re notified before any issues like this arise in the future. If you have any questions, or if you need any help updating your application, please don’t hesitate to contact us at developers@box.com.


See all of Alex's articles.

  • Pingback: Having Trouble Accessing Content from a Box App? Don’t Fret: Your Files Are Fine | The Box Blog

  • Peter Rexer

    This issue will affect custom built apps that have either stored fileID’s in a database field with too little precision, or have used intermediate variables without enough precision.

    What do I mean by not enough precision? FileID’s are now using the 32nd bit of a 4-byte number. If you are using a signed 4-byte integer, 1 bit is taken up by the +- sign, so you really only get 2^31 positive numbers. That is why uploads via the Box API will still work. We will mint a new ID when you do the upload that is larger than 2^31, and send that back to you. If your code takes that fileID, and stores it in a 4-byte number that is using the extra bit as the +- sign, your fileID number may ‘wrap around’ and become a negative number.

    Box is moving away from using numbers as ID’s. So the best long-term fix is to change your ID’s to be strings. Once we mix in all the possibilities strings give us for ID’s the namespace grows massively, and we don’t run out of space. You also avoid doing things you should not have been doing before anyway, like math operations on ID’s.

    Second best fix, is to move to 8-byte numbers, since we’ll be using numbers for at least another 3-6 months until most of our own clients and SDK’s are changed to using strings. Of course you’ll need to move to using Strings, so that move, while easier to do, isn’t a permanent fix.

    Do let us know if you are having problems downloading or accessing files in your own custom application that uses the Box API.

  • Erik

    It seems like your iOS SDK is still using version 1 of your API, will this be resolved in the near future?

  • Andrew

    This issue will affect custom built apps that have either stored fileID’s in a database field with too little precision, or have used intermediate variables without enough precision. plagiarism checker to fight plagiarism