Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Kunta_H_
Beginner
103 Views

Swiching between projects and do complete re-upload. How ?

Jump to solution

I've been trying to switching back-and-forth between a sample project and my own project, but I can't find a clean way to do it. Here is what I have tried:

- From Manage your Daemon/IoT Device, I choose upload control, and then 'Clear Board Directory'. But that caused the complete project being rebuild, as opposed to just updating the javascript / html files, and it takes quite a while as it seems it includes rebuilding the bluetooth and usb library (my project involves using the bluetooth).

- I tried to force it by deleting the file from the board in /node_app_slot, but then I received error saying :"There does not appear to be a project/package.json in /node_app_slot/ Attempting to run anyway ... Error : Unable to start application! (try -re-uploading a project from the Intel XDK.)."   But I can't find a way to re-upload. The "Upload project from the device" button (the arrow) seems did not copy the files anymore.

Any other better way to re-upload an entire new project?

Thank you.

Regards,

Kunta

There does not appear to be a project/package.json in /node_app_slot/
Attempting to run anyway . . .

 
ERROR: Unable to start application! (try re-uploading a project from the Intel XDK.)
There does not appear to be a project/package.json in /node_app_slot/
Attempting to run anyway . . .

 
ERROR: Unable to start application! (try re-uploading a project from the Intel XDK.)
Tags (2)
0 Kudos
1 Solution
PaulF_IntelCorp
Employee
103 Views

This is an interesting problem, I've been asking for multiple "app slots" so you could have one per project. Your request will, I hope, hasten the acceptance of my request! Thank you for asking. :)

My recommendation would be to try doing the following:

  • ssh into the board
  • mkdir ~/projA/
  • mkdir ~/projB/
  • cd ~/.node_app_slot
     
  • open project A in the XDK
  • use "clear board directory" option (clears the ~/.node_app_slot folder on the board)
  • edit code, push and test project A, etc.
     
  • when you are ready to move to project B
  • from your ssh prompt > mv * .* ~/projA/
     
  • open project B in the XDK
  • use "clear board directory" option (clears the ~/.node_app_slot folder on the board)
  • edit code, push and test project B
     
  • when you are ready to move to project A
  • from your ssh prompt > mv * .* ~/projB/

From this point forward you need to do the opposite:

  • before opening project A
  • from your ssh prompt > mv ~/projA/* ~/projA/.* .
     
  • before opening project B
  • from your ssh prompt > mv ~/projB/* ~/projB/.* .

I've included the .* because I believe there is a .guid file that is created by the XDK that is used to track if the contents of the node_app_slot match the current project. So you need to include that with your sources.

You might need a third "dummy project" (like a blank mobile app project) to switch to, in the XDK, to insure that you can perform the moves after closing one project but before opening the next.

I haven't tested this, but I think it, or a variant of it, should work. Careful coordination will be the key. Let me know if this helps.

View solution in original post

4 Replies
PaulF_IntelCorp
Employee
104 Views

This is an interesting problem, I've been asking for multiple "app slots" so you could have one per project. Your request will, I hope, hasten the acceptance of my request! Thank you for asking. :)

My recommendation would be to try doing the following:

  • ssh into the board
  • mkdir ~/projA/
  • mkdir ~/projB/
  • cd ~/.node_app_slot
     
  • open project A in the XDK
  • use "clear board directory" option (clears the ~/.node_app_slot folder on the board)
  • edit code, push and test project A, etc.
     
  • when you are ready to move to project B
  • from your ssh prompt > mv * .* ~/projA/
     
  • open project B in the XDK
  • use "clear board directory" option (clears the ~/.node_app_slot folder on the board)
  • edit code, push and test project B
     
  • when you are ready to move to project A
  • from your ssh prompt > mv * .* ~/projB/

From this point forward you need to do the opposite:

  • before opening project A
  • from your ssh prompt > mv ~/projA/* ~/projA/.* .
     
  • before opening project B
  • from your ssh prompt > mv ~/projB/* ~/projB/.* .

I've included the .* because I believe there is a .guid file that is created by the XDK that is used to track if the contents of the node_app_slot match the current project. So you need to include that with your sources.

You might need a third "dummy project" (like a blank mobile app project) to switch to, in the XDK, to insure that you can perform the moves after closing one project but before opening the next.

I haven't tested this, but I think it, or a variant of it, should work. Careful coordination will be the key. Let me know if this helps.

View solution in original post

Kunta_H_
Beginner
103 Views

Thank you Paul.

I'll give it a try the next time I need it. In the meantime I have incorporated the sample code to my code, so I don't have to switch. But I can see this feature would be useful for others who is doing this usecase: trying to learn from sample code while writing their own code.

--

Kunta

Kunta_H_
Beginner
103 Views
Just want to confirm, the solution works with minor command modification. The command 'from this point forward' should be: before opening project A from your ssh prompt > mv ~/.node_app_slot ~/projB mv ~/projA ~/.node_app_slot before opening project B from your ssh prompt > mv ~/.node_app_slot ~/projA mv ~/projB/ ~/.node_app_slot As you mentioned, there is a hidden file .appGuid in the .node_app_slot. So another usecase that I found this would be useful is if a developer found the current project doesn't work as expected, and it's easier to flush it with completely other known-working project. This is what I encountered this morning, which then led me to reset the Edison. Thanks, Kunta
PaulF_IntelCorp
Employee
103 Views

Thanks for that feedback. The process you described, for the second half, is much simpler.

Reply