Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.
Talk:Getting the news using The Guardian's API on Windows Phone
Croozeus - Nice app
This looks like a useful application...
May be you could trim down the code snippets to whatever you want to highlight with this article. For example, if you want to illustrate how to use the Guardian API, focus on it.. May be show a sample JSON response that you get from the API... and as you've already done show functions to parse the response... It's not necessary to focus on the UI in this case, however you can still show screenshots and your attached code snippet can contain all code.
The upshot is that for big projects like this, all code (XAML and cs) need not be highlighted in the article... just focus the part that you wish the article to cover. If there are multiple key aspects you want to cover, the right approach may be to have 2 or 3 small articles.
PankajPS: Are you going to publish this application to the marketplace? Are you going to maintain it for future updates? If yes, may be you should also have it on projects.developer.nokia.com.. you may find good collaborators.
09:10, 13 May 2013 (EEST)
Vaishali Rawat - Thanks for Feedback
Thanks very much for your encouraging words.
I will try to reduce the code available in the article by omitting the least useful one.
Yes, I am looking forward to make an app on it. About uploading it on Forum Nokia Projects... I am not pretty sure.
14:34, 15 May 2013 (EEST)
Hamishwillee - Agree with Pankaj
The choice of article is good, and the code looks great. I would certainly consider making it a ND Project so you can extend it easily and get more people on board - that is of course up to you.
The main point that Pankaj is making is that as written this isn't very useful because it is impossible to tell what is important and relevant. A developer can look at the code because you've provided the zip. Having so much code here is just unreadable.
I strongly urge you to take his suggestion. Cover things like what APIs you use to access the service - were they native or third party? Were there any tricks to the JSON parsing. Can the API supply XML as well? Were there any tricks/tips you discovered while writing this - for example did data come in an unexpected format you had to convert. Perhaps something on caching the results (should you wish to) for faster loading. All the stuff that others can learn from if they want to use this API or a similar one.
So your article is about using the service and what it offers - that is something others can learn from, while your app is code that people can inspect for the detail.
I would imagine your article would shrink to about 1/4 the size.
Hope that makes sense.
04:38, 16 May 2013 (EEST)
Vaishali Rawat - I Agree
Thank you for appreciating the article.
I agree that the code in this article is too much. While uploading it, i was having this feeling but didn't omit anything as I didn't wanted to miss any detail. Anyway, I will definitely reduce the code written here. Will also mention the minor details you suggested.
Just give me some time.
15:29, 16 May 2013 (EEST)
Hamishwillee - Of course!
Take your time. Sorry to dump so many reviews on you all at onceAnd of course thank you again, these are still OK articles, just not as great as you are capable of.
08:42, 17 May 2013 (EEST)
Vaishali Rawat - Code reduced
Hey Hamish | Pankaj,
I have reduced the code written in the article. Tried to include important information only. You may have a look at it now.
21:26, 21 May 2013 (EEST)
Hamishwillee - Looks a lot more clear to me
Thank you. There is a lot less code now, which is good. Now you've removed the code you perhaps need to say a bit more about what you have left.
So you have lots of text "This file has following declaration." - why is this code interesting? This isn't the whole file which is good, but its not obvious what it shows and why. I think part of the problem is that this is still "file centric".
Frankly as a reader I'm interested in "Hows" and "Why" - the file that information in is important, but its not the heading. So without delving too deeply I look at this and I see that your code does interesting things like get and send responses, as part of that it creates classes that have setters and getters for the main objects you're working with. These classes then interact with the service. All that stuff is what is interesting and will help people understand what they need to do.
So my headings would be something like (and remembering I haven't read this in enough detail to know how it works!):
- "Architectural Overview" saying stuff like "We query the service passing in an XYZ. We get back an ABC in ??? format which we then put in object blah blah. The UI then dynamically blah blah blab". each section below demonstrates these main parts ....
- "Creating the response objects". We need a response object to hold the results of X, and Y. These are standard getter and setter objects which we'll need to reference from XAML (note the name of the object). Then have your getter and setter code, listing the file origin of each fragment just as bold text.
Looking at your code HomePage.cs section is closest to what I want, though you'd again have a title which explains what you're doing, not where you're doing it.
Hope that makes sense. It is more understandable now, just not as good as it could be.
04:58, 22 May 2013 (EEST)
Pooja 1650 - Just got in!
Hi Vaishali | Hamish,
Sorry to step in all of a sudden. But just made a couple of changes like divided the code behind section into two parts: Sample JSON parsing and App Logic Handling. So anybody interested to know JSON parsing can check the first section, else can skip.
Please let me know if it's fine.
15:24, 22 May 2013 (EEST)
Vaishali Rawat - Further Edited
The article is further edited. Removed the references of individual pages, rather referred directly to search types like tags search, content search etc.
Hope it's better now.
20:49, 22 May 2013 (EEST)
Vaishali Rawat - @Pooja
Thanks for the changes. I think they are fine.
20:51, 22 May 2013 (EEST)
Vaishali Rawat - @Hamish
Forgot to mention in last comment that I have kept an example of showcasing JSON parsing. If you think it's not useful then I can omit it. I thought, if not for all search types, I can show way to parse data atleast for one kind of search response.
21:05, 22 May 2013 (EEST)
Hamishwillee - Much better
Thanks for this. I think this is much better.
The section on parsing the response was still "file centric" so I have re-written it. Please check it out above. As you can see by removing the filenames as headings I'm now in a position where I describe what the code is doing/for, not what is in each file. As a rule it is rarely a good idea to have filenames as heading.
Now that I've done that its a bit obvious that this section is "dangling" ie it starts from "The root node of a response is a single tag named response " but it is not clear where this tag is used and how it gets populated and how this then gets into the UI. I see further down you have "strResponse" - is this an object of type response?
It might be that we want to shift this around so that we JUST cover end-to-end "content search". So you'd have UI, then the section on making the request using content search, then this section I've just made on getting the data into the data object, (and explain how that gets back into the UI breifly). The sections on tag search etc might be kept for the end as an "aside".
Does what I've done and I'm proposing make sense? The whole idea is that someone can understand end to end what needs to be done to create this type of service as well as this service.
05:29, 23 May 2013 (EEST)
Vaishali Rawat - Thanks for editings
Your changes in JSON Response looks pretty good. Now it's more understandable.
>The root node of a response is a single tag named response " but it is not clear where this tag is used and how it gets populated and how this then gets into the UI. The tag with the name response is the part of the response we get by making content search API hit. I had tried to explain it in that section now.
> I see further down you have "strResponse" - is this an object of type response? It's a String type object, already declared above. Guess you missed it!
> how the response then gets into the UI. I had previously showed the code by which I was mapping my response with the UI, but removed it later on as less code was required. I thought readers can check it in attached zip.
>Does what I've done and I'm proposing make sense? The whole idea is that someone can understand end to end what needs to be done to create this type of service as well as this service I liked the idea a lot and it does makes sense too. Now by checking only the metadata section, one can directly jump to either of the search type (e.g). Writing the whole code into article was a mistake, will definitely take care of it in future.
I like the current structure, content and the length of the article.
Thanks very much for all the hard work.
21:00, 23 May 2013 (EEST)
Hamishwillee - OK, your call.
Yes, overall its a much better document than originally. Thanks!
04:38, 24 May 2013 (EEST)
Vaishali Rawat - Missed something
I am sorry but I completely didn't understood your thoughts last time. So, you want the article to cover content search (start to end) completely? Tags search and Sections Search can be explained briefly?
Sounds good. We can definitely do this. Let me know If you want to see the article in such a way, I will edit.
15:24, 24 May 2013 (EEST)
Hamishwillee - What I want you to do
What I "want you to do" has to be balance with whether YOU think the suggestion is a good one/worth the additional effort.
I think it is good to have an article which explained from end to end how to do the content search, and just the highlights of the other two would be a good way of presenting this. So you'd start with this is how I make the request, this is the object I get back, this is how I get it into the UI, these are the minor differences for tag and sections search.
At the moment all the information is there, but there isn't much logical flow - for example the UI is before the code to represent the returned request, which is before the code which makes the request.
Anyway, you decide if you think this might be better!
10:20, 27 May 2013 (EEST)