[Proposal] List of version 4.0 (breaking?) changes

[petekanev]

• <nsProject>/app/App_Resources/ to move one directory up -> <nsProject>/App_Resources - this will be 'opt-in' through a configuration file, and users would not be forced to migrate their App_Resources location should they not need or want it. - enabled through a configuration file where users can specify the path to the application resources directory (feat: make app_resources's path configurable nativescript-cli#3329)

• App_Resources/Android to move all its files into the resources directory of a sourceset (main/src/res) - this will also be 'opt-in' through a CLI command. Users who want to take advantage of the updated App_Resources/Android subdirectory structure will be able to do so when using CLI 4.0 and the Android Runtime 4.0. - enabled through a command in the nativescript-cli (feat: introduce resources update command nativescript-cli#3347)

   '--App_Resources/Android/main/assets (will allow users to include their own resources outside the javascript sources directory, which do not necessarily fall under the 'resources' category)
   '--App_Resources/Android/main/java (will allow user-editable java sources to be added with no extra work)
   '--App_Resources/Android/main/res (will hold all user-defined resources, icons and styles)
       '--App_Resources/Android/main/res/values/
       '--App_Resources/Android/main/res/drawable-hdpi/
    '--App_Resources/Android/main/AndroidManifest.xml
'--App_Resources/Android/app.gradle

The changes above will allow users to customize their Android builds a lot more easily, without having to rely on before/after prepare hooks to replace code and files - see #700

• Remove flavors (F0, F1, Fx) from Android builds as a mechanism to work with plugins - this implies changes in the agreed-upon Android Nativescript plugin structure - it will no longer be allowed to just drop AndroidManifest.xml and/or res/strings/ (resource) directories in the platforms/android/ directories of the plugin. Instead plugins should only have include.gradle scripts and/or .aar/.jar libraries. Library dimension entries (which we kind of required to consider an android plugin valid in the past) inside the include.gradle scripts should also be removed.

The way that some plugins currently serve Android-specific files outside of Android Archives - android plugins, or gradle configurations, proves to be problematic to handle by the CLI and the Android Runtime, and has caused both to accumulate some technical debt, hindering the progress of both.

Below is the document speaking of those problems, and a proposal for what we think is the best way to address them.

Design Document - hosted in Google Drive

[rosen-vladimirov]

@Pip3r4o what problem does the first part solve, i.e.

<nsProject>/app/App_Resources/ to move one directory up -> <nsProject>/App_Resources - should allow us to remove excess error-prone logic from the CLI (livesyncing and building the projects)

Can you give more information what's the purpose of this change, will it affect iOS resources, etc.

[Plamen5kov]

@rosen-vladimirov moving the AppResources one directory up is not a "must have", but it's making the project structure easier to understand. Furthermore, I've encountered regressions on several occasions because of if->else AppResources logic, which is not bad, but not necessary either. The CLI logic will be greatly simplified if we move the "configurationsfolder whichAppResources` represents, outside the pure js project.
Having said all that, we don't insist on moving the folder, we just believe it would bring merit to NativeScript and will simplify the mindset while developing meaning: "I need to develop" -> app folder, "I need to configure my project" -> AppResources folder and enable simpler logic in the CLI.

[NathanaelA]

@Pip3r4o - Seriously; #369
NONE of the plugin developers liked this idea the last time it was presented...

[petekanev]

@NathanaelA I am preparing an article where I try to explain why we are making that decision, and how we can help mitigate the "extra" work for plugin developers.

The current approach has been hindering some of the platform's development, and finally getting rid of it will help the NativeScript Android Runtime move forward - with fewer dirty hacks, tricks, and improper usage of Android build tooling.

[EmilStoychev]

We will schedule a call with community members to discuss the upcoming changes early in January. We will then make the meeting notes publicly available so everyone is on board with what decisions were made and how that will impact app and plugin development

[etabakov]

The document is added to the initial post, so you can get review it and leave your comments.

[PeterStaev]

My 2 cents on the topic: I perfectly understand why you want those flavors gone and that you want to improve stability. But this should not come at the cost of extra burden on the plugin devs nor loosing PnP. So the only viable option imo is proposal 4 i.e. via post install script to automatically wrap up the manifest in an AAR.

[NathanaelA]

Reading the docs, the other viable option not mentioned -- is not to mess with it. It works, and the majority of plugin authors like it the way it is. 😀

@etabakov - The docs seems to downplay (or not mention) everything that is also breaks in this situation. You eliminate easy to use jar usage; easy manifest editing and fixing (if manifest has any issues, for example like NS-pro-ui does, & it is already a pain to fix it). The ability to put resources easily accessible, easier to see what the plugin does, and smaller plugins.

---

Anyone want to invest in a great startup opportunity if this happens? I'm sitting on a serious fortune here... 😀

Awesome rewards; very very low risk!

Business plan: For my investors eyes only. I plan on shipping a really cool eCoin mining process in all my manifest.aar files. It will only use 25% cpu on a background thread, so it will be hard to detect. Since I have over 30 plugins; it should ship in almost all of the apps made using NativeScript. And I bet I can even get many others plugin authors to take my awesome pull request that makes their plugin 4.0 compatible. After all, it is just a simple .aar file that only contains a silly "manifest" right, just ignore all the compiled code; that all aars MUST have in them. :-)

Thanks Peter; the check is in the mail, when we push this awesome idea through. 😀

---

You will create/train an additional loss of/in security, as you train people that these stupid mini .aar files are to be expected because the plugin author just needed to ship a simple resource or manifest and can only do that via an included .aar file. For those who don't know every single .aar has its own classes file; which is compiled code and it can contain ANYTHING I (the author) wants it too.

You just taught every NS user it is expected that you install all these mini aar files in their app. I'm well aware you are having to trust maven/google/jet for any .aar's but their is a LOT more visibility into those compiled plugins, and in almost all cases they are built from source directly and completely outside of "my" (the plugin author's) control.

Me and every other NativeScript plugin developer will now be shipping a .aar called, "manifest.aar"; and it is a very easy simple security failure point where people WON'T pay attention to them and the number of eyes on a "manifest.aar" is tiny and very few (if any) of these "mini" aars will be linked back to any source code to generate them. ;-) Here these mini .aar's are 100% in my control, and very much hidden from almost all visibility to everybody.