Warning: Weather is still not usable at this point.
It compiles and you can open it but it will not work as it still tries to use the discontinued Yahoo API,I still have to fix that one.
When trying to login,I saw that Microsoft has removed the option to do Git operations with a password on August 13
Also I don’t remember my password so I got blocked for some minutes on the website.
Haven’t really used this proprietary piece of crap for months,except for browsing public pages.
That’s why I sent it as a patch file.
Feel free to upload it using your account if you want to
No need to create drama here
You can reset your github password at the login page.
Setting up an ssh key for use with github takes only a few minutes. Here’s the help page with the explanation how to do it: Connecting to GitHub with SSH - GitHub Docs
Feel free to ask me for help if you have trouble setting it up.
I’m done with proprietary Microsoft stuff,sorry.
I’ve been using NotABug.org for my own projects since they’ve bought Github.
I don’t want to create drama,I only describe why upstreaming is currently not an option for me.
Since Git itself provides this easy way of sharing patches via a patch file,why not just use it?
If someone with write access likes my work,they can apply my patch and merge it and otherwise it’s here for everyone who’s interested in it.
No problem with that, as long as you find somebody who is willing to take your patches and submit them to the github repo. For me personally I find it easier to be able to submit my changes directly.
Going back to the original topic,I’m currently looking into implementing the yr.no API into the application.
Unfortunately search by city is only possible using the yr.no website which uses quite obscure URLs.
They provide their official API for third-party apps only with GPS coordinates (latitude,longitude).
I may be able to use their unofficial website API but that isn’t officially allowed and may get the app banned,also they can change their API whenever they want and break the app.
Instead I thought of using another provider for the Geocoder API that returns the coordinates to be used with the official yr.no API.
I think the Nominatim service by OpenStreetMap is a good choice as it’s safe to stay open and free forever.
It can be used without a API key and their limit is as simple as one request per second - I think we won’t exceed that as coordinates need to be retrieved only one.
Edit: Forgot the link: https://nominatim.openstreetmap.org
What was wrong with the Metaweather API that the existing pull request to the Weather app partially implements? I think it already has searching by location.
It wasn’t finished and still uses old Haiku private libraries (so it was broken as well).
There was no one working at it for 1.5 years so I don’t think it will ever get finished.
As @frankps asked for supporting yr.no and the API looked good to me,I decided to give the good old Weather app a new chance using this one.
I patched it with that PR but it still doesn’t work, a JSON parsing error of some sort prevents it from loading the data, unfortunately i was unable to find where that error comes from.
I’m experiencing the same problem with the OpenStreetMap Nominatim API.
Maybe it has something to do with the changes to the Haiku private librarys,too.
I also tried setting the URL to 192.168.2.110/weather-test.php (a webserver in my Intranet with a logger installed) and came to the result that the request is successfully sent.
Then I added a simple JSON content to the file: {“hello”:“world”}
Still the Weather app shows a JSON parsing error and the logged response of the HTTP request seems to be empty.
First I thought OSM may block the Weather app but at least my own local server surely doesn’t.
That leads me to thinking the HTTP response isn’t processed correctly in the Weather app anymore but I have to do some more experiments to find the exact cause and a solution.
It’s really complicated to find the cause of the problem.
The response data variable stays empty.
The DataReceived() callback of BUrlRequest should write to it.
In fact,DataReceived() is never ever called,I checked that with a printf that should spam the Terminal whenever the function is called.
I suspect that this could be a side-effect of implementing the new buffer feature in the new Haiku private librarys that catches the full response and stores it in a variable.
A solution could be using the buffer response instead of writing a own variable using DataReceived().
However,the point where the request is sent and where the callback functions are called are in two different files and my C++ skills aren’t good enough to hand the variable over to the other file,unfortunately.
Also I’m not really sure that it’s the library change that causes the problem - Maybe the buffer is empty as well,I’m too stupid to check that currently.
I’m not making great progress actually,but at least I’m learning something about Haiku internals and I’m starting to understand a little bit of C++ what might help with future projects.
@nipos Did you forget to include the fix for the following error in your patch?
Source/NetListener.cpp: In constructor 'NetListener::NetListener(BHandler*, BMallocIO, RequestType)':
Source/NetListener.cpp:16:26: error: 'BMallocIO::BMallocIO(const BMallocIO&)' is private within this context
fRequestType(requestType)
^
In file included from /boot/system/develop/headers/os/app/Message.h:15,
from /system/develop/headers/private/shared/Json.h:12,
from Source/NetListener.cpp:5:
/boot/system/develop/headers/os/support/DataIO.h:149:9: note: declared private here
BMallocIO(const BMallocIO&);
No that’s exactly the error I wasn’t able to fix.
In the code the BMallocIO responseData variable is handled nearly the same RequestType requestType and still for responseData it throws that error while it doesn’t for requestType.
also RequestType are a enum.
enum RequestType {
CITY_REQUEST,
WEATHER_REQUEST
} ;
Now I’m not that good at c++ (c# is my language). But I think you need to use BMallocIO* (pointer) or make a subclass of BMallocIO and make the new class “copy constructor” (I think i’ts called that) public
You can look at BHandler and treat BMallocIO the same way.
It’s working now!
You’re right,BMallocIO* was the correct thing to do.
In my first attempt to do so,it threw even more errors because of :: instead of → but after fixing them,it does work now.
I made a new patch here: http://transfer.sh/6IeT2N/make-response-available.patch Warning: This still does not properly implement the new API so do not expect the app to work.
Keep an eye at the terminal while searching for some city and you’ll notice that the response JSON will now appear.
@nipos it compiles but crashes at startup, any idea why?, the crash seems to be triggered by BMallocIO
could you put your local copy somewhere? GitHub maybe? so i can compare my copy with yours?
Thanks.
Here is my local copy: https://transfer.sh/bOxfU3/Weather.tar.gz
It also includes the compiled version (for x86_64) so you can try if that makes a difference.
Are you using Haiku Beta 3 with all available updates installed and x86_64 version,too?
If yes,it should theoretically work as there are no other dependencies for this app afaik.
I believe the crash during manual refresh is fixed now, along with some other naughty things I was doing in the code
I started looking at a compact mode for the forecast window but I have no idea when it’ll get implemented. The Haiku layout manager wasn’t cooperating with me
