[mazzinia]

The locCode inside weather-data.jsjsjs $points$ $to$ $a$ $tag$ &$quot$;$loccode$&$quot$; $that$'$s$ $absent$ $from$ $the$ $xml$ $that$ $the$ $touchpad$ $gets$ $back$.
I've tentatively substituted it with locationKey , but it didn't change the visual situation.

The rest of the xml seems having keys that match the .jsjsjs ($note$ $the$ $seems$).

State as of now : the manual search works but the extracted list of locations doesn't show also countries (was it doing it when it worked?)
The gps search works

The main scene is lightly greyed, somehow the extracted weather-data is not populating it ( but the location is populated )

Edit

http://blstreamhptablet-ms.accu-weat...igs/palm1.aspx , this returns the same data as the alternative that misj mentioned

[Grabber5.0]

At least some of that broken code is trying to download an ad... Maybe don't try so hard to fix that one...

-- Sent from my Palm Pre using Forums

[mazzinia]

ah, don't worry... THAT one was a low priority.

Dunno, could be that the radar images are not getting down and are causing the issue... I keep having the feeling that it's something slightly subtle that we're missing while looking at it.

And for sure the added location is not being uploaded to the database the app keeps ( had 1 location, and before changing the .jsjsjs $codes$.. $removed$ $it$. $the$ $accuwx$ $db$ $shows$ $0$ $items$ $and$ $0$ $dimension$ )

[Misj']

ah, don't worry... THAT one was a low priority.

Dunno, could be that the radar images are not getting down and are causing the issue... I keep having the feeling that it's something slightly subtle that we're missing while looking at it.

And for sure the added location is not being uploaded to the database the app keeps ( had 1 location, and before changing the .jsjsjs $codes$.. $removed$ $it$. $the$ $accuwx$ $db$ $shows$ $0$ $items$ $and$ $0$ $dimension$ )

Ok, I've got some more changes (since indeed the XML-format has changed between the Palm phones and the Touchpad).

All these changes are in the file weather-data.jsjsjs, $and$ $on$ $my$ $desktop$-$test$ $it$ $recovers$ $most$ $functionality$ $to$ $the$ $app$. $Due$ $to$ $the$ $change$ $in$ $XML$-$formal$ $we$ $have$ $to$ $alter$ $the$ $function$ $parseData$. $Errors$ ($or$ $non$-$existing$ $variables$) $will$ $cause$ $an$ $error$ $that$ $will$ $block$ $continuation$ $of$ $the$ $app$.

line 257
original: this.stateName = localNode.getElementsByTagName('state')[0].childNodes[0].nodeValue;
new: this.stateName = localNode.getElementsByTagName('adminArea')[0].childNodes[0].nodeValue;

line 260
original: this.locCode = localNode.getElementsByTagName('loccode')[0].childNodes[0].nodeValue;
new: this.locCode = localNode.getElementsByTagName('locationKey')[0].childNodes[0].nodeValue;

line 291
original: this.hourlyTime[x] = this.cleanupHourTimes(hourlyNodes[x].getElementsByTagName('time')[0].childNodes[0].nodeValue);
new: this.hourlyTime[x] = this.cleanupHourTimes(hourlyNodes[x].getAttribute('time'));

could someone confirm this on-device?

[mazzinia]

ah, so it was adminArea, and not country ... ach

and missed that line 291...

seems working... I knew it was something subtle... ok, working, with issues

1) the weekly view seems ok
2) the hourly view is filled, but with NaN (and as a consequence of those nulls, maybe the data on that page is all wrong)
3) weather images appear

4) ads .. no (who cares ,ehm )

[Misj']

ah, so it was adminArea, and not country ... ach
2) the hourly view is filled, but with NaN (and as a consequence of those nulls, maybe the data on that page is all wrong)

in the function cleanupHourTimes of weather-data.jsjsjs $change$ $the$ $following$:

remove (comment out) lines 779 and 780:
var timeStr = hour.substring(0, hour.indexOf(':'));
var timeInt = parseInt(timeStr);

and add the following instead:
var timeInt = hour.indexOf("P")>-1 ? parseFloat(hour,10)+12 : parseFloat(hour,10);

