I am tried deploying .cod,.alx.jar files on blackberry simulator 8100;the application is not getting deployed on phone.I am using Blackberry plugin for Eclipse.
How can I solve this issue?
Please help
Update
Hi,
Thanks for your reply.
I am trying to run the application the way you suggested.
Do I need to setup new run configuration every time I run any project?
What should be default value for build configuration ? [Debug,Private,or Release]
Copying the .cod files into the simulator's directory (where all the other .cod files are) and restarting the simulator will work.
Probably though you want to automatically deploy from Eclipse. If this isn't working for you, there are a couple of things to check:
Check that the project has been activated for BlackBerry - from the right-click menu for the project, make sure that Activate For BlackBerry is checked.
If that's already checked (as it is by default when you create a new BB project), then sometimes explicitly building the project will do the trick: From the Project menu, choose Build Active BlackBerry Simulation
EDIT: In response to some comments below I thought of something else. The configuration you choose may have something to do with your problems (BlackBerry -> Build Configurations). The configuration in the JDE Plug-in doesn't affect the code generated, but it does affect which projects are activated for BlackBerry. If you switch configurations, your project may become un-activated.
Since it doesn't affect the code, I usually just pick one configuration and stick with it throughout debugging and release.
You might be missing 'jar' in your PATH. If so, the eclipse BB plugin silently fails and your application won't be pushed to your simulator plugin directory. To see this failure within eclipse, choose 'Project > Build Active BlackBerry Simulation'.
If you don't have jar in your path, then you will see:
I/O Error: Cannot run program "jar": CreateProcess error=2, The system cannot find the file specified rapc executed for the project
So, if your JDK is here:
C:\Sun\SDK\jdk\bin
Then append it to your system environment's PATH variable, then re-run 'Build Active BlackBerry Simulation' and you should see:
rapc executed for the project [YOUR PROJECT]
Here are a couple of ideas:
1) If you have any build errors then the application won't deploy to the Simulator. The Eclipse compiler (that underlines compile errors in red) is different to the "rapc" one that creates the binary for the Simulator. I have heard of situations where the Eclipse build seems to work, but the rapc compile fails - check the Console for the detailed rapc output (this might not look like a normal Eclipse build error).
2) In the Eclipse menu, open BlackBerry -> Configure BlackBerry Workspace.
Under BlackBerry JDE choose Code Signing and make sure the three RIM checkboxes are selected. I had compile errors when these weren't selected.
Under BlackBerry JDE choose Installed Components. Choose to use the Component Package 4.7.0 as I have heard of problems with the 4.5.0 Simulator.
You should delete all these extra answers you posted, or you might get downvotes - they should be comments instead of answers.
Check if your simulator is set up to clean the file system / configuration before launching the simulator. Simulators can be set up like this. If you deactivate it, the application should not disappear.
For future readers, there is another possibility for this issue. Check your workbench project directory (folder) for a ProjectName.err file. This may provide a clue as to why your build is silently failing and thus not deploying. In my case, it was an "Error!907", a new icon I added to my project was too big. There was absolutely no other indications in Eclipse 3.4.1 that there was a problem in my build.
Just ran through the same kind of problem : project compiled fine but didn't deploy on any device or on any simulator, even though the debugger said it was attached !
The problem came from a .zip file that was located in the ./src directory of the project, deleting or moving it somewhere else resolved this case.
I wish I hadn't spend 2+ hours on such a stupid problem :/
I know this is old, but you have to do the "generate ALX" option from right clicking the project menu as well or it won't deploy, at least it doesn't for me.
I ran into the same problem again and none of answers posted here worked for me.
I played around and finally made it work. The problem was that the output file name contained a hyphen ('-'). Changing this name in the Build section of BlackBerry app descriptor did the trick.
I mean, how stupid a developer must be to slip that kind of bug. No error reported and why reject the names with hyphens in the first place? Give me back my two hours RIM "developers"!
I had the same problem. The reason was using 'ü' character in the title.
I have been facing this problem today, but with a MIDlet project. It turned out to be that I forgot to specify the "Name of main MIDlet class" in the BlackBerry Application Descriptor (BlackBerry_App_Descriptor.xml). Once I specified it the application appeared on the simulator correctly.
Related
I've got a very curious error to share regarding Xcode localization process. I will try to share as much detail as legally possible.
From Xcode, I am trying to export an XLIFF file to send to our translators, via "Editor > Export for Localizations". However, this immediately throws error with the message:
The operation couldn't be completed. Argument list too long
This is indeed confusing, as I cannot find a more verbose log anywhere (I have already tried checking my Console.app). So, I spent quite a few time googling – to no avail. I couldn't find similar case like this. The error itself happens only when I am trying to export for localization. I can build and run the app just fine.
Facts
~ $ xcodebuild -version
Xcode 8.2
Build version 8C38
~ $ xcode-select -version
xcode-select version 2347.
~ $ echo $PATH
/Users/david.christiandy/.rbenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/david.christiandy/arctools/arcanist/bin:/usr/local/go/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands
I am using Xcode 8.2 on macOS Sierra 10.12.5.
The error happens only when I try exporting from localization. This is also true when I run the localization process via xcodebuild -exportLocalizations.
I can build and run the app just fine. (I believe) there's no problem with my header search paths.
Attempts
Thought there was something wrong in the code, so I tried to run the export process (via xcodebuild command) in a CI. Somehow, it's working. For the record, I am using Bitrise CI with the same stack as my system (Xcode 8.2.x, macOS 10.12)
Asked colleagues to run export process on their machines, and they have the same error.
This leads me to think that there must be something wrong with the configuration. So I made a standalone project to confirm that the export process fails consistently. Turns out, it works just fine!
So, the hypothesis I got currently is:
There's probably something wrong in the code, and
There might be tools/software (that most of our iOS engineers installed) that might contribute to the error (since the CI completes just fine).
I don't know why the CI can run the export process just fine, and I don't know when it might suddenly stop functioning (just like our local machines).
Appreciate any help on this matter. Thank you!
I also asked this question on Apple developer forums, here is the link: https://forums.developer.apple.com/thread/86762
“Argument list too long” sounds like E2BIG, which you get when you try to run a child process with a huge argument list (I believe the current limit is 256 KiB). I suspect that Export for Localizations is running some sort of command line tool to do that work (probably the extractLocStrings tool, which you’ll find lurking within Xcode’s app bundle) and passing it full paths to each of the files in your project. Depending on how many files you have and how long those paths are, it’s easy to run into problems like this.
One of the ‘fun’ things about bugs like this is that they are dependent on where you place your project. Things might work if the project is at the top of your home directory but fail if it’s nested deep inside a subdirectory.
That also suggests a potential workaround, namely, to move your project further up in the directory hierarchy.
Finally, you should definitely file a bug about this. I believe we’ve seen this before (r. 30703294) but your report will help reinforce that this is causing problems for developers in the field. Please post your bug number, just for the record.
Several days ago before I read this answer, I managed to get the export working by deleting some folders via Xcode (remove references only). Initially I suspected that there's an invalid format within the folders that I deleted, but when I tried deleting other folders, the export process works just fine.
I also tried exporting strings using Xcode 9, and I didn't encounter the problem. So hopefully this bug is only for Xcode 8.3.3 and below.
Every time I meteor build, I have to open XCode and do the following:
remove and add an item from "Link Binary With Libraries" (Facebook SDK)
add a URL Type (custom URL scheme for my app)
add a "Required device capabilities" to "Custom iOS Target Properties"
How can I edit my Meteor project to have these steps done automatically, and to auto add things to AndroidManifest.xml?
In some way use mobile-config.js or cordova-build-override?
I'm happy to see another guy who is trying to build a hybrid application using Meteor / extending a Meteor Cordova iOS app, since I'm facing the very same issues. So I'm very happy to share my experiences and approaches with you. :-)
So far, I ended up with the following approach:
I created a base template for my iOS app using meteor build (not meteor run ios-device, since I did not know if Meteor does some optimizations for production code).
Then, I copied the whole Xcode project under /platforms/ios to another loaction and used this new project as my "master" project from then on. This project is being enriched with native code, e.g. it also includes the Cocoa Pods I'm needing.
Of course, I also did not want to copy files each and every time I trigger a new Meteor build. At least, I would like to have the Staging/www folder updated, as this is happening quite frequently.
So my first (rather naive) approach was
delete the Staging/www folder in the master project
replace it with a relative link (using Xcode's linking functionality) to the Staging/www folder inside the .meteor/local/.../ios/ project
This approach did not work, since the shell script used in the Meteor Xcode project can't handle these links.
My second approach is to create a symlink on the filesystem level instead. This works as it should, and I'm able to build the project in Xcode as it should.
I could have followed the same approach for the Cordova plugins folder, but I've decided to replace the plugins manually in order to get a better control over them, even it means a bit more effort then.
Having the symlink in place also means that Xcode's version management (and also SVN which I am using for everything) will ignore everything below Staging/www, which is good in my opinion, because I'm already versioning the webapp code in the Meteor project itself.
BTW: I've started a discussion thread on hybrid mobile app on the Meteor forums as well, but so far it did not get too much attraction:
https://forums.meteor.com/t/building-a-hybrid-meteor-cordova-app-share-experiences/8212
Maybe we could follow up on Meteor-specific things there, to have the Meteor community participate in the discussion?
EDIT: I would also like to share an approach that failed completely, at least for me, maybe I was too dumb... Before I used Meteor's Xcode template as the starting point, I also tried it "the other way round", i.e. I started with my already existing Xcode app project and tried to include Meteor's / Cordova's part by hand. Using this approach, I never managed to set everything up correctly. I had lots of troubles and also had to tweak a lot of the compiler / linker flags to even get the code compiling. This grew me a lot of gray hairs. But even after I managed to get everything to compile, Meteor hang during startup - and I never figured out why.
One remaining problem I'm still facing is that Meteor's hot code push functionality seems to have some severe issues on iOS, that are also documented as GitHub issues. It can happen that the iOS app gets completely broken and needs to be reinstalled. I tried the mdg:reload-on-resume package, but this did not work as it should and made things even worse. As far as I can tell from the GitHub discussions, one should better disable hot code push until the Meteor team has addressed these issues. Breaking the app completely due to code pushes is not what my users would expect.
Unfortunately plist values (and assumably AndroidManifest.xml as well) can only be changed by a plugin:
Add entry to iOS .plist file via Cordova config.xml
I am creating an installer using the Adobe AIR captive runtime feature. Normally, the compiler generates a directory for me with all the necessary files that I then use to generate an .msi installer with.
Before, I could just double click the .exe file in this generated directory and the application would already work. (Good way of checking whether the generated files are valid).
I have now stumbled into the situation where I double-click the .exe file and nothing happens. No error message, no logs, nothing. The .exe file just exits immediately.
I have dug up and older installer of my app and tried to run this, the resulting install works fine. But once I replace my SWF file in the install directory with a new build of my app, I once again have the problem.
So, obviously SOMETHING in the Main.swf doesn't agree with the .exe file, but since there are no error messages or whatever it is extremely hard to figure out what the problem is.
The application runs fine from the IDE, by the way, the problem only occurs when I use it in combination with the captive runtime output.
Has anybody ever experienced something similar? And how were you able to figure out what was going on? Is there some secret place where AIR perhaps logs some errors, or is there a way to convince it to output some kind of error log?
You need to create a blank file with no extension called "Debug" (I used textedit and simply removed the extension manually). Put that in the META-INF/AIR/ folder, next to application.xml. This will cause the Air runtime to run in debug mode.
From what I can tell, if there are any fatal errors (e.g. a certain failover .swz file can't be loaded) then at least you'll be able to see what's going on.
Did you manage to make this work?
I haven't touched any of my Blackberry projects for about 2 weeks now. Today I had to make some modifications, but when I tried to compile and run my code I got an error message like the following (this has been simplified):
JavaBuilder handling CoreException
org.eclipse.core.runtime.CoreException: File not found: C:\Program Files\etc etc etc\ClassName.class
And this error pops up for every single one of the files in my project.
I'm not a Java professional by any means, but I'm pretty sure this has something to do with my build path. What do I have to do? I did a system restore a little while back don't know if that has anything to do with this.
Thanks a lot.
Problem solved. For some reason alot of the folders in my project's folder were duplicated (ie: mainpackage, mainpackage(2)), so each one of my class files had a twin. Eclipse didn't tell me this, instead it just decided to say "I can't find the files" even though they were there. Not a very useful error message.
So I deleted mainpackage(2) and now it runs fine.
Thanks again for the help.
I'm trying to sign our BlackBerry app, but now it's asking for "RIMAPPSA2" signing key, which is the signing key for private APIs (which isn't allowed in the app world I assume). So I want to remove this requirement so I can actually run the app on devices.
There's nothing in the build log. My app does NOT use any of the following packages (which the internet suggests might be the issue):
net.rim.vm.Persistable
net.rim.vm.*
net.rim.device.api.browser.field2.*
net.rim.device.api.browser.field2.debug.*
net.rim.device.api.script.*
org.w3c.dom.jsp2.* <- actually is uses org.w3c.dom.*, but I've had an app not require this that already had this package in it.
net.rim.device.api.io.Seekable
And I'm not importing any external JARs (although I was before). I'm using the 4.5 JDE.
How can I find out what is making the signer tool require this signature?
Is there any way to track down what is causing this signature (RIMAPPSA2) to be required?
This might be due to a bug in Eclipse or RIM. You might not be using the RIMAPPSA2 classes.
OK, so its hard to believe but this page might fix the problem for some:
Frustrations with Blackberry Developer plugins for Eclipse
Basically its a bug, and by changing the Application Descriptor, saving, removing & re-adding the JAR file, the problem is fixed.
Follow-up #1 - might not work:
The above solution enabled me to build & sign the app. Unfortunately the app won't run on the phone Module 'MyApp" attempts to access a secure API.
Follow-up #2 - this worked for me:
I documented a full solution that worked for me here:
BlackBerry - use own JAR file in own project
In my case, I was importing my own JAR file, and I needed to set that project's build type to be a MIDLET. Setting it as LIBRARY or APPLICATION caused problems.
I've not tried it, as I am waiting for my signing key.
If you use eclipse, you can have following settings that can be turned off.