I am working on a mobile application in Flutter to
create a Bluetooth connection
receive data from this device
plot them on the screen using SfCartesianChart
Everything works fine, except that after a while, the application freezes completely. There is nothing I can do but quit the application. I have looked at the "Flutter performance" section, but I can't find any useful indication. Also, I don't see any errors on my command line. It is a total mystery. I keep looking but it's hopeless.
Well, I never understand why people are giving a "-1" instead of explaining something but I appreciate your suggestions on how I can resolve this error.
Related
I have to fix some bugs in an app somebody else developed. I have not worked on iOS before.
The iOS app sends some data out every 15 seconds, this works fine. I can click the home button and go back into the app, works fine too.
Now the problem only comes when there is a change in the network, lets say I activate Flightmode.
When I go back into the app it crashes because of a NSRangeException. The problem is I can not get any Debug output out or anything, even if I put debug statements around all the places where this Exception can happen.
Could somebody give me a tip? How can a change in network have such a effect?
I have a question which seems like it should be a fairly common occurrence. I am trying to test code which only runs the first time an ios application is installed. While in principle this is very easy, I'm having trouble with it behaving properly the second time the app runs (note, this is not crash related).
I have been force running the app for a second time using the "Application does not run in background" flag in the plist, and then just hitting the home button. This works great, except i stop getting log data after the first run.
Does anyone know how to test for this situation in a way where you can continue seeing the log information after the app closes? For example, if there is a way to attach the xcode logger to the new process id? Or just another way to force an app reboot without losing the logging feature?
Thanks in advance!
Use the debugger menu:
Product>Attach To Process
(Results may vary with different versions of Xcode).
Also, you might need to insert a sleep at the very start of your launch to catch the very early log messages.
EDIT: If you're on a device then you can use the Device Organizer (cmd+shift+2) to watch all logs on a device.
I have a question,
i carefully went through and thoroughly understood the tutorial for iOS Core Data.
The issue was that when i coded everything and run on iOS 4 with multitasking.. the program crashed when i re-opened it (kill task from fast app switching and relaunch)
Then i went curious and recode it on iPad (since it hasn't support multitasking) and it works fine...
I went to explore abit, and some says that the fast app switching kill app is like the OSX kill app and there is applicationTerminate method in the delegate file which maybe need some changes (based on the comment).
Could someone enlighten me on that issue? Is there anything additional that i need to do in order to have Core Data to support the Multitasking feature..
Thank you!
Update
Ok but the thing i am not getting is that.. once i killed the app.. go Fast App Switch, kill it... and when i re-run the app.. it crashed.. Do i need to add some stuff to the multitasking methods? It crashes even if its a basic app with 1 button... What are the states that i have to save?
Update
The app just freeze on its own
Update
Alright my bad, trying my best, for the one button app... I sticked a button in there, and for each click, it prints an NSLog and a label. When i build and run it, it works fine, clicking it prints them normally. After going to background and close the app.. it sends SIGKILL Then when i relaunch the app, it no longer prints to NSLog and crash there 0x98a450f0 <+0000> mov $0xffffffe1,%eax 0x98a450f5 <+0005> call 0x98a453d8 <_sysenter_trap> 0x98a450fa <+0010> ret 0x98a450fb <+0011> nop
Update
However when i open the Iphone simulator and run the program directly... without building it from xcode.. It works just fine and it was able to print that value. Same is true for the Core Data.. if i just run it from the Simulator. Kill it and re-run, it works fine.. Not sure what's going on
With iOS 4.0, your app may not receive a -applicationWillTerminate call. It may only receive a call to go into the background and then be killed.
When you get the call to go into the background you should dump as much memory as possible to avoid being killed, that includes saving your context and perhaps calling reset on the context to get it to drop its cache.
Other than that, no changes need to be made.
What crash are you seeing, a stack trace would be helpful to explore this further.
Update
Again What crash are you seeing?
Update
Freezes where? Where does it stop when you look at it in Shark or the debugger? You are not giving me a lot of information to go on here :)
I'm trying everything i can to get instruments to profile my app on the actual iphone device, but it won't work no matter what i do. I tried the solution from Does Instruments (ObjectAlloc/Leaks) require the simulator? but that didn't work. Most of the time i get nothing of use from the console, but one time i did receive this error:
Mon Aug 31 11:27:48 unknown
lockdownd[14] : (0x83d400)
handle_connection: Could not receive
USB message #13 from Instruments.
Killing connection
I'm not sure what could be causing this; has anyone else seen this and know a solution?
Same problem - it worked the first two times, then after that never again (even after restarting Xcode, deleiting the device, etc).
Eventually I resorted to:
Set XCode to display the Console
Run with Performance Tool
(instruments starts, and goes "BEEP"
with no error - Apple "forgot" to
include the error message, I think.
ARGH!)
Build&Run on device
Once the (gdb) appears in console,
go to Instruments and select "Attach
to Process" from the drop-down at
top
If you cannot see the name of your
debugging app, wait a second, and
try again
Eventually your app appears in the
list of alread-running stuff, so
select it
Hit the Record button
On subsequent runs, Instruments will remember the name of your app, but will show an error if you hit "record" too soon. So you just keep hitting record and doing "OK" on the process it tries to connect to until it stops messing around and does what it's supposed to.
So far (20 odd runs) this works everytime. Obviously, it would be nicer if it just worked properly, without this manual hackery, but Apple is reporting zero error messages even to system console, so there's nothing we can do!
Has anybody had any success ever attaching a debugger to a tethered device? I am able to debug my j2me application in the emulator, but have a lot of trouble sorting out phone-specific problems when they come up. The phone I'm using is a Nokia N95, but ideally the debug process would work on any phone.
Is this possible? If so does anyone have steps they've used to set it up?
Sony Ericsson supports debugging on ebery phone at least since K700, this is done by using KDWP. UIQ 3 communicators also can be debugged the same way.
By the way, it the latest phones by SE it is even possible to monitor memory consumption and CPU profiling. So if you wanna debug your apps on real phones, I would suggest also using SE phones, they are really good at it. I use Netbeans, and it works without any problems with any SE phone.
Motorola phones support a debugging interface called KDWP(Motodev registration required).Their MIDway tool can also be useful for getting debug trace information from a midlet running on a device.
As other stated, on device debug is something that strictly depends on manufacturer's will and often it's nearly impossible. However, i can address you to Gear Java Mobile Framework that gives you the opportunity to use an on-device debug console to print your messages and thus read phone specific issues. If you need some explanation on how to use it, take a look to this tutorial
Unfortunately this is not generally possible. Some makers (like Sony-Erricson) support this on some of their phones but not all. I am not sure if there is on-device-debugging tool for N95 but you can use Nokia's emulator which should be pretty close to the device. The new Java ME SDK comes with promise of real ODD in near future. But it still very much depends on OEM cooperation.
I find a good debugging method is to control a string value which gets painted on top of everything else when it is not null. This will work anywhere, though obviously isn't ideal, but can be used to catch Exceptions, print values etc. Of course you're limited to the small screen, but in theory you could even code some scrolling functionality.
Some people use RMS logging but personally I could never be bothered.
As others have said here, Motorola have Midway which I think is great.
Others are correct here in that on-device debugging is very much device specific. I haven't done anything with Series 60, but at least on Series 40 phones, I had to open up a CommConnection and write out to it in order to see much of anything going on. The device emulators are again a mixed bag, but you usually can get 90% of the way to your application working on them and can usually get your debugger connected to them. If you aren't making use of any of the hardware on the phone, that should get you most of the way there.
I've used the Blackberry tools on occasion to debug J2ME applications (without using RIM APIs) but it is very slow and still is only emulation, not the actual device (but it sometimes does help to shake the odd thing out). I agree it is frustrating when you have something running on an emulator only to find that it doesn't run on the hardware.
You can not debug step by step like android or other SDK.
In J2ME you can trace the error by adding the log statement in the code and add another midlet and display that log screen in that midlet.
Example: add Log.p("Log statement.....");
LogMidlet.java
// Add the following line in the startup method of this midlet.
Log.getInstance().showLog();
This way you can somehow track the error in j2me.
I think it is possible to add additional debugging information on preprocess step. Like this:
public void myMethod() {
Debug.traceMethod("myMethod");
int var = 1;
Debug.newLine();
var++;
Debug.newLine();
...
}