I am developing one application in J2me MIDP 1.0
It requires local database management. I have heard about recordStore but can we use it for permanent storage?
Yes, your application can store data using a RecordStore, and you can get it back later even if the application or the phone has been shut down.
EDIT:
One example I found:
http://www.roseindia.net/j2me/read-write-midlet.shtml
RecordStore, or more generally, MIDP RMS API is intended just for use for permanent storage:
...The MIDP provides a mechanism for MIDlets to persistently store data and retrieve it later. This persistent storage mechanism, called the Record Management System (RMS), is modeled after a simple record-oriented database...
If you're interested in more details, refer to javax.microedition.rms package API documentation. Since you mention MIDP 1.0, make sure that you don't use API annotated as since: 2.0 in these javadocs.
Also, online tutorials are available to get you started, like:
MIDP Database Programming Using RMS: a Persistent Storage for MIDlets
Databases and MIDP, Part 1: Understanding the Record Management System
Related
I'm currently learning how to use CloudKit Framework and lack of documentation or examples showing how to sync Core Data and CloudKit.
I have watched all WWDC videos (2014, 2015, 2016) Dedicated to CloudKit, but none of them telling us how to implement syncing with Core Data. I can't find any fresh examples, tutorial or books, showing how to implement this syncing.
I know that it is effective to use Operations API by CloudKit (not Convenience API) and to Subscribe to changes as it said in the new WWDC 2016 videos, dedicated to CloudKit, but mapping with CoreData is a real problem.
For example, let's say I would like to create an app similar to Notes app. while offline, user can create his notes and work with them saving them to his core data database. When the device going online the app checks what changed on the server and saves newly created records to server (CloudKit).
When the app starts, it also fetches for changes from the CloudKit and if there are changes , it updates local cache (Core Data) with the new changes.
I would appreciate to have a common pattern of syncing. Where to place syncing with Core Data methods and how they should look like?
Would appreciate any information or help about this.
I'm using Swift 3, Xcode 8 , iOS 10.
As of iOS 13, there are new API's that simplify this synchronization for developers. I would recommend you to watch the WWDC19 session about the new synchronization between CoreData and CloudKit. Please note that these new API's only work for iOS 13+.
Video: https://developer.apple.com/videos/play/wwdc2019/202/
In short, you need to start using NSPersistentCloudKitContainer instead of NSPersistentContainer. This will let the syncing work automatically using automatic conflict resolution with a last-writer-wins merge strategy. If you want to build a good working app, you'll also need to do some modifications to improve the syncing for your app.
Official documentation can be found at:
Setting Up Core Data with CloudKit
Syncing a Core Data Store with CloudKit
Data modeling for collaboration (conflict-free replicated data type)
At the end of the session they also demonstrated an example of better sync merging than the default 'last-writer-wins merge strategy'. The usage of Causal Trees allow multiple users to edit the same string (and to some extend other types of data) without losing any data. I would really recommend everyone to read this article from Archagon that describes how this works and how to implement it (also with CloudKit syncing, but not the new automatic one). As demonstrated in the session, you can also implement this with the new automatic syncing between CoreData and CloudKit.
Core Data already provides the user with the ability to sync to iCloud. There's no need to use CloudKit.
Design For Core Data In iCloud
But yes, Core Data with iCloud has been deprecated. Even so, it has not been discontinued, and there are no immediate plans at apple to discontinue it, they just want to discourage its use. But it also has problems with rationalising updates from multiple devices.
In any case, I have been looking into the question of how to do this with cloud kit myself. Two answers; the first is to use the following;
Seam in GitHub
The second is to do it manually;
Designing for CloudKit
The key here is that Cloud Kit needs the record metadata to be able to handle record updates reliably, so you have to save that metadata in your Core Data database. The CKRecord class includes a method encodeSystemFields(with:) which will encode those fields into a Data record that can be stored in your database, and then your can use the appropriate decoder when you need to restore the CKRecord.
Anyway, I am about to start doing this myself. I'll update this with more information when I have it.
Apple has recently published a guide that seems to answer this question. Check out Apple's Maintaining a Local Cache of CloudKit Records to see how to store CloudKit data on device.
While this guide doesn't provide sample code to write to the device, it does answer the rest of the question. This tells you how to fetch changes from CloudKit and create data which can be stored on the device.
I am developing an social app on iOS that have many-to-many relation, local persistency, and user interaction. I have tried using native Parse API in iOS and find it too cumbersome to do all the client-server logic. So my focus shifted to finding a syncing solution.
After some research I found AFIncrementalStore quite easy to use and it's highly integrated in CoreData. I just started to work on this and I have two questions to ask:
1) How to do the authentication process? Is it in AFRESTClient?
2) How to set up AFRESTClient to match Parse's REST API? (an example would be great!)
P.S. I also found FTASync, which seems to be another solution. Any thought on this framework?
Any general suggestion on client-server syncing solutions will be highly appreciated!
Thanks,
Lei Zhang
Back with iOS 5 Apple silently rolled out NSIncrementalStore to manage connection between APIs and persistent stores. Because I couldn't word it better myself:
NSIncrementalStore is an abstract subclass of NSPersistentStore designed to "create persistent stores which load and save data incrementally, allowing for the management of large and/or shared datasets". And while that may not sound like much, consider that nearly all of the database adapters we rely on load incrementally from large, shared data stores. What we have here is a goddamned miracle.
Source: http://nshipster.com/nsincrementalstore/
That being said, I've been working on my own NSIncrementalStore (built specifically for Parse and utilizing the Parse iOS/OS X SDK) and you're welcome to check out/use/contribute to the project at https://github.com/sbonami/PFIncrementalStore.
Take a look at this StackOverflow question and at Chris Wagner's article on raywenderlich.com.
The linked SO question has examples for how to include the authentication token with each request to Parse. So you'll just need to have the user log in first, and store their token to include it with each subsequent request.
Chris Wagner's tutorial has a sample AFHTTPClient named SDAFParseApiClient to communicate with the Parse REST API. You'd have to adapt it to be an AFRESTClient subclass, but it should give you a start.
Some other thoughts between the two solutions you're considering:
AFIncrementalStore does not allow the user to make any changes without a network connection, while FTASync keeps a full Core Data SQLite store locally and syncs changes to the server when you tell it to.
FTASync requires you to make all your synched managed objects subclasses of FTASyncParent, with extra properties for sync metadata. AFIncrementalStore keeps its metadata behind the scenes, not in your model.
FTASync appears not to be widely used and hasn't been updated in over a year; if you use it you will likely be maintaining it.
I have an application on Symfony 1.4 framework. Recently I've started building an app in Node.js.
I need to do some action's response in node and I'd like to set credientals (log In the user) remotely, because some data is dependent on the user's data and I can't omit it.
How can I do this?
I am not sure I completely understood your scenario, but from I grasp you could share the session data (if this is the "user data" the nodejs app needs) between the two platforms (maybe use a common database to store sessions, like Redis) or you could implement a web service or api (REST) to enable communication between the two platforms, if the data is more complex.
Hope my answer was helpful.
I have an existing web app that runs offline (using HTML5 cache manifest).
I am storing data in localStorage. I am going to hit the 5Mb limit for localStorage. Can I use CouchDB as a local db, effectively replacing localStorage with the CouchDB implementation?
I don't want to install CouchDB on any servers, I just want to leverage the client-side storage capability to replace my localStorage implementation.
Is it as simple as downloading the relevant couchdb.js files and altering my client-side persistence code?
Thanks
As usual "it depends"
If your application is being served from a website then no, there are projects like pouchdb which aim to provide a client side version of CouchDB, however they arent going to help you avoid the limitations of a browser
If you are shipping your application as a standalone application then yes, it should be a fairly simple matter of following the installation instructions to add CouchDB to your application:
Android: http://www.couchbase.org/get/couchbase-mobile-for-android/current
iOS: http://www.couchbase.org/get/couchbase-mobile-for-ios/current
and having your client code make couch requests instead of localStorage ones, remembering that:
localStorage only stores strings and CouchDB stores JSON, and
calls to Couch are asynchronous and localStorage are synchronous, neither of those should be particularly big changes in javascript though.
The other main option to look at would be PhoneGap which will provide you access to the native storage API's from the device while still dealing in html / javascript, its a cross platform library that allows you to access native API's including the Storage API that wont have browser limitations - http://docs.phonegap.com/phonegap_storage_storage.md.html#Storage
PhoneGap will also require you to ship as an application and not a website (its the only way to not be limited by the browser).
This should be updated. PouchDB now uses IndexedDB which on most browsers I have tried does not have size limits (or is an option). I am storing several 100MB of map tiles in a browser.
See: https://gis.stackexchange.com/questions/62070/offline-slippy-map-tiles-database-for-leaflet/62073#62073
A short answer is that installing Couchbase Mobile on your phone requires you to ship as an application, and the Couch APIs it has are more full featured than the localStorage APIs.
If you want to get a sense for what you can do in the scope of CouchDB's web apis (not mobile specific, but handy on mobile), see this architecture document.
Is there one? (for .net)
I see msft samples StorageDotNEt and StorageRest. These dont do if-match right and they dont appear to do paged queries
Lokad has a library but does funky stuff to spread data over columns
Have you seen the one that is supported and ships with the SDK? Microsoft.WindowsAzure.StorageClient.dll? This supports blob, table, and queues. Check the Windows Azure Training Kit for basic manuevers with it.
At a low level I also used the http://azurekit.codeplex.com/ library - not a finished beast but is a more direct mapping of C# to REST - if that's what you need.