Startup sequence, best practice.
Select messages from
# through # FAQ

MGMaps -> Developer Forum

#1: Startup sequence, best practice. Author: kolaf PostPosted: Mon Aug 28, 2006 1:48 pm
yet another question if you have the time. Could you please give a quick and dirty version of your thinking behind the startup sequence with the services and such?

What I am wondering is what should happen when a service is selected from the menu such as "GPS-where am I", and what should happen when "start" is selected. And how does this work together with autostart (which I think you have).

My reason for wondering is that the startup sequence for the different services seem a bit different. So what I have done now is that the tracking service starts as soon as it is initialised on start up of the application and starts the appropriate tracking method based on the configuration. Triggering tracking in the service menu executes the appropriate runService method which currently does nothing. Now, if I delay starting the Tracker thread until runService is called, will the starting of this be remembered by the application so that it is started automatically the next time round, or do I have to store this information somewhere myself?

The ideal would be to be able to start and stop the tracking and mapping, and all other services individually during the applications lifetime, and that this should be remembered when the application is restarted. I think this might be supported by your application, but I'm not quite sure how.

Also, is the GPS started automatically by default without having to select the GPS entry in the services menu?

I realise that this question is a bit confusing, but it reflects my current understanding of that part of the system Smile

#2:  Author: Cristian Streng PostPosted: Mon Aug 28, 2006 4:09 pm

The method called when the application is initialized is startApp (MGMapsRunner) that initializes the forms (including the canvas) and displays the welcome screen.

The services are created in initServices(), called from startApp() - that means that the services are initialized as soon as the application starts, not when the user selects "Start" in the welcome screen. The whole logic behind the welcome screen is that it should be displayed even if some features (like JPG images, or network connectivity) are not available on the phone, so that the user may configure them before viewing the map. In that respect, indeed it would make sense to only initialize the services later.

The method called when "Start" is selected in the welcome screen is canvas.startMapping(). Auto-start simply calls this method from MGMapsRunner.startApp() -> cmdStart().

When a service is selected in the menu, the appropriate runService() method of the service is called. That can display a form, or maybe do anything else. I understand what you mean about starting/stopping mapping and tracking, but I think that would be too difficult to implement while keeping the design safe, so we'll probably delay it till the next major redesigned version of MGMaps (v1.5, maybe 2.0).

The GPS service is always started automatically if at least one of bluetooth/infrared/navizon is supported (since navizon cannot be detected, that means always). I realize that could/should be delayed - see the todo tag in (//HIGH, //PRIO and //FIX are viewed as high-priority todos in eclipse, //TODO is normal priority, //LOW is low priority)

Hope this helps a bit. Maybe you should just add a relatively basic version of tracking to the current MGMaps, and we'll see if we can release the tracking-enabled version as it is. In a future major version things will be redesigned so I'll see how things can be integrated better. I'm pretty busy with other stuff and I'm only able to work on the app in my free time, which is very little.


#3:  Author: kolaf PostPosted: Mon Aug 28, 2006 5:35 pm
In that case I believe a version with tracking is just around the corner. We now support sending positions at specific intervals, or using smartBeacon with fully configurable parameters. Currently, APRS is the only tracking mode supported, but I have tried to make a modular design to easily expand the number of possibilities. There is a system in place for receiving reports from other stations and displaying them on the map with appropriate information when selected. All the parameters for the features have configuration screens, and settings are saved and loaded correctly.

What remains to do is to create a tracker information screen indicating the status of the connection, time since last position report, the number of received stations, and so forth. This is however not necessary for a working application, only for an improved user experience. Also, more information about received stations may be added, such as direction and distance, and anything else that might seem interesting Smile

There also remains a small amount of debugging, I sometimes get a null pointer exception when using the map display. Assuming you have debugged the map display before I guess the fault is in the displaying of received stations. I hope I will be able to sort this out soon.

I have full understanding of your lack of time, I myself have a full-time job, but luckily I have somewhat flexible work hours (I spend several days a week working at home on my Phd thesis:) ). I have probably spent more time on MGMAPS the past few days than I should, but it has been fun implementing it on a platform with a more stable GPS connection than I was able to achieve myself, and with mapping Smile I assume things will normalise as the thrill of a new thing wears off.

#4: nullpointer exception solved Author: kolaf PostPosted: Tue Aug 29, 2006 7:10 am
I was finally able to get a stack trace of the exception, it seems that the emulator does not provide stack traces without attaching a debugger. The problem was caused by pressing the fire key to zoom or view nearby stations on the map after a station has been added to the received list, but before it has been displayed on the map. marker.cachePos will then be null since it has not gone through the paint method.

There are no more serious faukts, I think Wink

        at com.mgmaps.components.GPoint.pixelDistance(
        at com.mgmaps.components.Markers.findMarkers(
        at com.mgmaps.ui.MGMapsRunner.cmdMarkers(+45)
        at com.mgmaps.ui.MapCanvas.keyPressed(
        at javax.microedition.lcdui.Canvas.callKeyPressed(+19)
        at javax.microedition.lcdui.Display$DisplayAccessor.keyEvent(+202)
        at javax.microedition.lcdui.Display$DisplayManagerImpl.keyEvent(+11)

#5:  Author: Cristian Streng PostPosted: Tue Aug 29, 2006 10:34 am
I see... so you fixed the problem?

#6:  Author: kolaf PostPosted: Tue Aug 29, 2006 10:38 am
Of course Smile

I'm almost done with a simple tracker information screen as well, so I guess the only thing that remains for a simple (APRS) tracking feature to be included into the main application is some serious field testing.

#7:  Author: Cristian Streng PostPosted: Tue Aug 29, 2006 10:42 am
Great, after you do that let me know and I'll check the application to see how it works.


MGMaps -> Developer Forum

output generated using printer-friendly topic mod. All times are GMT

Page 1 of 1

Powered by phpBB © 2001, 2005 phpBB Group