I am stuck somewhere, I am building an application, where I want to total numbers of calls (stats) only, No Call Duration, No Number, No contact Name... Just total numbers of call, is there any way which doesn't breach apple development policy.
because accessing call history data is not allowed, is there any event which can tell us the call count, or any services which shows specific status at the time of call so we can get the status of active call and number of calls by adding them in sum.
Please have a look of my query and give me best possible answers on basis of the same.
Regards,
Andy
Unfortunately no. There is no API for that.
The information you seek is located in the Call History Database (call_history.db)see this wiki. This file is very useful in forensics but cannot be accessed on a non-jailbraked iphone using legit means. More information here and here.
It is however, under certain conditions, possible to detect the start of a call: see Detecting the call events in ios on SO. You can also check the Core Telephony Framework Reference. This will give you ways to access some call informations, such the unique identifier for the call. That may be enough for you to count calls.
Related
I am working with React Native/Redux and an express/postgresql backend.
I have an api call to create a comment that returns the created comment as well as some of the information concerning the user.
Those are two different api calls.
Now I also need the updated comment count to send to the feed reducer so that the count is still correct when they close the comment tab.
I was wondering if it is still okay to have 3 queries in one API call and maybe more general/meta, if there might be a better solution to this if that isn't the case.
Kind regards
It's perfectly fine to do multiple queries in a single API call. You can do as many as are required to complete a single coherent interaction between the server and client.
I'm trying to add ~20 tracking category options programmatically and I've seen that calls to add the first two values returns in < 1 second, but after that calls timeout.
If I restart with a new session, I see the same behavior (first two calls are quick and then calls timeout).
My question is, is there rate limiting on the Xero API? Has anyone seen behavior similar to this? Workarounds or fixes?
UPDATE: I forgot to add that i did look at rate limits posted by Xero, I'm not anywhere close to any of those limits
I think xero API give you the option to save a bunch of tracking categories within one request
I need to fetch transactions of our users accounts (investment accounts, if it matters).
Now, my favorite method is "Approach 2", as mentioned in this official guide, as it requires using only one API method and generally, seems simpler to implement. But, I have a few questions on this approach:
Can I use this approach? I'm asking since the API method page doesn't remind it but rather mentions only 'approach 1'.
The numbering of transactions - when I request transactions shall I start from transaction number 0 or 1 ? The couple of pages linked above each uses different version :-)
Lastly - the page that details the approaches talks about setFirstCall parameter, yet the method API page doesn't mention it. I just wanted to verify that I need not care of this parameter.
Thanks!
1) Can I use this approach? I'm asking since the API method page
doesn't remind it but rather mentions only 'approach 1'.
Yes you can use approach 2 from this guide
2) The numbering of transactions - when I request transactions shall I
start from transaction number 0 or 1 ? The couple of pages linked
above each uses different version :-)
Please start from 1. We have updated the guide accordingly.
3) Lastly - the page that details the approaches talks about
setFirstCall parameter, yet the method API page doesn't mention it. I
just wanted to verify that I need not care of this parameter.
This parameter has to be passed to use approach 2.
it should be passed as transactionSearchRequest.firstCall = false
Using the Souncloud API, I'd like to retrieve the reposted tracks from my activities. The /me/activities endpoint seems suited for this and I tried the different types provided.
However, I didn't find out how to get that data. Does anyone know?
Replace User Id, limit and offset with what you need:
https://api-v2.soundcloud.com/profile/soundcloud:users:41691970?limit=50&offset=0
You could try the following approach:
Get the users that shared a track via /tracks/{id}/shared-to/users endpoint.
Fetch the tracks postet by this user via /tracks endpoint, as the _user_id_ is contained.
Compare the tracks metadata with the one you originally posted.
I am not into the Soundcloud API, but taking a close look at it seems to make this approach at least as technical possible, though e.g. fetching all tracks won't be a production solution, of course. It's more a hint. Perhaps reposting means something totally different in this context.
And the specified entpoint exists in the general api doc, so I don't know if you would have to extend the java-api-wrapper for using it.
I'm building my first REST API (at least trying) for a personal project.
In this project there are resources called players which hold can be in a team. According to REST API design rulebook a resource should be made either to be a document or a store and one should keeps these roles as segregated as possible.
Yet I would like to append some metadata to the team resource, eg the date the team was founded. Is it okay then for GET /teams/atlanta to return this metadata (making it a document) alongside the list of players in the team (making it a store).
Is this a good idea? If so why? If not why not and how to solve this better?
I know there are no rules to developing a REST API, but there are good practices and I would like to adhere to those. Please also not that this is really my first REST API so pardon my ignorance if there is any.
I would recommend having GET /teams/atlanta return just the information about the team, such as the founding date that you mention, and then having GET /teams/atlanta/players return the list of players for that team. These distinctions become more important when you are presenting an API that uses HTTP methods other than GET.
For example, if you wanted to add a player to a team - this would be a lot easier if you could just POST a player object to /teams/atlanta/players than if you had to PUT the whole team object to /teams/atlanta every time you wanted to add one individual player.
If your API only allows retrieval of data, and if it is for a specific client application, there is an argument for combining all the team data into one object to save the client having to make additional requests for the data, but bear in mind that it is less flexible.
Your application may want to display a list of teams by calling GET /teams but you probably wouldn't want all of the player information included in each object in the list as this is quite a lot of data, but if GET /teams/atlanta returns player information then it would be inconsistent not to include it in the list version too.
I would personally favour splitting up the resources as I've suggested, and live with the fact the client may need to make an extra request or two.