[TIMOB-26025] TiAPI: Improve Ti.Filesystem.File parity #10019
Conversation
…le#createDirectory to be recursive like other platforms (but allow passing false as arg to disable). Fix Android returning true for Ti.Filesystem.File#isDirectory() on non-existent Resource sub-dirs.
… return Numbers not Dates. Deprecate the property versions. Incorporate some of Hans' updates.
… under the hood with these APIs
|
So my concern here is that introducing alternate methods would be a bit of work for all the platforms, and that the new names actually suggest return types of Date mores than the current names. iOS just happens to return Date objects for a method clearly named to suggest a unix timestamp return value. I think it makes sense to make a deprecation note now and not change the return type to Number yet, but I don't see a nice way to avoid the issue of the method suddenly changing return type on iOS in the future. Moving to a new method name is one way to do it, as you suggested, but then that suggests moving all the other platforms to Date to me and requires more work - and I'd still be reluctant to remove the timestamp variants. Looking at Node's So maybe we combine our solutions?
|
|
Date Objects make a lot of sense in JavaScript world. For a lot of purposes you'd actually be making date objects yourself as well. And getting timestamp from date object is easy. I'm in favour of just having 1 property, based on Hans his suggestion, the |
|
@sgtcoolguy I can help doing the |
hansemannn
changed the title
…turn Dates. Deprecate #modificationTimestamp() and #createTimestamp() due to inconsistent return types across platforms. Update unit tests to check new createdAt/modifiedAt methods. Add docs for new methods/deprecations. Use longs in place of doubles in Android file APIs whne it's more appropriate. Support getting creation timestamp for files on Android when API 26+. Fix spaceAvailable to use newer more accurate APIs on API level 18+.
…dificationTimestamp() on Android.
|
@infosia Hey Kota - so to fix some parity issues we're looking at deprecating |
|
@hansemannn @Topener I've pushed the changes to deprecate the timestamp methods on iOS and Android and added the new variants that return a Date. |
Tests:
Generated by 🚫 dangerJS |
…w it wasn't there before.
JIRA: https://jira.appcelerator.org/browse/TIMOB-26025
Description:
This stole quite a bit of @hansemannn 's PR from #9750 on the iOS side to better define return types of methods/properties and at least log errors that may happen under the hood. This did not incorporate the ARC changes (I was concerned they were the cause of the crashes on that PR).
iOS:
Ti.Filesystem.File #createTimestamp()and#modificationTimestamp()and the property equivalents (log deprecation note when old methods are called). Add#createdAt()and#modifiedAt()as new replacements that return a Date.Ti.Filesystem.File#copy()method.Ti.Filesystem.File#createDirectory()to be recursive like other platforms. This took an undocumented single argument to do this recursively in the past. I retained the ability to pass an explicit false in to the method to not create a directory recursively - not sure what we want to do here. This is a behavioral change.Ti.Filesystem.File.parenttestAndroid:
Ti.Filesystem.File #createTimestamp()and#modificationTimestamp()(log deprecation note when old methods are called). Add#createdAt()and#modifiedAt()as new replacements that return a Date.Ti.Filesystem.File#append()method.Ti.Filesystem.File#isDirectory()on non-existent Resource sub-dirs.JIRA: