I am using IBM's MobileFirst Platform Foundation (6.3.0.00-20150130-1638) to build an Android and iOS application. The application (iOS at this moment) gives quite a lot of information when running. But one is quite common and I think it is also quite dangerous. The error I get is:
THREAD WARNING: ['WLApp'] took '11.354004' ms. Plugin should use a background thread.
This is for WLApp, but for more plugins like DeviceAuth (111.884766 ms), UserAuth (19.232910 ms), another DeviceAuth (47.208984 ms) and more.
Is there a way to run plugins on the background, and so, how can I achieve this?
Another question is if I can and how to hide the Debug notifications?
These warnings come from cordova plugins, and it is harmless, it just means that the code in the executing part of the cordova native plugin side, should be run in background.
We are intending on cleaning these warnings out.
look at: http://docs.phonegap.com/en/4.0.0/guide_platforms_ios_plugin.md.html#iOS%20Plugins
You cannot do this on your own with the supplied plug-ins.
These warnings are issued by iOS but are harmless.
We'll take a look, but this is harmless, unless you actually see a real problem (which I doubt right now that you do).
Related
Below you can see the output I get when I try to run npx react-native run-android. It suggests some options to try in order to further pinpoint the problem, however they don't work with the aforementioned command so I assume that they are related to a gradle (just an educated guess).
I know ZERO about gradle; I have just seen the name here and there and in the output shown below. So please keep that in mind when you answer. If I need to learn how to run some gradle command(s) directly, please be as verbose as possible in your answer.
The project was working fine just a bit ago, but I wanted the ability to force portrait mode for certain screens but without configuring my entire app to always have to stick to portrait mode. So I found what looked to be a solution in the react-native-orientation-locker module. I installed it with yarn and then proceeded to update files as directed: https://www.npmjs.com/package/react-native-orientation-locker.
After updating the appropriate files, I got an error that suggested axios was the problem. I uninstalled and reinstalled axios. After that didn't work, I proceeded to undo all the file changes I had just made. Then I uninstalled the react-native-orientation-locker module.
To my knowledge, I have undone everything I did between the time the project worked and stopped working.
Sadly, I had not put this into source control yet (a mistake I won't make again), so I can't revert.
Where to go from here?
Problems like this are hard to pin point. What you can do is open the android project in android studio and see the logs as the project is being assembled. I assume you do not have much knowledge about android either so you might need some senior resource to help you.
What I usually do in this case is open android studio and if I am lucky enough, it tells me which file has an issue and I go to the file and do what android studio suggests me. Some times it fixes the problem and sometimes it doesn't.
Another thing I would like to mention is that the documentation of the package you are using is important to follow. I assume you did that already but I would suggest to review it narrowly and closely.
Another guess I can tell you is try to go to your-project/android/build.gradle and over there, you'll see something like this in the start. The package you are using mentions something about target SDK 27. I think you should check that out too. May be it helps
Lastly I would say always use source control while working with react native. It can easily blow up at any time so you should always have a safety net to fallback to :)
I'm currently trying to push off some time consuming tasks to an actionscript worker. This worker will in turn needs to call out to an AIR Native Extension as part of it's processing.
I've tried various combination in Flash Builder 4.7 i.e. embedded worker and external worker (with explicit packaging of the ANE in the external worker project) but alas I've been unable to get this to setup to work. I keep getting an error from the worker saying that the native extesion class could not be found (Error #1014).
Does anyone know if it is at all possible to do this or it's a limitation of Actionscript workers?
I'm guessing this might be a bit late now, but I've just been having this problem myself, and it was caused by the ANE not being packaged with the app when it's sent to the device / simulator.
Classes within the NE weren't being found at runtime, but were accessible in Flash Builder.
It turned out that by default the .ANE file wasn't copied to the device.
To fix this, change the following project property:
ActionScript Build Packaging -> Apple iOS -> Native Extensions -> Check 'Package' for the ANE
No idea why it wasn't included by default. When you uncheck 'Package' you get a warning telling you that it may cause runtime issues!
Hope this is of use for somebody.
I have an OSX application written in Objective-C/Cocoa using xcode. The application is quite finished, tested and sold on the App Store.
I haven't worked on this application for some time and recently, I rebuilt it using xcode 4.3.3 on my OSX 10.7.4 and I noticed that while it builds just fine, there are some very strange visual glitches when running the application that were never seen before and occasionally, I get EXC_BAD_ACCESS when closing the application. All these seem to be related to the PDFKit framework I am using. I am unable to debug these problems since the glitches are just visual (nothing I can check in code) and EXC_BAD_ACCESS exception comes from internally allocated objects not related to my code.
The code itself haven't changed, I tried previous revisions of the code and they all exhibit the same strange behavior now. I tried running an old binary I have of the application (compiled couple of months ago) and it works just fine. Then I tried building it with previous versions of xcode, down to 4.2.1 (which I know was ok when I submitted the app to the app store) and the problems still occur.
Then I suspected this may be something specific to my environment so I built the project on different machine also with xcode 4.3.2 and OSX 10.7.4. Same results, the problems are still there.
So now I suspect that it has something to do with the OSX 10.7.4 update since this is the last thing that was changed between now and when I was able to produce a good build of the application. I am pretty puzzled to what to do next and how to identify the cause of this problem. I have an old binary that is working fine and I have a newly compiled binary of the same code revision that has problems.
Is there any useful information I can get from the difference of these binaries? What can I do to determine the cause of these problems? What can I try next?
Thanks!
NOTE (update): I stated it above but I want to make sure it is clear. This is a Mac OSX Cocoa application, not iOS.
just reset your simulator then try.
I hope you check the ARC information
go to your project Target set build settings --> Search Paths-->Always Search User Paths Set Yes.
And check your all class variables different from one another.
Xcode--> preferences-->Documentation check installed core Libraries (or) install it
like that
Xcode--> preferences-->Components check required component installed or not
check these things in your project.
Are you sure your customers are not having the same problem? Since you have tested the application on a different machine you probably do not have corrupt libraries installed (unless you did not install from scratch but used some migration tool?), so that is probably not the problem.
Most logical explanation to me would be that your customers also have this problem but they haven't reported it yet. In that case, you probably have a memory problem and there are techniques to attack that.
In any case, eliminate all the parameters that you can eliminate to simplify the problem. Deconstruct the application until the problem does not occur anymore or reconstruct the application in a different project until the problem occurs again.
It sounds like a nasty one, but you'll get there in the end, with patience and perseverance :)
First of all, you need check and verify the build log for suspicious compiler warnings.
For EXC_BAD_ACCESS, XCode analysis will give useful information.
You could try 10.6 or 10.5 (need manual installation) SDK. Or restrict the deployment target to 10.5 or 10.6.
I will answer my own question (since none of the above answers really answer it) so anyone with a similar problem might have a hint. I was not able to understand why exactly this happens but I'm pretty sure this is not a problem with my code but rather some glitch on Apple's side. And there is a workaround.
First, I compiled Apple's sample "PDF Annotation Editor" project on my Lion 10.7.4 and while the functionality is obviously different from my project, it also exhibited similar glitches with the PDFView display that my project does when compiled with 10.7.4
Then I proceeded to building a fresh clean system on new hard disk. Intalled Snow Leopard and upgraded to 10.6.8 and ONLY installed xcode. Compiled my project (the source code always stays exactly the same) and everything works fine. No problems seen in the compiled project.
Updated my OSX to Lion 10.7.4 and xcode 4.3.3, same source code. The problem is there after I compile it. I am pretty sure that if I tried 10.7.3 first, I would not see the problem as I remember it only starts with 10.7.4 but Apple doesn't provide any reasonable way to update to 10.7.3 first or downgrade to it after 10.7.4 is installed (shame on them, not very developer friendly!).
So, the problem appears in 10.7.4.
Then I installed the pre-release version of 10.7.5. This was the only thing that was changed, same source, same xcode. To my surprise, the compiled code works flawlessly now and the problems seen with 10.7.4 are now gone!
So my workaround - wait for 10.7.5 release before working on the project further. Hopefully Apple won't screw it in the future with Mountain Lion. I don't think I am going to try and debug it further or submit a ticket to Apple, going to be a tough case to explain.
Thanks for the responses.
So I just finished my app and I wanted to as the final few steps run some diagnostics on it. In terms of what its memory usage, allocations, leaks, etc are.
I have a few questions:
1) Is there a standard list of instruments/checks I should run on my app be fore its submitted to make sure its robust? If so could someone point me to some links and/or tell me some names so I can google the stuff.
2) One of the tools I know to run is NSZombieEnabled. I followed the steps I found online on some sites to set up this NSZombie test but it doesn't seem to be working. I looked at this site: NSZombieEnabled
This is what my XCode looks like after I tried the steps listed there:
But why is the zombies choice not highlighted?
Once I get it to work how do I actually use NSZombies?
So far from what I know, NSZombies is only available for debugging Mac apps or ios apps running on the simulator. It cannot be used for apps running on i devices.
Follow this thread and this.
I'm making a iPhone App written in Objective-C using the Cocos2d game engine.
I'm using Xcode v3.2.1 with the 3.1.2 iOS. At this point I have always ran my project under Debug Configuration. When I set it to release configuration certain elements of my game are no longer behaving correctly.
My logic that worked in the debug configuration doesn't work in release configuration. What makes release configuration behave differently and what about release configuration would cause problems in the code. This holds true on both the simulator and an actual device.
I'm thinking it may be something within one of my loops, but I'm not sure. Is there guidelines that should be followed under release configuration that are different then debug configuration?
I also ran a Build and Analyse thinking perhaps I was doing something I shouldn't but it came up clean.
Differences between release and debug builds are often caused by uninitialized variables.