Is it possible to persist PubSub framework objects in a Core Data persistent store? Or is there a better way to do this...? I'm working on an RSS reader and looking for ways to cache RSS/Atom feeds retrieved by PubSub..
Thanks in advance
It is possible to persist PubSub objects in the persistent store, however, I am not sure if it is needed as I believe those objects are persisted in an operating system database.
Regardless, to do this, all you have to is add a transformable property, i.e. feedObject. The docs have a good explanation of how to do this:DOCS
The only real trick is that you have to import the PubSub framework on the Entity header file.
Like I said though, the feeds and associated entries are all persisted (I believe) in the operating system as long as you subscribe to the feed. The only time it retrieves entries is (a) when you first subscribe to a feed and (b) when it decides that is time to refresh the feed.
If you don't subscribe to the feed and you are only taking the feeds manually then you might want to consider adding them to your persistent store.
there is an example in the mac developer site regarding reading news feeds. The sample code can be downloaded by clicking here. Hope it will be useful for you.
here is another example by Colin Wheeler
Related
I'm working on a game-companion app and I was looking for a neat way to fetch data from multiple APIs initiated by starting my app (and maybe also if the user is refreshing the current page with swipe-to-refresh).
The thing is, I planned a dashboard-style homescreen (mostly reduced data from every API), where the user can navigate to different pages (all fed with different API's) and get detailed information for the specific section. I'm not sure how I can provide the API-data 'globally'.
I feel like my main.dart would be way too overloaded, but i can't think of any other way.
What's your thought on that?
Few approaches:
You can use a persistent db and write a wrapper DAO over it that such that anybody with access to this DAO object can write and read from DB. Packages like sqlite help in this regard.
If you are adopting bloc way of state management in your flutter app, then you can create blocs which could be used to share data across your app. flutter_bloc is a good place to start with this.
Via Singleton , If you want a sensitive data that needs to be available within the app globally, then you can create a singleton class that provides read and write from a secure vault. For this secure vault, flutter_secure_storage is convenient or shared_preferences for non sensitive data
I have been using Firebase Web SDK for my react-native app (I am using FIRESTORE to store the data). Up to this point, I have had no problems. It all works smoothly. But now I want to add some kind of offline storage mechanism to my app so that I could still offer some functionality or display some content that was cached from the last connected session even if my users are offline. After some investigation, I have the impression that react-native-firebase is the preferred way to go. Now I have some questions and I like to get some advice from the experienced.
Is react-native-firebase the only option to go? I have quickly read about AsyncStorage and it is just a key-value storage. Considering the simplest thing I want to do is page through a list of firestore documents, this kind of storage seems not to be suitable to do this offline. Like If I wanted to do this with AsyncStorage I would have to put all the content (maybe hundreds of documents) I get from the firestore backend, persist them as a single string value, fetch them back, parse them, page them etc. And write custom logic& methods for all these.
If I was to use react-native-firebase, just enabling the offline storage -I assume- takes care of this for you and you don't have to write any custom logic for offline storage usage. I assume the data that has persisted for offline usage has the same structure as it does in firestore database. I feel like If I use anything other than react-native-firebase, I would have to handle all the custom logic for persisting, reading and rendering the data offline myself. Is that right?
The biggest concern I have is the amount of code refactoring that might be required. I have many lines of code and so many .get().then() like lines where I get and render the data from firestore. In the documentation of react-native-firebase it says:
...aims to mirror the official Firebase Web SDK as closely as
possible.
I am not sure to what extent this is true. I have checked the react-native-firebase's firestore module's reference documentation but I just can't tell how many of these querying methods are actually supported.
So, the way to go is react-native-firebase's way? Would it take a heavy toll on me trying to refactor the existing code? Any similar experience do you have?
I would appreciate any help.
Thanks a lot...
Maintainer of the react-native-firebase library here.
...aims to mirror the official Firebase Web SDK as closely as possible.
This is a minor disclaimer as there are some differences between the two, mainly down to how certain things have to be implemented with React Native.
For example, enablePersistence does not exist on RNFB. Instead, persistence is enabled by default and can be toggled off (or on) via settings().
Is react-native-firebase the only option to go? I have quickly read about AsyncStorage and it is just a key-value storage. Considering the simplest thing I want to do is page through a list of firestore documents, this kind of storage seems not to be suitable to do this offline. Like If I wanted to do this with AsyncStorage I would have to put all the content (maybe hundreds of documents) I get from the firestore backend, persist them as a single string value, fetch them back, parse them, page them etc. And write custom logic& methods for all these.
This is technically possible, however there are downsides to this as you have mentioned. With Firestore, when the device goes offline (quite common on apps) and you attempt a read/write it'll read/update your local cache, which will still trigger event listeners. When the app goes back online, it'll automatically re-sync with the server for you.
If I was to use react-native-firebase, just enabling the offline storage -I assume- takes care of this for you and you don't have to write any custom logic for offline storage usage. I assume the data that has persisted for offline usage has the same structure as it does in firestore database. I feel like If I use anything other than react-native-firebase, I would have to handle all the custom logic for persisting, reading and rendering the data offline myself. Is that right?
This is all handled for you. We wrap around the native Firebase SDKs so expect the same level of consistency if you were developing a native Android/iOS app if not using React Native.
The biggest concern I have is the amount of code refactoring that might be required. I have many lines of code and so many .get().then() like lines where I get and render the data from firestore.
Generally everything is the same apart from a few minor methods for reasons mentioned above.
So, the way to go is react-native-firebase's way? Would it take a heavy toll on me trying to refactor the existing code? Any similar experience do you have? I would appreciate any help.
I'd recommend anyone developing with React Native & Firebase to use RNFB. It provides a lot of extra functionality the Web SDK cannot provide with React Native. Apart from a more cumbersome setup & changing imports, it should work very much the same.
Having to look to all the feed data in the phone harms people's necks. A more comfortable way to see and manipulate it is needed. I would like to do a web viewer to view the up application feed in a browser.
However, I had a look at the REST API and couldn't find a way to obtain it. There is a part where generic "events" are mention. Can I obtain the feed data from there?
Regards
The developer REST APIs do not provide the ability to re-create the UP app's feed.
If you really want to, you could do a close approximation since the APIs provide most of the data that appears in the feed. However, you would have to provide all the styling and assets yourself.
How does the Dropbox Datastore API differ from similar offerings like Parse? One difference that I see is that my users pay for server storage instead of me. Are there other differences?
Disclaimer: I'm a Dropbox engineer who worked on the Datastore API, and know about the Parse API only indirectly. Weigh my opinion appropriately. Major differences I know of (pro and con):
Dropbox Datastores are free to the developer, and free the user for the first 5MB per-app (after which their Dropbox quota applies). Parse charges developers based on how many API requests they’re making.
Parse has minimal offline support, while Dropbox has full offline operation. With Dropbox, if the developer modifies data while offline, those modifications will be reflected in subsequent queries (with Parse, those changes are not reflected). Dropbox provides on-device query logic (unlike Parse) so that apps can continue to generate the views they need to, even when there’s no Internet available. In addition, Parse does not provide conflict resolution or querying offline.
Parse provides the ability to share data between users, and global data for all users of the app. Dropbox Datastores only support per-user data (for each app) for now (sharing is on the roadmap).
I would also add that:
Parse is full feature of backend of as service. You can find a pretty complete list of the other player in this field: http://en.wikipedia.org/wiki/Backend_as_a_service. They provide feature like:
Data service
User registration/auth
Push notification
Social
The dropbox Datastore APIs is more focusing on data services. (You also got the User part for free too?) Also it works full offline.
The Parse framework can store data that can be ready by any user in the application.
The Dropbox datastore, store data for each user, and you can't accesss data from other user. That's the main difference.
So easy to get lost in this since you have to read between the lines. My take is that with Datastore you are working with objects stored offline locally as json. I'm hoping they will soon release a Xamarin Android component - they released an IOS component last month. Since Xamarin targets both Android and IOS and Winphone, who knows why they made a dedicated IOS DLL for Xamarin but I digress. With Parse, it appears to me their intent is the always-connected-device. Sure you can save queries locally and you can save (save eventually) locally where Parse will push to the server when it is connected. But saving "eventually" and saving queries for offline work is a different design than just saving and letting Parse do it all in the background for you - which it does not unless I have missed something that would make this attractive to me. I cannot see Parse useable for devices that you know will be sometimes-connected, without a lot of code to make this happen and sync.
I have an app that relies on some key value pairs where the value could change at a point in the future due to 3rd party api. The app is only useful when connected to the internet by the way. If any values change I don't want issue a new version of the app - I would rather that these values were pulled from a webservice/static xml file on my server. I would only need to pull these if I encountered an error.
Is there a standard way to do this or should I just roll my own?
EDIT: I'm not so interested in a server side technology - I think a flat file will suffice. What I'm interested in is what format should the flat file should be and how to cache it into my application once I get an error.
try redis, high-performance key-value store. used by some of the big cloud players, like cloudfoundry. Have a look at http://redis.io/. Objective-c client is available at http://redis.io/clients.
I figured out the best way for my use scenario:
I setup a json file on S3 which required authentication. I then used AWS for Objective C to authenticate so I could access that file.
I decided that I only needed to update the local info when the applicationDidBecomeActive in the App Delegate. I then got the json async and on success I then checked a version number in the json and if outdated wrote the changes to NSUSerDefaults (which are then used through the app.) If there was an error getting the json file I just continued as I would already have the previous set of NSUserDefaults that would do the job until the user next made the app active.
This solution worked best for me as it's simple to maintain and should easily handle the load even if my app were popular.
Have you considered using iCloud? It has support for key value pairs. More info here: http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/iCloud/iCloud.html