Good afternoon. I am using Agora - UE4 Bluprint version.
I can not find a way to access the frame of the new connected user. This is provided that more than two people are connected. The first connected each tick causes "OnLocalFrameReceivedDelegate"
all subsequent connected call "OnRemoteFrameReceivedDelegate". In total, it turns out that you can broadcast the image from the camera of the first connected or the second. And how to take the camera of all subsequent connected?
In our blueprint example, we have two images that receive Agora video frames:
CameraFrame - the Local user
InterlocutorFrame - the Remote user
If you call into the blueprint example with 3 or more people, you will see that you can switch between UIDs in the dropdown menu.
Switching UIDs changes the InterlocutorFrame video feed to the remote user whose UID matches the one you specify, like so:
To display multiple users, you need to place multiple UI Images on the screen, and SetBrushFromTexture with the appropriate UID.
I would suggest using the OnUserJoined callback to create a new image actor, and store the new incoming UID inside that actor. You could also store all the current UIDs in one place, or use another solution that you think is best :)
Related
I have an app and its going to have these features in it :
SCREENS :
Home { Show recent posts from all categories (API provides 30 posts per page)}
Categories {Show all Categories List }
By-Category {Show recent posts by category (API provides 30 posts per page)}
Post {Show Post Details with Comments }
User-Profile {Show User Profile with their recent posts (API provides 30 posts per page)}
Profile-Setting {Show updatable Fields and Update Button}
Now, Where i am confused :
Should I fill the whole store with API in the starting or should I
make API calls for each screen when they are opened ?
And for updating, like If user likes post then should I show a
spinner or something till API completes OR should I update the local
store value instantly and then call the API ?
There could be many approaches to solve this. mine is:
1) I would create a model/manager to handle the API requests that also have access to the same store. so for example when the screen did mount use Home.Manager.getNextPage(); and it will know already to handle the api request and also know how to handle the paging.
So all the calcs will be in the manager. and when it get the data it will update the store with it.
2) When I built an app that contained likes I have used local data as well. My approach was to set time out of 10 seconds from last like so in case the user liked more than one post I could send a bulk. so the server won't need to handle multiple tcp connection but one with multiple likes data.
The point was first store it locally(for incase the user kill the app before we update the server) and then wait for 10 s' if got new like add it to the data array and wait for another 10 s' if not just send the data to the server. do not clean this local data until server return that it saved on your db
This way you can display animation first without letting the user to wait for a feedback from the server..
The best practice is to make small API calls for each component.
You should load each screen with a loading, then call the API in
componentDidMount after receiving the response shows the data.
enter code here
For this kind of action, first, make the API call, make the like button disable, update the store after successful API call.
Disable the button because of some user double-tap. This kink of APIs is usually fast, so loading does not have a good UX. The loading will be removed before full animation. Always update store data on the response, not the request because you need to revert the store changes if the API calls failed.
If you type IAM <GO> in the terminal you'll be shown the UserID, UUID, CLID etc.
Is it possible to extract this information through blpapi when using the Desktop API to connect via BBComm? I've seen references to Identity and populating that by sending an AuthorizationRequest but it appears that's only relevant for SAPI/B-PIPE.
To the best of my knowledge and after asking a couple of Bloomberg reps - this isn't possible. The best work around which I've found is: each user creates an EQS screen called their UUID. Add some filtering which causes this screening to return nothing. Then the application, upon start up, requests all possible UUIDs as EQS screens and stops when it doesn't get back an error - that's the UUID.
This is a dirty, dirty hack and, granted, this only works if you have few distinct users using your system. You don't want to ask may users to create such a screen and probably don't want to iterate over thousands of EQS screen names.
There is a "SID report" which is provide together with monthly invoices from Bloomberg which contains the UUIDs for users - this can be used to look up existing users but when setting up a brand new account you have to manually copy this information out of the terminal.
I would like to, via OneSignal REST API :
filter the push to users in a certain location (as in the doc) but it lacks sample code/relevant routes. The steps would be :
store tags for users (documented here, this is fine)
creating a segment (I don't see this in the docs)
push by filtering by segment (this is covered here)
Similarly I would like to be able to filter the push to users that visited a location in a certain date range (ex. last week, last month...). I am not completely sure this is possible using only OneSignal.
The minimum I would need is how to create a segment with OneSignal.
Edit : looks like there is a way in the dashboard, but I need to do it programmatically.
(I help work on OneSignal) OneSignal does not support programmatically targeting by a location at this time but we're planning on adding support for this in the near future.
One way to do some of this until then would be to provide the name or position of a location as tags. For instance you could use the tags lat=41.123, lon=55.331, then target users programmatically where the tags are greater than and less than the ranges you specify.
OneSignal does not provide built-in functionality to target by historical locations and we do not plan to add support for this, but you may be able to use tags to achieve your desired result.
Note that OneSignal does allow you to target by Player ID, so you could always store your users' Player IDs in your own system and do the calculation of who should receive a notification on your own.
I'm developing an application, that allows using dictionaries (e.g. English-German). I want to enable periodic tile updates for my application at start screen. I want to show random word with translation from random dictionary, so all I want to do is just show 2 strings (I found an appropriate template for it). I can show the notification once using TileUpdateManager.CreateTileUpdaterForApplication().AddToSchedule()
but I want it to happen say every minute. I only found examples that use TileUpdateManager.CreateTileUpdaterForApplication().StartPeriodicUpdate() method and they all use some web address. Is there any way to make it happen using just my local strings without accessing cloud or something?
For showing periodic tile updates periodically when your app is not running you need to provide a URL that will be requested every once in a while (I don't think you can set it to as frequent as 1 minute though - I think the least is 15 minutes.).
If your app is in the foreground, you can simply run a timer and show an update every minute.
You could use push notifications, but again - that's more complex than just providing a URL that returns the XML for a tile update.
In case you want to look at the possibilities: http://blog.equinoxe-consulting.net/blog/bard-rsquo-s-tile-i-introduction-and-local-tiles-and-badges
How unique is MPMediaItemPropertyPersistentID? Will it even work when synching the list of IDs to another device connected to the same iTunes Account?
I want to implement a iCloud synchronized playlist solution which stores the IDs as a list and I need to know if this will be possible.
As per the documentation (emphasis mine)...
The value of the MPMediaItemPropertyPersistentID identifier persists
across application launches and across syncs that do not change the
sync status of the media item. The value is not guaranteed to
persist across a sync/unsync/sync cycle.
As such, given that it won't even persist on this basis I'd be surprised if it persisted across devices in a sufficiently robust manner, if at all.
In my understanding this is not possible. I think this ID is persistent only for each device. It is no unique identifier for a specific song in the iTunes Store. It is only a ID for your own synced songs.
As you read the documentation, you'll see how fragile this ID could be.
"The value is not guaranteed to persist across a sync/unsync/sync cycle."
So if you sync your song database with iTunes and maybe delete a song from your iOS device and the sync again and put it back to your device, you may not get the same ID again for this song. And for sure not across other devices.
So I think, what you're trying to do will not work, until you get a worldwide identical Identifier for each song of the iTunes catalogue or your own iTunes catalogue on the Mac (where the Mac has to handle the IDs).
The other answers are a little big vague, so here is an answer from my own experiences and tests:
1) You can't use MPMediaItemPropertyPersistentID to get an ID that is equal between devices.
2) The MPMediaItemPropertyPersistentID will change when the device is synced with another iTunes library or all music is removed from the device and then synced again.
The ID get's created and stored by iTunes when the song is synced on the device. If it's unsynced, the ID get's deleted.
In case somebody else lands here, like me, using a Google search:
I confirmed what middaparka said above after an iOS upgrade of my device, when my music app tried to use persistentIDs from before the upgrade. The IDs had changed, and I ended up (unwittingly) listening to many songs from my library that I don't normally listen to...
So I took middaparka's advice and constructed a persistentKey by exclusive-oring the hashes from title, artistName, albumTitle and duration. Building the persistentKey during Core Database initialization will be save time later, by avoiding multiple string comparisons when fetching items in "normal operating code."
The persistentKey strategy worked properly for songs. However, when I made a hash for albums from title, artist and releaseYear, I ended up with one collision.
I had two self-titled albums by different artists released in 1976. When the hashes for the album title and the artist were exclusive-ored, they cancelled each other out. I ended up using the hash for the duration instead of the artist, and that worked.
I may end up refining the algorithm for generating the persistentKeys later...