I am having an issue with my application hosted on Cydia.
Users are complaining that the app crashes on startup.
The app uses CoreData, I thought it had something to do with this.
Weird thing is that it works fine using simulator or on my device when testing.
But as soon as it is installed through Cydia it crashes.
Turns out that using "Fix User Dir Permissions" from SBSettings fixes this issue.
Now what can I do about this?
I just had a discussion with the repository guys at BigBoss about this.
I never really got a clear answer, but it looks to me like when Cydia installs your application, it doesn't necessarily set the ownership (explicitly) for your application. That seems bizarre to me. In my case, they were test-installing my app, and seeing that it was owned by user/group = { 1000 / 100 }, which was the linux user id and group id from the machine I was preparing my .deb package on!
I can also see this same behavior if I build a .deb package, deploy it to my own local test repository, and install it with Cydia (pointing at my own repo).
In any case, I explained this to them, and they did something to fix it (without anything more from me).
However, one other option is to manually fix permissions in your post install script. In your .deb package, you would have this folder and file structure:
DEBIAN/control
DEBIAN/postrm
DEBIAN/postinst
DEBIAN/preinst
If you put this in your postinst script, I think it should fix this immediately, without having to go into SBSettings afterwards:
#!/bin/bash
chown -R root.wheel /Applications/MyAppName.app/
exit 0
You can do more than that in the script, if you need other directories created, for example. But, the above will at least suffice to change ownership on the .app directory itself.
This BigBoss link recommends creating additional directories in your app's code, and points out that the installer runs as root, while your app normally runs as user mobile. Depending on what you're doing, it may be better to fix ownership/permissions in postinst (root) or in the app (mobile).
Related
We want to have the same VSCode settings for the whole crew of developers. Also it would be fine to have a oneline command to tear VSCode down and restart it from scratch with predefined settings and plugins so that you do not have to worry about trying out plugins and getting beck to the known state. Kind of Config-as-Code for VSCode.
I already found:
https://code.visualstudio.com/docs/editor/extension-gallery#_command-line-extension-management
https://github.com/microsoft/vscode-dev-containers
https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync&ssr=false#qna
https://github.com/gantsign/ansible-role-visual-studio-code-extensions
https://code.visualstudio.com/docs/remote/containers
https://github.com/gantsign/ansible-role-visual-studio-code
But non of these provides a good solution to me
We are using Mac and Windows machines and develop most of the time locally (not remotely in the cloud or the like).
I imagine like having a script like
.... projectname up
or
.... projectname reset
(or
.... projectname down)
to receive/reset the configured settings and newest plugins that have been configured for the project.
Have any ideas or use a similar solution already?
After doing a lot of research, playing with Docker, Ansible and so on... it seems that although I excluded it at first the plugin Settings Sync Plugin from Shan Khan is the way to go. It has round about 1 million installs!
Only dependency - you need a GitHub account to host your configs. That is what held me back at first - but it should be not that much of a problem to get one for everyone in the team and connect it to like a company-github-account.
Copy the files settings.json and keybindings.json to your target machine(s) to copy the settings. You can find those files here:
Win: ~\AppData\Roaming\Code\User
Mac: ~/Library/Application Support/Code/User/
Linux: ~/.config/Code/User
You can copy extentions from ~/.vscode/extensions or C:\Users\username\.vscode\extensions from linux/mac or windows respectively.
FalcoGer's answer should explain how to copy the files in a way VS Code will pick them up. If you only need to copy the config files once, this solution would be fine.
If you need to "sync" these config files on a regular basis, I would advise to create a Git repository where all config files will be stored.
When cloning the repo to local machines, you can symlink the files to the config destinations (see FalcoGer's anwser). Then when you need to "sync", you only have to run git pull and restart VS Code to apply the changes.
For your other script-related question, you could create a CLI for this. Python would be the most friendly way to do this. You can find an example here.
I use the command cordova serve to test the app in browser. But when I issue the command, I find all the code changes I made to the app has been disappeared include newly added js files etc. The app just got a complete reset. How can I avoid this and still use cordova serve command to test in browser? Thanks.
I got the issue resolved. It took sometime to figure out what is happening under the hood. As I was making changes directly in platform IOS directory, the cordova prepare or serve statement just replaces the code from the parent www folder.
To conclude, I have to make changes in root www folder and then issue the prepare/serve command that copies the code to the platform to test it out.
My question is, how should my Erlang app reliably find a binary in the priv directory, not just in production; when installed properly, but during common test?
I realised today when I added a travis-ci configuration to an old Erlang app and pushed it to git-hub, that the process by which it works locally for me, is a little more fragile than I thought. The travis-ci build failed because it, not unreasonably, checked out my repo into a directory named after the repo, which is of the form erlang-APP. Locally my app is in a directory called APP-VSN though.
The result of this is that a call to code:lib_dir(APP) returns a correct result during the common test run locally, but if I rename my current directory to erlang-APP instead of APP-VSN (or just APP works too) my local build fails, just like it does for travis-ci, because code:lib_dir(APP) returns {error,bad_name}. The behaviour as though .. is added to the library path for rebar ct.
Renaming my github repo from erlang-APP to APP resolves the travis-ci build failure... but knowing the build tests only pass depending on the name of the directory the repo is checked out into doesn't sit right with me.
One way could be to use a soft link (either in the repo under version control, or created when initializing the tests), and make your Erlang code path go via the link. E.g., "./APP" -> ".", or "./lib/APP" -> "..".
I'm trying to clean start karaf on Windows using clean option.
It does delete data directory with bundles cache but it copy new bundles into data directory from system directory not local maven repository. But system directory has stale jars in comparison to local maven repository which cause karaf to start with stale bundles.
Is this a 'feature' of clean option? Am I missing something? How could I start Karaf with latest code from maven repo not dealing with file system?
You can't as the system directory is per default the one to use.
The clean does mean to clear up bundles in a awkward state and is only rarely used. Sometimes this happens if you start and stop the karaf container very close to each other then bundle might be in an incomplete state and since those bundle state is kept only a clean will help. Another way of cleaning is to delete the data folder.
So what you look like to be intending is to update certain bundles that are installed from the systems folder. For that you need to install the never version cause Karaf nows which versions are in the systems folder, those bundles are defined in the framework feature which is the basic feature to be used by Karaf itself.
If you have your own bundles in the system folder there is no way of updating those as those are regarded to be bootfeatures. In case you want to update those you'll need to make sure those features aren't boot features anymore and after that just do install the never versions of your bundles and uninstall the older ones. This can be done with the command shell.
One side note, it's usually best to ask those questions on the users mailinglist of Karaf, you get more people to answer your questions there.
I'd like to know if there is any way to develop continuously with Trigger.io and avoid the forge build step with every file change I want to test in my browser or simulator.
I was faced with the same problem and I've got a working solution that uses watchr and watch to automatically rebuild each time I make a change to a source file. If you are running a "web" version of your app you can make a change to a source file and go directly to your browser and see the effect of your changes fairly quickly depending on how long the build takes.
Prerequisites: Ruby, watchr, Unix 'watch', and a terminal.
gem install watchr.
create a new ruby file for watchr to know what files to monitor and what to do when it sees a change. I named my file 'my_watch.rb': https://gist.github.com/3153167
open two terminals. Terminal 1 will run watchr and Terminal two will run 'forge build ...'.
In terminal 1 run 'watchr my_watch.rb' making sure the path to my_watch.rb is correct and make sure you've edited my_watch.rb according to your setup so that the path inside watch(...) reflects the files to be watched. My example watches all files in the same directory (and beneath) as the my_watch.rb script. You can place my_watch.rb in the 'src' folder of your Trigger.io app if you want to match my example and run watchr my_watch.rb directly from the src folder. Also not the shell command and path in the block need to be updated to reflect your environment. Again, in my example 'my_watch.rb' is inside 'src/' so when a change is detected we go up one directory and call 'forge build'.
I tend to develop actively with the 'web' version of my app so I can just open terminal 2 to my forge project directory and 'forge run web'. When I am testing in simulators and on devices, yes I have to run forge build every time I want to see a change. However, I typically don't have to wait for forge build to finish because watchr kicked off the build as soon as I made a change and it happens pretty quickly.
I know this is not an ideal solution but so far developing new features in the 'web' version first and then implementing in mobile versions has been very smooth for me. I've never needed to kill the 'web' version after a build but I maybe just lucky. As for running build each time you want to test the mobile versions if you are good with your keyboard shortcuts it really isn't bad at all. XCode makes you build and run after changes are made to source code when creating native iOS apps so I don't think Trigger is unique in requiring this build step.
I hope this helps and that my answer isn't too specific to me and my setup.
The build phase makes some changes to your source to enable the forge.* APIs - therefore, trying to just use the raw files in your src directory won't work.
You may be tempted to change files directly in the development directory, but this is a pretty bad idea: we delete those files with impunity when we need to!
We have plans on our medium-term roadmap to add a file-system watcher to start builds automatically when changes have occurred.
In the meantime, I just use forge build && forge run PLATFORM which tends to only take a few seconds...
while not perfect... this works for me.
go into development/web
rm src
link to your root src, ie ln -s ../../src src
copy the all.js from the web/forge and add to your index.html
ie
start nodemon web.js
open in browser.
note you will need to comment out the all.js script tag for non web builds.