[TIMOB-14068] Fail to run BlackBerry if the platform is enabled after alloy project is created
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Critical |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2013-05-31T21:40:18.000+0000 |
| Affected Version/s | Release 3.1.1, Release 3.2.0 |
| Fix Version/s | 2013 Sprint 11 BB, 2013 Sprint 11, Release 3.1.1, Release 3.2.0 |
| Components | BlackBerry |
| Labels | qe-3.1.1, qe-closed-3.1.1, qe-testadded |
| Reporter | Lokesh Choudhary |
| Assignee | Josh Roesslein |
| Created | 2013-05-31T00:14:09.000+0000 |
| Updated | 2014-02-20T23:57:24.000+0000 |
Description
Description:
1. Create a default alloy app from the default templates in appcelerator studio without BB as target
2. After the app is created enable BB in the tiapp.xml & save it (Note the blackberry folder gets created in the resources folder)
3. Build & run for BB device/simulator
Actual Result:
1. The build fails as the blackberry folder in resources gets deleted automatically
Expected Result:
1. The alloy app builds fine & runs as expected on the device/simulator
Checked with alloy 1.1.3-alpha & I can reproduce the issue.
I can take a look if this is on Alloy's end. There's little chance it would have been a regression though. This would undoubedtly have been present in alloy 1.1.2.
I was able to reproduce using Lokesh's instructions. I don't think the source of this issue is Alloy though. I followed a similar set of instructions to Lokesh's as such:
Create a default alloy app from the default templates in appcelerator studio without BB as target
After the app is created enable BB in the tiapp.xml & save it (Note the blackberry folder gets created in the resources folder)
Instead of "build & run" in studio, which can cloud the issue's origin, I specifically ran the Alloy compile by hand to see if it caused the deletion of the Blackberry Resources folder. I did this:
The result was that the app successfully compiled for Alloy and that both the "app/assets/blackberry" and "Resources/blackberry" folders' contents remained intact. This leads me to believe that the issue lies with either Studio or some characteristic of the Blackberry build process that only occurs when Blackberry support is added after project creation via studio.This looks to be a CLI issue. Here is what we see:
When an alloy project is created without BB, the app/assets/blackberry folder is empty. By contrast, the android, iphone, and mobileweb folders have images and icons even when their respective deploy targets are not selected during project creation.
After the alloy project with BB is created, when BB is enabled via tiapp.xml, the following command is run:
The command will copy the assets to Resources/blackberry directory correctly, but app/assets/blackberry folder is still empty.Then when project is run on BB simulator, it would fail on the packaging part. This happens from command line as well.
After we manually add the images to app/assets/blackberry directory, running on BB simulator would work.
More on the sequence of commands Studio runs, and I tried them in order from the command line:
First project creation:
The project is created, and there is no app folder, and that is expected.Then we run "alloy new":
After running this from command line, app folder is created, along with individual platform as sub-directories. However, android, iphone, and mobileweb under assets have contents, while app/assets/blackberry has no content. And I think that's the problem.[~mxia] alloy will attempt to grab the existing contents of the Resources folder for a particular platform and move it into that platforms' "app/assets/PLATFORM_NAME" folder when you do "alloy new". If there is no "Resources/blackberry" folder contents when you call "alloy new", then alloy has nothing to try and populate it with. The "Resources/blackberry" folder needs to be present and populated before calling "alloy new". Does that make sense?
Is this really BB specific? Would the same thing happened if you added on new platform of any stripe to an existing project? If we add a new platform to a project, it seems we then also need to call some alloy command to move over the resources, no?
Copied from my email: High level points:
It is reproducible from command line using the same set of commands Studio runs, so it is not an Appcelerator Studio specific issue;
The issue happens when BlackBerry is not included in the initial project creation but added later through tiapp.xml; it does not happen when BlackBerry is included in the initial project creation.
More detailed investigation: 1. When user creates the project with selected platforms, the following command is run:At the end of the run, Resources folder contains the following files and directories: -rw-r--r-- 1 mxia staff 1158 May 30 21:21 KS_nav_ui.png -rw-r--r-- 1 mxia staff 1074 May 30 21:21 KS_nav_views.png drwxr-xr-x 5 mxia staff 170 May 30 21:21 android -rw-r--r-- 1 mxia staff 1164 May 30 21:21 app.js drwxr-xr-x 8 mxia staff 272 May 30 21:21 iphone drwxr-xr-x 5 mxia staff 170 May 30 21:21 mobileweb drwxr-xr-x 3 mxia staff 102 May 30 21:21 tizen There is no blackberry directory since BB isn't included; expected result. 2. Then this command is run:This creates the app directory under project root. It has an "assets" folder, which in turn contains android, iphone, blackberry, and mobileweb. Only the blackberry one is empty. From Tony's latest comment in the ticket, this is expected as well since Resources/blackberry folder is not there. 3. Now user enables BlackBerry in the tiapp.xml and saves, the following command is called:It copies the BB assets from the SDK to the Resources directory so Resources/blackberry/ folder contains content. The app/assets/blackberry folder remains empty. 4. Finally Studio runs the build command:And here are the outputs at the end: [Command] :source /Applications/bbndk/bbndk-env.sh && blackberry-deploy -installApp -launchApp -device 192.168.163.135 -package "/Users/mxia/Documents/Titanium_Studio_Workspace/testbb/build/blackberry/x86/o-g/testbb.bar" Error: Command failed: Warning: Using default icon: /Applications/bbndk/host_10_1_0_132/darwin/x86/usr/samples/icons/blackberry-tablet-default-icon.png Error: Attribute image: file cannot be found in the list of packaged files: assets/splash-600x1024.png Warning: Using default icon: /Applications/bbndk/host_10_1_0_132/darwin/x86/usr/samples/icons/blackberry-tablet-default-icon.png Error: Attribute image: file cannot be found in the list of packaged files: assets/splash-600x1024.png Error: Command failed: Error: File does not exist or not a file or cannot read: /Users/mxia/Documents/Titanium_Studio_Workspace/testbb/build/blackberry/x86/o-g/testbb.bar Error: File does not exist or not a file or cannot read: /Users/mxia/Documents/Titanium_Studio_Workspace/testbb/build/blackberry/x86/o-g/testbb.bar If we check the Resources/blackberry/ folder now, it becomes empty again. My suspicion is that the build script copies from assets folder instead of respecting the existing content in Resources, thus wiping it out since assets folder is empty. The solution to me seems to be that we should call "alloy new" again after step 3 to copy the content from Resources to assets again; however, I tried that from command line and it failed because app folder already exists. Then the next suggestion is for the build script to respect the existing content in Resources if they don't exist in the corresponding assets folder. Either way, we would need help from the platform team since Studio doesn't call "alloy new" directly or interfere with the build command.I also checked to see if it's a BB specific issue by calling the project create command with only android specified. In that case, "alloy new" will still generate content under app/assets/iphone and app/assets/mobileweb even though only Resources/android exists, so the process works. For tizen, the app/assets/tizen folder doesn't exist either, but it doesn't appear to affect the build command, as it succeeds anyway.
So I can make a change to Alloy to add the SDK's Resources for BB like I have for iphone, android, and mobileweb, *BUT* this only helps when "alloy new" is called, which should not be called every time a new platform is added to a project. This would, as its name states, create a new Alloy project from scratch, using the given template. So if this was an existing project with work in it, it would get blown away. So "alloy new" should not be part of Studio's workflow every time someone adds a platform to an existing project, only on initial project creation. So, while this is an important note, I don't think it solves this issue. We have a couple options, let me know what you guys think, or of you think there's a possible solution I'm missing. [~ingo] I know you generally like having the "fast" and "right" way to evaluate, so...
fastest way
Whenever Studio adds BB as a new platform to a project, it adds the "blackberry" folder to both "Resources" and "app/assets". *pros:* quick, and requires a change to only one project (Studio) *cons:* Doesn't account for the CLIlonger, better way
Alloy implements a new command for adding new platforms relying on assets contained in alloy itself. So instead of Studio calling "alloy new", which is dangerous after initial project creation, Studio would call "alloy platform add blackberry", or something like that, which would then populate the "app/assets/blackberry" folder. *pros:* could be done in studio or CLI *cons:* now requires change to both Alloy and Studioeven longer, even better way
The CLI exposes a hook for the completion of this very long command (I believe "project" is the command name):"/usr/local/bin/titanium" "--no-colors" "--no-prompt" "--no-banner" "project" "--sdk" "3.1.1.v20130530171546" "--project-dir" "/Users/mxia/Documents/Titanium_Studio_Workspace/testbb" "deployment-targets" "blackberry,tizen,mobileweb,android,iphone,iPad"[~tlukasavage] Can you give an estimate on how long the three options would take from your perspective?
[~ingo] option 1: no time from my perspective (all work is in studio's court here) option 2: a couple hours (plus Studio's estimate of time) option 3: to be comfortable with its stability, about a day since changing the hook potentially impacts every Alloy app (lots of testing). But I couldn't even start it before this hook was added to the CLI, and obviously whatever version of the CLI supports it would be necessary. There is however a 4th option which would likely be faster than all the other and would put the work on the BB platform, which makes sense since it is the new kid on the block in this scenario. Can't BB just handle the scenario where it doesn't have the appropriate files in its "Resources/blackberry" folder? Again, like option #1, not ideal, but quick and covers this situation. To be clear, option #3 is the way to go long term. It just introduces a lot more variables and potential for regression at this late point in the game than does option #1 or #4.
To be clear on option #4, the BB build process should copy the necessary assets to both "Resources/blackberry" and "app/assets/blackberry". With the assets in both folders, it ensures that the app is back in sync and that further files can be added to the "app/assets/blackberry" folder going forward in the app's development.
Russ and myself sat down and came up with a solution in BlackBerry CLI. A pull request [#65](https://github.com/appcelerator/titanium_mobile_blackberry/pull/65) is up for review now. This makes the CLI more gracefully handle a missing BlackBerry resources folder by falling back to the SDK templates directory.
Pedro discovered another problem if the project's Resources/blackberry contains a file (ex: .npmignore). I tweaked the way we fall back to using the default resources in the SDK if they are missing in the project. Pull request is ready and Pedro will be reviewing and testing it shortly.
Verified the fix in both titanium studio & appcelerator studio & now able to successfully run alloy apps in which BB target has been added after the app has been created. Environment: Ti Studio : 3.1.1.201305312303 Appcel Studio : 3.1.1.201306031002 Ti BB SDK : 3.1.1.v20130531163723 Mac OSX : 10.8.2 Alloy : 1.1.3-cr CLI - 3.1.1-cr Z10 BB simulator : 10.0.10.822 Z10 device running 10.0.10.88