Platform code separation

[mattapperson]

As we all know, there are times when you need to separate iOS and android code. And in Ti.Current we have the platform specific resource directories. And while the "legacy" mode for Ti.Next will for sure support this. Is this the prefered method all the time? Or is something like NativeScripts usage better?
NativeScript for the record lets you name files with .ios.js, .iphone.js, .ipad.js and .android.js
This means you dont end up with multiple file structures and thus easer to spet where code splits off. This is also how iOS does things for iPhone vs iPad files.

[joshthecoder]

👍 Yeah the file extensions for platform specific code would be a nice addition.

[cb1kenobi]

That's not a bad idea.

FWIW, I tried to pitch a Resources directory for each platform, but then specific Resources-android, Resources-ios, etc for platform specific files. This would solve the problem of say Android specific assets/code landing in your iOS app.

[yuchi]

I thing we have to differentiate two code separation goals.

The first is the obvious one, namely segmented_control.android.js. This kind of code separation happens because we either a) don‘t want to pollute a single file with conditionals or b) we want to gain some performance wins.

The second one is related to #2, namely http_client.android.js. This kind of separation happens because we could need to distinguish for which platform the native bindings should be generated for.

This comes down to three different questions:

1. What is the expected developer experience in the production of platform-specific code at the application, package, and component level?
2. What is the expected developer experience in the production of code that uses native platform APIs? (Discussed to The Titanium Mobile API written in JS #2 IMHO)
3. If we need to separate in both cases, will they be the same one?

[mattapperson]

I think we need both platform resource directories for when there are entire feature sets of your app that only work in one platform (Ti has this now)
And also filename based to keep things simple when its just a few minor changes. or some assets that need platform specific break outs, but its too much to rebuild its own file tree

There are many usecases for both IMHO (I can write them all out upon request but its the weekend so im lazy).