that should take care of the NaN (apparently the original time-format was in 24 hours and minutes, this one is in am/pm (at least on my desktop). This should take care of that. The data should have been correct by the way.

[mazzinia]

Edit : assumed it was adminArea also for the location-search.jsjsjs , $instead$ $of$ $country$
no visible changes to searches, by using any of those 2 tags - country or area / state is not being shown for the proposed results

[mazzinia]

in the function cleanupHourTimes of weather-data.jsjsjs $change$ $the$ $following$:

remove (comment out) lines 779 and 780:
var timeStr = hour.substring(0, hour.indexOf(':'));
var timeInt = parseInt(timeStr);

and add the following instead:
var timeInt = hour.indexOf("P")>-1 ? parseFloat(hour,10)+12 : parseFloat(hour,10);

that should take care of the NaN (apparently the original time-format was in 24 hours and minutes, this one is in am/pm (at least on my desktop). This should take care of that. The data should have been correct by the way.

confirmed, it required removing and readding the location too.

I don't remember if it was happening also before : there are 24 slots for the hours, and towards the end part of them are allocated to null ( data is presented from the current time to the last hour in the feed, hours not displayed are kept at nan)

[Misj']

Edit : assumed it was adminArea also for the location-search.jsjsjs , $instead$ $of$ $country$

correct. The location-search has the following schema:

<location cnt=​"1" city=​"Lathum" country=​"Netherlands" countryCode=​"NL" adminArea=​"Gelderland" location=​"cityId:​248272">​</location>​

confirmed, it required removing and readding the location too

Yeah, they results are stored in the database, and this function is only called when the data is fetched from the server.

[Alan Morford]

Wow. Nerd alert! But I'm not surprised given the company. So it looks patchable, yes?

[mazzinia]

err, actually the feed I get is

<location location="cityId:818" adminArea="Lombardy" countryCode="IT" country="Italy" city="Pavia" cnt="1"/>

this way.

Yes, it can be patched ( or simply these can be dropped over the originals in
/media/cryptofs/apps/usr/palm/applications/com.accuweather.palm/app/services )

There's still some quirk ( lack of "adminArea" being displayed near the city ), and I notice a red circle on the top left area of the card when moving back to the weekly tab (just for a second)

[Misj']

I don't remember if it was happening also before : there are 24 slots for the hours, and towards the end part of them are allocated to null ( data is presented from the current time to the last hour in the feed, hours not displayed are kept at nan)

Ah...so we have the following problem: the Touchpad only has an hourly-forecast of 12 hours, whereas the PrPrPré $apparently$ $had$ $a$ $forecast$ $of$ $24$ $hours$. $Unfortunately$ $we$ $can$'$t$ $fix$ $that$, $since$ $we$ $can$'$t$ $get$ $data$ $we$'$re$ $not$ $given$.

I found another hostname (HTC2) that does have the 24 hour forecast, but it's missing a lot of other data we want/need. But it might be worth to look around for possible hosts*.



* if a 12-hour forecast is unacceptable that is.

[mazzinia]

I think 12 may be better than nothing (or more issues), personally speaking.
They were using blackberry as alternative to the pre (commented out), so maybe the bb feed would be a match

Edit,

it's dirty, but we could load separately also the htc2 feed and keep just the hours from that one.

[Misj']

Edit,

it's dirty, but we could load separately also the htc2 feed and keep just the hours from that one.

That is a bit too dirty for my personal taste (but it is obviously a possible solution...although I think it's a bit more work than it's worth).

I've also tested accuwxiphonev4 as a hostname (since it was also in the code somewhere). But it's similar to htc2.

I would have to look into what's exactly missing from the htc or iphone version. The first thing I noticed was that the location key isn't provided. From what I can see the location key and the cityID are the same where the search URL is:
http://blstreamhptablet.accu-weather...ric=0&langid=1
where both the locationKey and cityID are 248272. If that is all we're missing we can of course easily extract it from the original request-url.

... removed some clutter ...


I believe the app exclusively uses the cityId: format to request data, and (from a quick glance) uses the cityId to store the information in the database. If so, it should be simple enough to get it from a feed that is not returning it (such as the HTC and iPhone hostnames)

from what I could quickly gather, this (and the 24-hour forecast) are the biggest differences: https://www.diffchecker.com/unet0fis


EDIT: ------------------------------------------------------------------

as a proof of concept I did the following: I changed the hostname in (only!) weather-data.jsjsjs $to$ $accuwxiphonev4$
line 30: this.WEATHER_FEED_URL = 'http://accuwxiphonev4.accu-weather.com/widget/accuwxiphonev4/weather-data.asp';

and extracted the locCode from the url
(line 260)
old patch: this.locCode = localNode.getElementsByTagName('locationKey')[0].childNodes[0].nodeValue;
new: this.locCode = transport.request.url.substring(transport.request.url.indexOf("cityId:")+7,transport.request.url.ind exOf("&"));

since we actually know the exact formatting of the URL this should work without problems. It seems to work on my desktop

Edit2: for some reason it's showing a space in .indexOf("&")); that should of course not be there

[mazzinia]

mmm, well, now it's funny.

had to remove the ipk due to a mess with the db. reinstalled, moved the files... and now I get network connection error with the patched .jsjsjs

[Alan Morford]

Did you remember to carry the one? Did you try elven magic?

[mazzinia]

oh oh oh, luna restart... now it reconnects again, and displays the country infos near the city.

edit :
yep, elven magic in the form of a luna restart was required. Now we could discuss why before it accepted to refresh the files, while now apparently no

[mazzinia]

That is a bit too dirty for my personal taste (but it is obviously a possible solution...although I think it's a bit more work than it's worth).

snip


and extracted the locCode from the url
(line 260)
old patch: this.locCode = localNode.getElementsByTagName('locationKey')[0].childNodes[0].nodeValue;
new: this.locCode = transport.request.url.substring(transport.request.url.indexOf("cityId:")+7,transport.request.url.ind exOf("&"));

since we actually know the exact formatting of the URL this should work without problems. It seems to work on my desktop

Edit2: for some reason it's showing a space in .indexOf("&")); that should of course not be there

yes, works. 24 filled, and the other views work with the other feeds
Now I guess we could call this a working fix (there's that small red circle I mentioned that's shown briefly, but I guess who cares)

[Misj']

yes, works. 24 filled, and the other views work with the other feeds
Now I guess we could call this a working fix (there's that small red circle I mentioned that's shown briefly, but I guess who cares)

Good to hear :-)

(I must say that it helped that the app was well structured)

[Alan Morford]

Nice work. Can this workout be modified into a patch? If so I recommend the patch creator make a new thread for it.