After using sometime App crash on User Device which I don't have access to it. I have read the blog about using the CN1Libs-NativeLogsReader to see the error occurred on remote devices. I would need some help on how to use it for this kind of issue for debug builds. Please advise.
That won't save you from a crash as that would be too late in the game.
You can use the API to get the native log but you can't use it to catch a physical crash.
Related
Is there an equivalent of the browser console in AIDE? It took me trial and error to find out that it doesn't seem to support local storage (or at least the library that I'm usings implementation of it)
Should I wrap everything in one big try Catch block? I've googled and searched, I suspect I should be doing better error handling.
Here's what I ended up doing. You can share the published web app from aide when you're running it. Open it in Firefox for Android after downloading the console add-on. It's not as fully featured as a desktop version but it's close
It feels like poor form to answer ones own question, I earnt the tumbleweed badge for this so perhaps I can be forgiven!
I am developing an app using react native, I use some code base for ios and android, the ios version run smoothly.
But the android version run very slowly. the weird thing is:
When I shake the phone, and click "Debug JS" to enable debug in chrome feature, it run faster, anyone have a clue about the reason?
Sometimes, one or more than one active console.log() lines cause this issue.
console.log lines should be searched and deleted if they exist.
Also in production, babel-plugin-transform-remove-console can be used to clear all console.* methods automatically.
The reason for different execution speeds of javascript code when running in debug mode and without is that when you are in debug mode, in order to enable the debugging experience React Native executes the code in the Chrome browser on your computer, and the results of the execution are bridged onto the device.
Outside of the debug mode, the code is executed in the JavaScriptCore engine on the device itself.
That said, I cannot explain why the execution is so slow on the device. Are you perhaps running on an low-powered device, or an emulator with limited allocated memory?
React Native app does run slower on Android. But the performance is not real during your development. You can build a release version to check the real performance, release version is much faster than dev version.
There are also some bad codes which can make your app slow. Like console.log(), it does slow the app during development. Avoid unnecessary re-render the view, don't use arrow function and .bind in render, etc.
I have the same issue on IOS device (ipad4, ios10). I don't use redux-logger and removed all console.log, still don't know what makes the app so slow. It takes 2s to swich between tabs.
"react-native": "0.41.2",
"react": "15.4.2",
"native-base": "^2.0.10",
I know it is an old topic but suffered the same problem. I applied the above solutions but the problem still presisted. Later I found out that problem caused by a emulated USB storage device rather than mounted as a USB disk. Because when you upload signed Apk file and install the appllication from this file it causes problems and gives write error e.g. hiddenly but don't gives error messages much. I hope changing from emulated storage device to mounted as a trivial disk helps who suffer the same problem like me.
My application is crashing sometimes while running on real device but the debugger always goes to "main.m" class not where the app is exactly crashing.
Infect console log is also not telling anything about the crash.
I think there is some settings required for debugger but not exactly know the right solution for that. Please help.
Check your device logs for an app type of Unknown. Often, an app will crash by being killed by the OS and an unknown log entry will appear on your device logs showing that your app is the largest memory consumer. To figure out which piece of code is causing the crash, evaluate the UI behavior and add a breakpoint at the appropriate spot (probably where you start working with your data).
Perphaps this could be a memory issue. In that case debugger does not show warning or exceptions. you can use instruments like profile provided in xcode to backtrace the issue. You can also backtrace your issue in Report navigator in xcode.
You can also use apps like crashlytics. Upload your build to crashlytics and then download it from theer and use it. Once it gets crashed .Login on web and check for the crashes. It will show the exact line where got gets crashed.
I hope it can help you.
I have a codenameone app that works fine in the desktop emulator (windows 7) but when I run it on my Xperia Z1 (android) it crashes when I try to show a new form (this has been working fine).
I am currently using the free account and so do not get crash reports (e.g. a call stack). And it'll take me forever to keep trial-and-error hoping to find it ....
Any suggestions?
Install the Android SDK, connect your device with a cable and launch the DDMS tool to connect to the device. You should be able to see the log messages and stack trace thru that and it might give you a better indication of what is going on.
I have registered my Phone 7 app as a Share Picker Extension. It works—my app is in the list of Share options and it gets launched and I can load the chosen image. Okay, great.
But then things go wrong in my code. I would like to be able to debug the issues, but I can't seem to keep the debugger attached.
I cannot debug this in the simulator, since the Pictures app (and thus the Share Picker functionality) is not present in the simulator.
I cannot debug this on the phone because as soon as I pick my app from the Share list, the debugger detaches... right as my app is "launching" again.
Is it possible to attach the debugger to a running WP7 app? Is it possible to keep the debugger attached? Am I doing it wrong? Any suggestions, advice or guesses are welcome because I'm tearing my hair out.
When doing M+V hub integration (sorry, haven't done any pictures hub integration yet) I initially used a crude debug technique (Messagebox.Show, etc. - like Justin mentioned) to verify what was being passed to the NavigationEventArgs of OnNavigatedTo and wrapped the whole method in a try..catch block to learn what was going on. I then refactored the code when I knew what could be expected. (Remember OnNavigatedTo will be called when your app is launched normally too and so e won't be populated in the same way.)
When the app is launched from a/the hub it creates a new instance of the app and there is currently no way to connect to this for debugging while the main page is being navigated to.
Great question. I'm unsure if that's possible. As far as I know, there's no way to attach the debugger to when the WP7 O/S starts an app (which wasn't triggered by the debugger).
Photo Share picker extensibility, music+Video hub extensibility and other O/S extensibility points seem to not play nicely with the VS debugger. Normally I resort to MessageBox.Show to debug any problems with WP7 O/S integration.
1) Connect the Device
2) Turn off Zune
3) Start C:\Program Files\Microsoft SDKs\Windows Phone\v7.1\Tools\WPConnect\x86\WPConnect.exe
To properly debug your application that uses the Media Library, you'll need to use the Windows Phone Connect Tool (WPConnect.exe) as described on MSDN. Jaime has some additional tips on his blog.
Once you are connected, you should be able to debug your application. Fingers crossed anyway. If that doesn't help, I'll dig a bit further.
It's not so much about the WPConnect tool. The nature of your application means that you have to have it closed and the user should pick a photo. Only after that the data is returned to the application.
You should read about the application execution model on Windows Phone 7. Also a good explanation is available here.
Initially, I would say that you should look at tombstoning (a good explanation here) but then again, the image returned will re-start the app and won't allow you to directly attach the debugger.
Yeah, looks like this is impossible...
All the answers above seem to be missing the point: I presume you're able to debug your app in the "standalone" mode (when it's launched normally), but not when it's launched via the Share Picker Extension. Am I write? This is the wall I'm hitting... :-(
I thought the proper way would be to attach to the process once it's launched.
I tried to use Debug > Attach to Process, then select Smart Device as the Transport and Windows Phone Device as the Qualifier... But in return I get the ugly "Unable to connect to 'Windows Phone Device'. Not implemented" message.
Bummer :-(