Talk:Mapping points of interest using Java ME
Hamishwillee - Code looks nice, article a bit rough around the edges
The best improvement you can make to this one is in the introduction/quick walkthrough - this basically says that the app is about mapping Points of interest, but the app does a whole lot more - displaying news and weather. I would mention these and how it does it (ie using RSS feeds or whatever) and also provide the screenshots up the top as part of the introduction - "a picture tells a thousand words". Upshot is that the introduction sets the scene for the rest of the document, so its worth saying what you're going to cover, and what developers can learn.
In terms of "wiki tidy up" I would use the Icode template for marking up code fragments inline rather than italic, and I'd go through all the code fragments and improve the indentation. Usually I use two or four spaces as a level of indentation.
In terms of the individual sections, I think you could say a lot more than just code dumping. I would use less headings, and certainly more meaningful headings. I would provide brief overviews of what APIs you've used, with links.
So for example, "Quick intro to Location API" has headings "Creating object of location" and "Current location through Cellular ID", neither of which have much content. YOu could hear provide an overview of the location API and links to references in the JDL or the wiki category page. You could explain that the code provides hints to the provider on the type of location information you want - ie cellular, gps etc and why you've specified all three. You could explain that the system will use the best options possible. You also imply that this section gets points of interest, but actually it only gets your current postion - it doesn't matter if you only plot your own position, but you should make it clear what you provide and what you don't.
Does that make sense?
I could say similar things about all the sections - for parsing the feed what XML do you use, what JSR is it in. Is there any reference material for XML parser people can use. normally I'd just have a brief overview explaining what sort of parser it is and link to the information for more. A REALLY good article would then go on to explain any particular tips and tricks - why you did it a certain way, not just what you did.
I think the code looks fine (although not a java expert).
09:31, 25 July 2012 (EEST)
Jasfox - Why does the code example include its own XML parser?Is there a good reason for including your own XML parser in the example? The complexity of the code could be reduced by importing the standard JSR 172 SAX parser library directly. This would make the code easier to read.
13:50, 27 July 2012 (EEST)
Hamishwillee - Agree with Jasfox hereWhere possible, best to use the native libraries.
07:26, 30 July 2012 (EEST)
Adarsha saraff - @Jasfox and Hamish
I thought most of the developers are familiar with kXML parser. I didn't got this in my mind.I could have done, but time was short and I am more familiar in using kXML parser.
08:32, 30 July 2012 (EEST)
Hamishwillee - Fair enoughSomething to think about if you revise this though - on a resource constrained device it makes sense to use the inbuilt parser - for smaller and faster code.
04:48, 31 July 2012 (EEST)