[TIMOB-26142] TiAPI: Deprecate Ti.XML in favor of standalone module
| GitHub Issue | n/a |
|---|---|
| Type | Story |
| Priority | High |
| Status | Closed |
| Resolution | Won't Fix |
| Resolution Date | 2018-06-26T15:54:21.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | Android, iOS |
| Labels | n/a |
| Reporter | Hans Knöchel |
| Assignee | Hans Knöchel |
| Created | 2018-06-20T12:54:26.000+0000 |
| Updated | 2018-08-02T22:20:08.000+0000 |
Description
Our Ti.XML namespace has been around a while now. Nowadays, most of the common-used API's are JSON-based and based on the usage reports, there are not many devs left using this API inside the core. But still, it is still included, with it's 37 files. Removing it would mean a huge compile time bump, so it should be deprecated and moved to a standalone module, like we recently did with Ti.Yahoo.
I strongly believe we must retain XML support in the SDK proper. This is a industry standard data exchange format. The spec is stable. Ti.XML is not like Ti.Yahoo where it is a 3rd party service. I get moving it to a native Titanium module, but this is a huge mistake. They would need to activate the module in the tiapp.xml and require the module to use it. This is a poor developer experience. Either leave Ti.XML alone or move it into a pre-compiled framework/library that the Titanium build will detect the use of Ti.XML and alter the project to link to it during compile/link.
[~cbarber] Party agree. Yes, it is stable and standard, but it should not be packaged with every application. What I would like to do is to move it to a module and link it to our xcode project of Ti.XML.* is used. Therefore, we could a) save compile time if used by having a framework and b) save compile time when not using it by ripping out the framework link. This would require a build change as well, which should be small enough.
[~hknoechel] When you say module, do you mean a Titanium module or a framework/library?
Titanium module, static library. Once our [swift support](https://github.com/appcelerator/titanium_mobile/pull/9983) is merged, our native modules will be frameworks, so I mis-spelled it :-).
You cannot do a Titanium module. If you do, then you will need to inject
Ti.XML = require('ti.xml');. This is not elegant. It maybe acceptable in the future to force users to require() the XML module, but I believe we can and should make this automatic. Again, I propose you move the XML APIs into a native framework/library and if the build detects Ti.XML being used, then the build links to the framework/library. No need to require() anything. Robust, doesn't break anything. Let's be clear here, iOS is the problem. iOS is the only platform that does NOT pre-build it's native code during scons. This is the root of the build time problem. We've had ticket TIMOB-12186 open for 5-1/2 years to fix this and nobody has stepped up to the plate. I brought this up at the last eng week. iOS needs to get on the bandwagon and compile as much of its code during scons and have the result packaged with the SDK. This would make building the Titanium app even faster than just ripping Ti.XML out. Please, please, please, please do some house cleaning and fix the Xcode project so that scons builds the iOS platform code during scons. Add a new Xcode project if you need to. Organize theclassesdirectory and clean up the iOS platform.Why would we need to require it? It's just a namespace that is linked via the static library. So if defined (=
USE_TI_XML), the namespace can be made available in our source. And thats btw exactly what's described in the other ticket, although it does not make sense to compile the whole SDK inside a library, since it a) makes the app size too large and b) will cause save app rejections because symbols (= API's) are compiled into the app although not used.I didn't know Titanium modules had access to the Titanium namespace. Not sure if that's brilliant or an issue.
I don't see how pre-building the iOS platform would make it any larger. As for the symbols, that's why you ship a debug and a release build of the framework/library. This is standard practice.
It's the main reason we wrapped all larger API's in our precompile macros (
USE_TI_*). Some critical examples that other frameworks need to worry about because of this: - Camera, Music, Video API's -> App rejected if compiled into the app but not used - Contacts -> Same - Background Services / Silent-Pushes -> Same We had some of these issues in the past as well, but having the wrapping now solves it quite elegant for us and people love it. BUT: The above Swift-PR moves out our CORE to an own framework, so the whole JSCore handling will be precompiled - and works pretty nicely already. It saves us around 90 of ~310 classes already, which is pretty cool as well.I didn't say you need to pre-build the entire iOS platform code into a single framework/library. Android and Windows both have the various Titanium namespaces in separate libraries that the build system will include as needed into the final build. No need for macros because the build system takes care of it.
Thats also not possible. Ti.Media.showCamera & Ti.Media.audioSessionCategory. Same class, different API's. If not wrapped -> rejected. This cannot be done by the build. And Android still compiles all modules into the app from what I think. It's rather for the package based Android ecosystem.
It is possible because the build system can detect the difference between
showCameraandaudioSessionCategory. Android build does something similar to auto select permissions: https://github.com/appcelerator/titanium_mobile/blob/master/android/cli/commands/_build.js#L3625. Android certainly does NOT compile all modules into the app. It only compiles in what is used: https://github.com/appcelerator/titanium_mobile/blob/master/android/cli/commands/_build.js#L3027-L3047.Closing old "Won't fix" tickets. If you disagree, please reopen.