I have developed a Java ME application for CLDC platform. It works fine when executed in an emulator. But when i deploy it to my N70 phone the application doesn't start at all in the phone. In my application there are some 14 classes and am creating an instance of each and putting them in the vector on application start. The classes just have one variable and 2 methods. Can this creating of lot of instances be the reason for its crashing?
Is there any way I can find out the reason why the application is not able to start in the phone?
Update:
Its running fine on emulator. And one more thing I would like to mention is that- The code stops executing only at the point where am creating those 14 instances and adding them to the vector. Till that point the code executes fine.
It might depend on where in the code you are creating those instances. If you are creating them in your MIDlet constructor or the startApp method try moving the initialization into the run method of your application.
One way of debugging J2ME applications that don't start on the phone is by adding "printf" style debug messages in your code to be written in the record store system and adding another MIDlet to your application to read from RMS and display those messages.
Or you could just comment bits of code and see if it works.
You can debug on device. If the emulator you are using is part of the Nokia SDK then there should be facilities elsewhere to carry out on-device testing and debugging. (I'd post more detail on this but I've only done this with Sony Ericsson phones recently.)
Another option is to use the Nokia tools that allow you to view the standard output and error for your application when it is running on your device (via Bluetooth for example).
The probability that your application is actually crashing the Java Virtual Machine bytecode interpreter thread and terminating the whole native process is very small.
It has happened before but you need to eliminate several other potential issues before being convinced of an actual crash.
It is more likely that either:
Your MIDlet is not created or not started because the MIDP runtime decides it is not correct.
or
Your MIDlet simply throws an exception that you don't catch, which can make it look like it was brutally terminated.
Since the MIDlet installer is supposed to prevent you from installing a bad MIDlet, the uncaught exception issue is more likely.
How to find an uncaught exception:
Start with the simplest HelloWorld MIDlet, using a Form so you can easily insert more StringItems at the top of the screen.
Create and start a new Thread in MIDlet.startApp()
In your override of Thread.run(), add a try{}catch(Throwable){} block.
Inside that block, do whatever your original MIDlet did.
Use the form as your standard output for debugging.
You can use Form logging to make sure you don't enter an infinite loop, to display exception classes and messages, to flag logical milestones, to display variable values...
That's the first step to figuring out what is going on.
I also faced a similar problem and when I recompiled my MIDLET as Midlet 1.0 then it worked fine. It seems like N70 is not able to run the new version of MIDLET. I think you downgrade and re-test your midlet.
Regards
Junaid
Related
I have started learning Android development recently and have some doubts. " What invokes onCreate method to get called automatically when we create new project or create a new activity ? And how is it getting called"
I tried to search it. But not getting the proper answer
I don't know if there's a specific spot in the documentation that explains this clearly, so I can't really cite sources. This is just what I've picked up over time working in Android and looking at source code.
The Android OS is responsible for launching Activities. An Activity is found and launched through an Intent. It could be internally done in your own app. Or if it is the entry point to your app, it could be launched by the home screen launcher app of the device. Or in debugging mode, the OS can be commanded to launch a specific activity (this is what happens when your Run your app from Android Studio).
An Activity must have an empty constructor (a constructor with no arguments) so the OS can create an instance of your Activity using reflection. Since the OS cannot know of all possible Activity classes ahead of time, it must use reflection to find the constructor and call it.
After it has an instance of your Activity, the OS manages its lifecycle. It will call lifecycle functions like onCreate() at the appropriate times in its life. onCreate() is the first time in your Activity's life where you can do Activity- or Context-specific work safely. So, there are restrictions in what you can do in property initializers and init blocks, since these are called before onCreate().
You must never call your Activity's constructor or its lifecycle functions directly yourself. These are reserved for use by the OS.
I'm working on a NW.JS-based application that uses a document scanner. Since the API for that scanner is packed in a OCX component, I had to build a wrapper DLL in C++ and call this wrapper through the node-ffi module.
The scanner API is event-based, so it fires events for almost everything. From hardware initialization to image generation when processing documents.
The issue I'm facing is when the scanner notifies my wrapper layer about the images from the document being scanned. The API fires the event twice, one for the front image and another for the rear image. When testing the wrapper DLL using a console application, everything works fine and I can get the two images from the document. If I call the DLL from node-ffi (through my NW.JS application) the behavior is almost the same, except that I get only the front image from the document.
I analyzed the behavior of the two applications using WinDbg and I could notice that everything seems to be the same between the two tests. The only difference is that the event for image generation is being fired only once when testing from the NW.JS application.
It's very strange and I'm running out of ideas about what to investigate. Does anyone here have faced this kind of issue?
Any ideas and hints are welcome.
Thanks!
After having a hard time hitting my head on the table I discovered that the problem was caused by a typo in a configuration file.
After getting out of a mode of procastinating, I've finally gotten to the item on the projects todo-list that says "Run on virtual device to see why it crashes".
My project is a libgdx application that I plan on porting to various platforms, the two most important ones being desktop and android.
During development I've exclusively used the desktop launcher, as it's a lot easier to fire up when just checking minor things.
I did build an .apk at one point just to see if it'd run out of the box, but it didn't. Now that I've tried via the virtual device, this is what the log says:
com.badlogic.gdx.utils.GdxRuntimeException: Couldn't load file: rifleman.png
The same goes for any other assets that my game uses. The files are all placed in projectname/android/assets, as I remember learning way back that this was the way to go.
The virtual device I tried with is the stock Nexus 5, but I tried running the .apk by uploading it to my actual phone with a crash right after start, and I assume the problem is the same and is therefore unrelated to the test-platform.
I am currently not using an assetmanager, as implementing this is scheduled for after getting the basic core mechanics up and running. In the mean time I'm loading them as such: new Pixmap(new FileHandle("rifleman.png"));
Using android-studio 2.2 on Linux Mint 17 Cinnamon.
Please comment if more info is needed.
Use Gdx.files.internal() instead of FileHandle().
From filehandle(string) method info
Creates a new absolute FileHandle for the file name. Use this for
tools on the desktop that don't need any of the backends.
Do not use this constructor in case you write something cross-platform.
I have a really awkward problem. I have build my app for iOS and tested it on all emulators and it works fine. I have installed it on a device (iPhone 6 plus) and that works fine as well. However, when I submit it to the app store, the feedback is that it crashes on launch on all devices. The crash log attached shows this error;
Unhandled Exception:
System.ExecutionEngineException: Attempting to JIT compile method 'GalaSoft.MvvmLight.Messaging.Messenger:get_Default ()' while running with --aot-only. See http://docs.xamarin.com/ios/about/limitations for more information.
The code that causes this error is in ViewWillAppear;
Messenger.Default.Register<LoggedInFailedMessage>(this, LoginFailed);
Messenger.Default.Register<LoggedInMessage>(this, LoggedIn);
The below stack overflow thread seems to indicate it might be caused by using value types, but I am using reference types.
System.ExecutionEngineException: Attempting to JIT compile method only in Debug Mode on device (MonoTouch)
Any ideas would be greatly appreciated! I don't know how I can test for these errors if they work when i debug on emulator and device but fail when apple test it.
Most of those issues where fixed a long time ago. Make sure your options for the AppStore builds (or the one you used to submit) match the one you're testing (e.g. Debug builds).
In particular make sure that the Enable generic value type sharing options is ON on the build you are submitting. This will include some extra code to ensure all value types code path variants are available at runtime.
Note that this setting should already be ON by default. Still it's a good practice to ensure your debugging/release settings are mostly (except debugging stuff) identical. Otherwise you risk testing different code, locally, than what you're submitting to the store.
I've just managed to implement my first daemon using C# and mono (hurrah). It's working all fine except one thing. In windows for a service to log into system's log base, one should use System.Diagnostics.EventLog class. This class comes with a method named WriteEntry to log a string into system logs. The same class exists in mono and compiles just fine but it seems it does nothing. Or perhaps I don't know where to look. Where does the logs generated this way go?
It's not 100% clear from your question - are you expecting the event log code to be working on Linux?
If so, perhaps this answer will help you.