In my RESTful API I need to have two operations:
Remove player
Remove player and his/her games
Although the first operation is obvious (DELETE request with URL /api/players/playerId), the second operation got me thinking.
Second operation is tricky. You can remove the player and leave the game in the system but also there is an option that the player will delete all games he was in. As weird as it sounds, please believe me. I'm really curious how well designed API should handle such situation.
Is it a good practice to have a DELETE request with an bool option "removeGames". For example:
DELETE /api/players/playerId?removeGames=1
I personally don't like this idea of passing bools to delete other domain objects.
I would do something along these lines:
DELETE to /api/players/playerId
DELETE to /api/players/playerId/games if you want to delete all of them
DELETE to /api/players/playerId/games/gameId for a specific game
Of course you will have to make a decision what happens when you delete the player but keep the games, or you try to delete a game from a player that is already deleted
I'm creating a sync manager for my app and part of that process is to track changes made in the local Realm and queue them for upload to the server. As far as I can tell, collection notifications lack some important details for this case, such as missing the primaryKey of an object that has been deleted. They also send notifications when a property has been changed on a related object, which is not the behavior I want when tracking changes to sync.
The library SyncKit manages change tracking by iterating through every object in the Realm and adding an object notification to a dictionary [String: NotificationToken] where the object id is the dictionary key. This seems reasonable, but I'm wondering if there are any performance limitations to this approach based on the implementation of NotificationToken under the hood.
What happens if 1000 objects are deleted at the same time? Is it reasonable to store 20,000 objects in the Realm, each with their own NotificationToken?
I think you need think of when you data can be changed. For example, you creating an object => trigger SERVER API request. Then, user edited some object => trigger request on object update. User deleted some object -> do the same thing. I didn't used SyncKit, so i don't know exact features it can do. But holding 10k references on notification changes... It doesn't seem to be reasonable
Im wanting to pull play count data for an individual track on SoundCloud. I've seen various examples that pull total plays for all users tracks, but not for individual tracks. I'm very new to coding and will probably not be the one handling the final coding, but was just wondering if anyone already has the answer.
For example, I would like to keep track of the play count for this track:
https://soundcloud.com/llucid/fish-grease-prod-louis-futon
If you guys can help me, I'd truly appreciate it.
Kind regards
The previous question wasn't so straightforward because a users total track playcount for all tracks is not readily available. But playcount for a single track is right there for you to get.
I find myself working with track ids more often than urls to tracks. But if you just have the url, you can still resolve it to a full track resource, which would include the playcount.
I don't know what language you use, but I use php and heres the code to get that tracks playcount. But I'll tell you right now, unless you can make some sense of the api docs (located here) then i think you are in over your head. This code is copy/paste from api docs.
<?php
require_once 'Services/Soundcloud.php';
// create a client object with your app credentials
$client = new Services_Soundcloud('YOUR_CLIENT_ID');
// a permalink to a track
$track_url = 'https://soundcloud.com/llucid/fish-grease-prod-louis-futon';
// resolve track URL into track resource
$track = json_decode($client->get('resolve', array('url' => $track_url)), true);
$track_playcount = $track['playback_count'];
echo $track_playcount;
I want to keep my list GWT side after fetch it from service side.For example i have button A and when i press, it bring me the list of patient names which start with 'A'. So; I don't want to fetch names from service side all the time. I want to take them for once and store in the cilent side. What am I suppose to do about it? Do you have any suggestion? Thanks.
Fetch them all at once at the beginning, and save them on a list and keep a reference of that list across the aplication (where you need it). Then every time you want to see more, just use that list and show the ones you wish to view. But keep in mind that if you have a lot of information on the server side, it might very well be better fetch just a few at the time, otherwise it might take a lot of time to get the bulk list at once.
At beginning fetch all list name and stored them. From this it will not provide u latest or frequented name list. so u can use gwt event service in gwt. I don't know the requirement but u can track like if new patient is added then it will fire the event from server to client and try to add that user also in that list.
Refer link:
http://code.google.com/p/gwteventservice/
I am trying to write a Core Data application for the iPhone that uses an external data source. I'm not really using Core Data to persist my objects but rather for the object life-cycle management. I have a pretty good idea on how to use Core Data for local data, but have run into a few issues with remote data. I'll just use Flickr's API as an example.
The first thing is that if I need say, a list of the recent photos, I need to grab them from an external data source. After I've retrieved the list, it seems like I should iterate and create managed objects for each photo. At this point, I can continue in my code and use the standard Core Data API to set up a fetch request and retrieve a subset of photos about, say, dogs.
But what if I then want to continue and retrieve a list of the user's photos? Since there's a possibility that these two data sets might intersect, do I have to perform a fetch request on the existing data, update what's already there, and then insert the new objects?
--
In the older pattern, I would simply have separate data structures for each of these data sets and access them appropriately. A recentPhotos set and and a usersPhotos set. But since the general pattern of Core Data seems to be to use one managed object context, it seems (I could be wrong) that I have to merge my data with the main pool of data. But that seems like a lot of overhead just to grab a list of photos. Should I create a separate managed object context for the different set? Should Core Data even be used here?
I think that what I find appealing about Core Data is that before (for a web service) I would make a request for certain data and either filter it in the request or filter it in code and produce a list I would use. With Core Data, I can just get list of objects, add them to my pool (updating old objects as necessary), and then query against it. One problem, I can see with this approach, however, is that if objects are externally deleted, I can't know, since I'm keeping my old data.
Am I way off base here? Are there any patterns people follow for dealing with remote data and Core Data? :) I've found a few posts of people saying they've done it, and that it works for them, but little in the way of examples. Thanks.
You might try a combination of two things. This strategy will give you an interface where you get the results of a NSFetchRequest twice: Once synchronously, and once again when data has been loaded from the network.
Create your own subclass of
NSFetchRequest that takes an additional block property to
execute when the fetch is finished.
This is for your asynchronous
request to the network. Let's call
it FLRFetchRequest
Create a class to which you pass
this request. Let's call it
FLRPhotoManager. FLRPhotoManager has a method executeFetchRequest: which takes an
instance of the FLRFetchRequest and...
Queues your network request based on the fetch request and passes along the retained fetch request to be processed again when the network request is finished.
Executes the fetch request against your CoreData cache and immediately returns the results.
Now when the network request finishes, update your core data cache with the network data, run the fetch request again against the cache, and this time, pull the block from the FLRFetchRequest and pass the results of this fetch request into the block, completing the second phase.
This is the best pattern I have come up with, but like you, I'm interested in other's opinions.
It seems to me that your first instincts are right: you should use fetchrequests to update your existing store. The approach I used for an importer was the following: get a list of all the files that are eligible for importing and store it somewhere. I'm assuming here that getting that list is fast and lightweight (just a name and an url or unique id), but that really importing something will take a bit more time and effort and the user may quit the program or want to do something else before all the importing is done.
Then, on a separate background thread (this is not as hard as it sounds thanks to NSRunLoop and NSTimer, google on "Core Data: Efficiently Importing Data"), get the first item of that list, get the object from Flickr or wherever and search for it in the Core Data database (carefully read Apple's Predicate Programming Guide on setting up efficient, cached NSFetchRequests). If the remote object already lives in Core Data, update the information as necessary, if not insert. When that is done, remove the item from the to-be-imported list and move on to the next one.
As for the problem of objects that have been deleted in the remote store, there are two solutions: periodic syncing or lazy, on-demand syncing. Does importing a photo from Flickr mean importing the original thing and all its metadata (I don't know what the policy is regarding ownership etc) or do you just want to import a thumbnail and some info?
If you store everything locally, you could just run a check every few days or weeks to see if everything in your local store is present remotely as well: if not, the user may decide to keep the photo anyway or delete it.
If you only store thumbnails or previews, then you will need to connect to Flickr each time the user wants to see the full picture. If it has been deleted, you can then inform the user and delete it locally as well, or mark it as not being accessible any more.
For a situation like this you could use Cocoa's archiving facilities to save the photo objects (and an index) to disk between sessions, and just overwrite it all every time the app calls home to Flickr.
But since you're already using Core Data, and like the features it provides, why not modify your data model to include a "source" or "callType" attribute? At the moment you're implicitly creating a bunch of objects with source "Flickr API", but you can just as easily treat the different API calls as unique sources and then store that explicitly.
To handle deletion, the simplest way would be to clear the data store each time it's refreshed. Otherwise you'd need to iterate over everything and only delete the photo objects with filenames that weren't included in the new results.
I'm planning to do something similar to this myself so I hope this helps.
PS: If you're not storing the photo objects between sessions at all, you could just use two different contexts and query them separately. As long as they're never saved, and the central store doesn't have anything in it already, it would work just like you describe.