A throwaway phrase here1 makes me think that my telephone should be able to use the downloaded maps to do a location lookup, even when offline.
But I don't seem to be able to get it to work when there's no internet connection. I get a result with State = Success, but the list of locations is empty.
I've wondered whether it might be the phone trying to check the AuthenticationToken, rather than the actual geo lookup...
Any thoughts?
1"However, mapping services also work without Internet connectivity when maps are downloaded for offline use."
Related
My calls to the API to get users work just fine, but the default URL does not return the home phone number, or the ip phone number.
/Users/jo.bloggs#example.com
adding parameters works for other things
/Users/jo.bloggs#example.com/?$select=id,displayName,mail,postalCode,businessPhones
works too, I have tried homephone, homephones, homePhone, homePhones and ipphone, ipphones, ipPhone, ipPhones but do not get those properties returned. We can see the properties filled in on our local Active Directory, so they are in there.
Looking at the docs I don't see mention of home or ip phones https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0 but I am hoping I am missing something.
To extend on my comment
For some reason the fieldname ipPhone does not work, only a prefixed
version with a 33 character hash in it extension_<33chars>_ipPhone. I
don't have direct access to the system, but have been told its been
done correctly, so it works enough for us
The URL path we have is now:
/Users/user.name#example.com/?$select=id,displayName,mail,homePhone,mobilePhone,businessPhones,ipPhone,profile,streetAddress,postalCode,extension_e48de7ec5b11c947e3006271ff83029_ipPhone,extension_e48de7ec5b11c947e3006271ff83029_homePhone
The codes for both of our fields fields are the same.
I presume the codes for other orgs will be different, but just in case I have not used our actual ones here.
Some attributes (such as ipPhone) that are synchronized by default might not be exposed using the Microsoft Graph API. In these cases, you can use the Azure AD Connect directory extension feature to synchronize the attribute to Azure AD.
I am wondering about what the best way to keep users in sync with each other in a social network is. The concerned stack is an iOS app with a NodeJS backend. Let me give you an example:
Say X and Y are friends on a social network. Y's posts appear in X's feed, and as such, Y is cached somewhere on the X's phone. This morning, Y decided to change profile pictures however. Everything is well, the new picture is uploaded to the server, but how do we go about letting X know about the change of profile picture?
My possible solution: Create a route /<UID>/updates that contains a stack of "cookies" which lets the user know what and who changed since the last time they made a GET request to the route.
This seems elegant enough, but what worries me is what happens on the client side (am I supposed to make a GET request every 2 minutes during my app's uptime?). Are there any other solutions?
One solution is indeed to poll the server, but that's not very elegant. A better way is to make use of websockets:
WebSockets is an advanced technology that makes it possible to open an interactive communication session between the user's browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.
They are a 2-way connection between client and server, allowing the server to notify the client of any changes. This is the underlying technology used in the Meteor framework for example.
Take a look at this blogpost for an example of how to use websockets between an iOS client and a NodeJS backend. They make use of the open source SocketRocket iOS library.
I have a specific issue where I'm using WebRTC (voice and video).
I want to keep a connection/voice/video streams alive between webpages on a website. I thought I could use shared web workers to run in the background?
Any guidance would be great. I've looked at other posts but they're quite old and wondered if anyone had any, more, up-to-date information or ways I could tackle this issue?
UPDATE:
Shared Web Workers are the incorrect way of tackling this problem. Service Workers are the way forward for maintaining after the web page is terminated.
Keeping the webRTC connection alive between page loads seems like a rare use case. Normally, you start a call and remain on a single page. I guess it could make sense if you wanted to embed a customer support like webRTC widget on a site and have that widget follow a user through page navigations under a single domain.
I don't think saving/reusing the blob URL will allow you to reconnect on a page reload for security issues/hijacking potential.
There is the IceRestart constraint which might help. Apparently you can save the SDP info to local storage, reuse the negotiated SDP, then call an IceRestart to quickly reconnect.
As described in section 3, the nominated ICE candidate pair is
exchanged during an SDP offer/answer procedure, which is maintained
by the JavaScript. The JavaScript can save the SDP information on
the application server or in browser local storage. When a page
reload has happened, a new JavaScript will be reloaded, which will
create a new PeerConnection and retrieve the saved SDP information
including the previous nominated candidate pair. Then the JavaScript
can request the previous resource by sending a setLocalDescription(),
which includes the saved SDP information. Instead of restart an ICE
procedure without additional action hints, the new JavaScript SHALL
send an updateIce() which indicates that it has happended because of
a page reload. If the ICE agent then can allocate the previous
resource for the new JavaScript, it will use the previous nominated
candidate pair for the first connectivity check, and if it succeeds
the ICE agent will keep it marked as selected. The ICE agent can now
send media using this candidate pair, even if it is running in
Regular Nomination mode.
https://bugs.chromium.org/p/webrtc/issues/detail?id=979
https://datatracker.ietf.org/doc/html/draft-li-rtcweb-ice-page-reload-02
I’m developing a iOS App and I want to have a level of offline support and I’m struggling out of local datastore or cache which approach to use as It appears that you can’t use these two feature together.
My query is quite basic and doesn’t change only the data that is retrieved can change.
if i used one of the cache policies, i get connection errors and nothing appears to be returned from the cache.
The workflow i’m after is on the lines of below.
->When connected to the internet perform query and store objects locally.
->if there is no internet retrieve previously downloaded objects.
For the workflow you describe I think you're looking for a cache. If you would like the user could modify the data without connection and then, when there is wifi again, synchronise the local data with the remote data then you'll need the local datastore behavior.
The problem for me is when you want both in different parts of the same app because in parse in you use local datastore you can't use the cache. I don't really understand why!
When I make API calls to the server, I'm getting 404 errors for various data -- grades, role IDs, terms -- that I won't get on the next time I call it. The data's there on the server, viewable by the same user, and is often returned successfully, but not every time. The same user context will return data successfully for other calls.
Any ideas what could be causing this?
I'm using the Valence API with the Python client library and our 9.4.1 SP18 instance of Desire2Learn in a non-interactive script.
more detail: the text it returns on the bad 404s is " ErrorThe system cannot find the path specified."
It would help enormously to gather data about your case: packet traces that can show successful calls from your client alongside unsuccessful calls, in particular, would be very useful to see. If you are quite certain (and I see no reason you shouldn't be from your description) that you're forming the calls in the right way each time you make them, then the kind of behaviour you're noticing would seem to speak to some wider network or configuration issue: sometimes your calls are properly getting through the web service layer, and sometimes they are not -- this would seem therefore not to be down to the way you're using the API but in the way the service is able to receive that request.
I would encourage you, especially if you can gather data to provide showing this behaviour, to open a support incident with Desire2Learn's help desk in conjunction with your Approved Support Contact, or your Partner Manager (depending on whether you're a D2L client or a D2L partner).